William Ahern wrote:
On Fri, Feb 16, 2007 at 04:58:53PM -0800, Dave Gotwisner wrote:
Yes, C doesn't define it (ANSI should have at the char/short/long/long
long level). Even though there is nothing requiring that short is 16
and long is 32, the fact that the type.h files I mentioned in my
On Fri, Feb 16, 2007 at 04:58:53PM -0800, Dave Gotwisner wrote:
> Yes, C doesn't define it (ANSI should have at the char/short/long/long
> long level). Even though there is nothing requiring that short is 16
> and long is 32, the fact that the type.h files I mentioned in my
> previous post impl
Dave Gotwisner wrote:
Using your example, if you had a 8, 16, 64, and 128 bit native types,
and you wanted an EXACTLY 32 bit type, how would it work? Given ANSI
only specifies char, short, long, and long long, when we support 256
bit native types, and you still need the smaller ones (or everyt
Steven Grimm wrote:
Dave Gotwisner wrote:
I personally hate the proliferation of typedefs. I have seen u8, U8,
u_int8, uint8, and many others that all express the same thing.
(similarly for 16, 32, and 64 bit sizes).
The lack of a common standard is the problem, IMO, not the existence
of
Dave Gotwisner wrote:
I personally hate the proliferation of typedefs. I have seen u8, U8,
u_int8, uint8, and many others that all express the same thing.
(similarly for 16, 32, and 64 bit sizes).
The lack of a common standard is the problem, IMO, not the existence of
typedefs per se. The un
On Fri, Feb 16, 2007 at 07:17:17PM -0500, Nick Mathewson wrote:
> I think your approach is reasonable too in the medium term; you should
> probably send a patch to the list too, so yours can win. :)
>
*yawn* I'd rather complain from the sidelines whilst other people do the
work ;)
If I can keep
On Fri, Feb 16, 2007 at 04:28:26PM -0800, Dave Gotwisner wrote:
> I personally hate the proliferation of typedefs.
I concur whole heartedly.
> I have seen u8, U8, u_int8, uint8, and many others that all express the
> same thing. (similarly for 16, 32, and 64 bit sizes). In all cases that
> I ha
William Ahern wrote:
On Fri, Feb 16, 2007 at 06:24:34PM -0500, Nick Mathewson wrote:
Hi, all!
Now that Libevent 1.3 is out, it's time for Patches Less Obvious.
One longstanding problems has been that it's not possible to include
event.h unless you first define u_int8_t, u_int32_t, struct t
On Fri, Feb 16, 2007 at 04:10:03PM -0800, William Ahern wrote:
> On Fri, Feb 16, 2007 at 06:24:34PM -0500, Nick Mathewson wrote:
> > Hi, all!
> >
> > Now that Libevent 1.3 is out, it's time for Patches Less Obvious.
> >
> > One longstanding problems has been that it's not possible to include
> >
On Fri, Feb 16, 2007 at 06:24:34PM -0500, Nick Mathewson wrote:
> Hi, all!
>
> Now that Libevent 1.3 is out, it's time for Patches Less Obvious.
>
> One longstanding problems has been that it's not possible to include
> event.h unless you first define u_int8_t, u_int32_t, struct timeval,
> and so
On Fri, Feb 16, 2007 at 06:24:34PM -0500, Nick Mathewson wrote:
[...]
> This way, people on platforms
> like mingw and Solaris will be able to build projects that use mingw
> correctly.
Oh dear. This is why I should proofread everything _three_ times, I
guess. This sentence should read "...to
Hi, all!
Now that Libevent 1.3 is out, it's time for Patches Less Obvious.
One longstanding problems has been that it's not possible to include
event.h unless you first define u_int8_t, u_int32_t, struct timeval,
and so on. It wasn't possible for event.h to do so itself, since the
info needed to
12 matches
Mail list logo