[Libevent-users] [Patch] Install autoconf header file as evconfig.h
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 decide whether to define those existed only in the config.h file created by autoconf. Here is a patch that solves this problem by renaming config.h to evconfig.h, making it get included from event.h, and installing it as a header file to $PREFIX/include. This way, people on platforms like mingw and Solaris will be able to build projects that use mingw correctly. This isn't a new or controversial approach, so far as I can tell: many other projects, like mysql, postgresql, glib, expat, firefox, SDL, python, and so on, do the same thing. (For an approximate list, run ls /usr/include/*/*config.h on your favorite _nix machine.) The patch is here: http://www.wangafu.net/~nickm/libevent_evconfig_patch/evconfig.diff In addition to this patch, you'll need to rename WIN32-Code/config.h to WIN32-Code/evconfig.h. You'll need to re-run aclocal, autoheader, autoconf, and automake after applying this patch. I have not tested it on all platforms. yrs, -- Nick Mathewson pgpKRwfU00ruW.pgp Description: PGP signature ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [Patch] Install autoconf header file as evconfig.h
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 build projects that use event.h correctly. yrs, -- Nick Mathewson pgpzTKrxvnSb4.pgp Description: PGP signature ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [Patch] Install autoconf header file as evconfig.h
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 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 decide whether to define those existed only in the config.h file created by autoconf. Here is a patch that solves this problem by renaming config.h to evconfig.h, making it get included from event.h, and installing it as a header file to $PREFIX/include. This way, people on platforms like mingw and Solaris will be able to build projects that use mingw correctly. Wouldn't it be cleaner to either 1) Use (unsigned char) instead of (u_int8_t), (unsigned int) instead of (u_int32_t), and include sys/time.h or timeb.h, conditional on the WIN32 macro; Actually, you'd want to do unsigned long instead of unsigned int; old C only guarantees that int can hold 16 bits. or, if the above isn't portable enough from a theoretical perspective, 2) Build an event.h using M4 and the autotools framework? The additional header just litters things unneccesarily, especially for something this trivial (not to say the headaches are trivial; I build on all these platforms, too). 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. :) yrs, -- Nick Mathewson pgp6LdQBu9T9V.pgp Description: PGP signature ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [Patch] Install autoconf header file as evconfig.h
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 timeval, and so on. It wasn't possible for event.h to do so itself, since the info needed to decide whether to define those existed only in the config.h file created by autoconf. Here is a patch that solves this problem by renaming config.h to evconfig.h, making it get included from event.h, and installing it as a header file to $PREFIX/include. This way, people on platforms like mingw and Solaris will be able to build projects that use mingw correctly. Wouldn't it be cleaner to either 1) Use (unsigned char) instead of (u_int8_t), (unsigned int) instead of (u_int32_t), and include sys/time.h or timeb.h, conditional on the WIN32 macro; Actually, you shouldn't use (unsigned int), very unportable. Use (unsigned long) if you must. 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). In all cases that I have seen (I admit, I haven't looked recently to see how a DEC-10 implements this, with it's 10 bit bytes), but, for almost every modern implementation I have seen (including MIPS64), char is 8 bits, short is 16, long is 32, and long long is 64. Int is unpredictable and non-portable. That said, the only typedefs I can possibly see of interest are wrappers for 8 bit data types, since char implies character data not numeric type data. Also, I have only seen 2 platforms in the years that treat char as unsigned rather than signed, without a specifier, and neither of those platforms exist anymore. Just look in linux/types.h, they define u_short, ushort, u_int16_t, and uint26_t. This is in addition to the __u16 defined in asm/types.h. None of these have platform wrappers around them, which implies the base types are VERY portable. Two header files, 5 defines for the same thing. That said, why not just fix the code for unsigned or nothing (you shouldn't need to specify everything as signed), followed by char, short, long, or long long. Any programmer that is worth anything would know the sizes these apply to. Note, that this isn't a flame on libevent per se, I take issue with this everywhere (including the companies I have worked at). ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [Patch] Install autoconf header file as evconfig.h
On Fri, Feb 16, 2007 at 07:17:17PM -0500, Nick Mathewson wrote: snip 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 a strong stomach tonight I might dive into the autoconf morass. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [Patch] Install autoconf header file as evconfig.h
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 typedefs per se. The underlying problem is that C doesn't provide any built-in portable way of saying you want a data type exactly THIS big, short of resorting to structs with bit-counted fields. None of the built-in types are required to be a particular size, even if they happen to have settled down on particular sizes on present-day architectures. I would much rather waste one line of header file somewhere doing a seemingly redundant typedef than have my code break on some future 128-bit machine whose long is 64 bits and long long is 128. (Heck, forget future -- such machines exist today!) That would be perfectly legal for a C compiler to do. uint32_t is much more precise and unambiguous than unsigned long -- I read that and have no doubt how big the author expected the data type to be. -Steve 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 imply that they really are required to be these sizes, or the header files be broke. If there were an architecture with char being 8, short being 32, long being 64, and long long being 128 (the National 32032 did this without the long long), there would be no way to express a 16 bit data type, so you couldn't even define an uint16_t type! How would autoconf work in this case? How would you build a types.h for C (not C++) to deal with a 16 bit data type as a native type? How badly would all the code on the planet that uses a uint16_t type work (assuming you can get it to compile)? Note, this is because of the limitation on the C standard, not on the games played by the typedefs. 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 everything written to date will break), how would you get the fifth type? I have worked on projects where different people are familiar with different type conventions, so the code is written with two or more of the various typedefs, based upon who touches the code when. Note that this is for commercial products not open source, with formal review processes, etc. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [Patch] Install autoconf header file as evconfig.h
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 everything written to date will break), how would you get the fifth type? You wouldn't, and your application would fail to build because it's not compatible with that architecture -- which IMO is a better situation than it building just fine (because you used long) and failing at runtime because the code expected a particular length and got something different. If the failure is in an infrequently-used part of the code you might not discover it until pretty far down the road. Using typedefs gives you fail-fast behavior on systems that can't support the required types. I have worked on projects where different people are familiar with different type conventions, so the code is written with two or more of the various typedefs, based upon who touches the code when. Note that this is for commercial products not open source, with formal review processes, etc. Me too, and I'm not defending that practice! If anyone sees redundancy like that in libevent, it should be stamped out immediately. But the fact that word-length typedefs can be used poorly isn't a reason to not use them at all; they do serve a useful purpose in some cases. -Steve ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [Patch] Install autoconf header file as evconfig.h
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 imply that they really are required to be these sizes, or the header files be broke. But C *does* define fixed-width types, through stdint.h, ever since C99 (going on 8 years, now!). And all modern platforms which even contemplate some POSIX/SUSv3 support, provide stdint.h, now, w/ the glaring exception of Microsoft and the Visual Studio suite. Actually, I think that SUSv3 mandates uint8_t, uint16_t, uint32_t, similar to how POSIX/SUS mandates that CHAR_BIT is 8. C99, strictly speaking, only requires the fixed-width types be defined through stdint.h if they can be represented as such. C99 also defines least and fast types. In any event, it kills me that Microsoft won't even add stdint.h. Kills me! People rail against C99 all the time, but the fact is that some very important parts are very nearly universally supported, now, at least in terms of number of distinct enviornments. stdint.h and snprintf() are the two most widely known. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [Patch] Install autoconf header file as evconfig.h
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 previous post imply that they really are required to be these sizes, or the header files be broke. But C *does* define fixed-width types, through stdint.h, ever since C99 (going on 8 years, now!). And all modern platforms which even contemplate some POSIX/SUSv3 support, provide stdint.h, now, w/ the glaring exception of Microsoft and the Visual Studio suite. Actually, I think that SUSv3 mandates uint8_t, uint16_t, uint32_t, similar to how POSIX/SUS mandates that CHAR_BIT is 8. C99, strictly speaking, only requires the fixed-width types be defined through stdint.h if they can be represented as such. C99 also defines least and fast types. In any event, it kills me that Microsoft won't even add stdint.h. Kills me! People rail against C99 all the time, but the fact is that some very important parts are very nearly universally supported, now, at least in terms of number of distinct enviornments. stdint.h and snprintf() are the two most widely known. I didn't anticipate that this would go for this long, but... I agree stdint.h is pretty much a standard. It defines the ones you are mentioning. Libevent uses the u_intX_t types (from types.h). As I said, my complaint is in the massive proliferation of these (in many different flavors). In my opinion, C99 (and ANSI) should have specified it at the compiler level NOT the header level, but, oh well. I would much rather see everything get broken by removing the different types from types.h than give everyone every flavor of everything, and then have companies specify their own standard definitions as well. As for Microsoft not providing stdint.h, there is lots more that they provide or not that forces non-standard implementations (such as their template library for C++). Enough said, lets get back to libevent rather than C. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
