Re: stdint.h

I hate to say it, but the simplest thing is to use long long int for all this junk. In practice that is what it is on most systems, or at least that covers their useful range. The unfortunate answer is that C/C++ is just plain ill considered. The argument that you should just use cout is ludicr

Re: Removing DIR_SEP code

+1 Yes the DIR_SEP was for windows. Path handling, etc can be re-done if/when the windows port is done. -G On 5/18/10 10:37 PM, Mladen Turk wrote: > Hi, > > I propose we remove all DIR_SEP code and just use the > slash directly. > > The only reason for DIR_SEP can be windows, but I propose > that

Removing DIR_SEP code

Hi, I propose we remove all DIR_SEP code and just use the slash directly. The only reason for DIR_SEP can be windows, but I propose that for windows we create a private set of posix_path_to_windows_path_and_vice_versa set of functions which would allow proper path construction (eg, using \\?\ pr

Re: stdint.h

On 05/19/2010 07:02 AM, John Plevyak wrote: I would say that if we can't find a system which doesn't support the standard %lld for 64-bit numbers then we should just go with the standard. It is simpler and it will only be more right as time passes because it is the standard. Fair enough. Make

Re: stdint.h

All compilers that are C99 compliant must accept %lld as long long int where sizeof(long long int) == 8. Sun 64 and linux 64 both have sizeof(long) == 8, but because of C99 they also have sizeof(long long int) == 8 and %ld and %lld will both work with 64-bit arguments, however gcc/g++ will compla

Re: stdint.h

On 05/19/2010 06:35 AM, John Plevyak wrote: However, since the C99 and new C++ standard declares that long long int is 64-bit and since just about everyone already has that: linux, solaris, freebsd, mac, and since I have been able to use it portably for several years now I would rather go that

Re: stdint.h

There are standard macros for doing that (e.g. PRIu64) which are defined in /usr/include/inttypes.h for ISO C99 7.8. If we had to go that route I would go with those rather than a roll-your-own even if that means defining them on platforms that don't have ISC C99 support yet (only a decade past).

Re: stdint.h

On 05/19/2010 02:52 AM, John Plevyak wrote: Why the hell uint64_t is defined this way and g++ complains even though long int == long long it is beyond me. Suggestions, comments? I saw whole bunch of %ld, %lld stuff in the code which will IMHO never be portable no matter what type you use.

stdint.h

It seems that g++/C++ is completely broken with respect to portable 64-bit numbers and scanf/printf. uint64_t is long long int on 32-bit machines and long int on 64-bit machines and scanf/printf require the corresponding %lld %ld which is painfully difficult. Until they fix it, either we use the

Apache Traffic Server 2.1.0-unstable released

We are pleased to announce that Traffic Server 2.1.0-unstable is now available on the Apache mirrors. http://www.apache.org/dyn/closer.cgi/trafficserver/ This is an unstable release from the development line so all issues reported will be fixed in the trunk. That said, 2.1.0-unstable brings a

Re: Remove INKPluginLicenseRequired() ?

+1 for removal -Jason On May 18, 2010, at 10:27 AM, Leif Hedstrom wrote: Hi, I'm thinking of removing the API INKPluginLicenseRequired(), there's just something that seems 'wrong' with having such an API in a free, open source project. Unless someone objects, I'll remove it on Thursday

Remove INKPluginLicenseRequired() ?

Hi, I'm thinking of removing the API INKPluginLicenseRequired(), there's just something that seems 'wrong' with having such an API in a free, open source project. Unless someone objects, I'll remove it on Thursday. -- leif