just read through that message reference, bruce, and I do agree of course - I think the real problem with stdint/stdbool and friends is that it is just a nuisiance to make projects be portable to platforms that are not strictly up at '99 or better, and w.r.t. gstdint I can point to the fact that inttypes were introduced in 1992, being later part of unix98, and folded into C99. But I am not supposed to use these inttypes because there are many compilers and systems out there that do not have them, - I could adapt my local source code but I am not allowed to put them into public header files. It's making me sick, really :-( ... and in way the same account to bool/true/false series of defines, since one should think that all this is actually established programming practice but for the merits of portability, I do have to avoid that and start using those mylib_bool defines all over the public interfaces.
Of course, instead of doing a mylib_bool for every project of mine, I could just as well extract that part into a seperate project (e.g. "autoposix" ;-)) and let my local one be dependent on it. And in a way, I would not be suprised that many people start using libglib just for the reason that it flattens the differences of the supported systems and returns, among other stuff, an up-to-date system interface to such established programming schemes like inttypes, dlopen and lwp-threading, and not to forget, gboolean. @paolo I agree with you too but on one thing: a programmer does not specifically need to copy stuff in over and over again, instead it is possible to make an #ifdef series like #if defined HAVE_STDBOOL_H #include <stdbool.h> #elif defined HAVE_GSTDBOOL_H #include <gstdbool.h> #error could not get either of stdbool or gstdbool, sorry #endif and let user code (of such a header file) be required to check for these. This happens to be of established autoconf practice to search in multiple headers for things that we need, and AC_HEADER_DIRENT might serve as an example for it. And in a way, it was also the reason I started with that gstdint microproject that is based on my m4 macro to check into the various possible locations for inttypes and have now a last resort being a dependency on the file that gstdint could install all out of itself. I have to admit that I am not quite convinced that it is the final answer to all the problems in this area but just a step more to detach myself from the problems there are around with multiple lib-headers to try to define stdxxx types in different locations all over again. So, in a way I would ask you to start such a microproject for gstdbool too - other projects could then check for bool in it's normal locations (possibly being predefined in the compiler) and have a third-party check for gstdbool.h, and just make a note in your project docs that you declare the bool-types as a precondition to be it around, and hint the user that this might be in the compiler, from a system extension or from that microproject one can hand out the url for. And autoconf could get a standard-macro ac_header_stdbool that would work just like header_dirent with one exception - it will also check for the header from from the microproject that has settled around the autoconf-people, and in a way it is the reason that I placed gstdint in a subdir of the ac-archive sfnet-fork as I see it as a thing very close to autoconf but not just in it. Anyway, even that I do not feel your stdbool macro should live in the autoconf core itself, I feel it could be great contribution to be memorized in the ac-archive, so that people shall not need to reinvent it. Amongst the various effects I could not that one would be able to make a standard for an is-already-defined macro that other header could check so they do not redefine the same symbols. Such a thing has been done for inttypes all the way long (since it overlaps with the bsdtypes stemming from network code), and it could be used for generated-header too, so that the generated header contains #ifndef _GENERATED_STDBOOL_H #define _GENERATED_STDBOOL_H xxxx #endif which will avoid redefinitions even when the macro and the header-generation is used in multiple places around the software world. Actually, it's another lesson that I had to learn around stdint and friends. And to emphasize it again, I am not sure if it is the last lesson I have to learn the hard way.... sorry for such a long talk on it, 'hope the things do not look that foggy as they do look to me sometimes, cheers, guido Es schrieb Bruce Korb: > > Guido Draheim wrote: > > being a person who has been doing some tricky stuff with a generated > > file called stdint.h, I would like to oject on generating a stdbool.h > <<reasons elided>> > I agree, with arguments about project focus and project bulk > to boot: http://sources.redhat.com/ml/autoconf/2001-11/msg00033.html > > > p.s. references are > > http://ac-archive.sf.net/gstdint > > http://ac-archive.sf.net/Miscellaneous/ac_create_prefix_config_h.html > > The downside to "gstdint" or "gstdbool" is that they are just > the tip of an ugly iceberg. If you were to assemble one project > for every fixable compatibility issue, you would find yourself > with a lot of projects. In my code sourcery contest entry I > proposed a single project that ran through the million known > compatibility issues and installed whatever was needed so that > a consistent interface was available for all supported platforms. > This would mean that a "stdint.h" and a "stdbool.h" headers > would be part of it and installed as needed. Then, instead of > bulking up every autoconf-ed project in the world with 300K > of duplicated configury overhead, a project can just have a > dependency on a minimum revision of the compatibility library. > Way, way, way simpler. Smaller distributions. "configure" > could focus on the with/without/enabled/disabled options for > each package. autoconf users would not need to be M4 quoting > experts. I suppose I'm just whistling in the wind? ;-) -- guido http://freespace.sf.net/guidod GCS/E/S/P C++$++++ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)
