Re: dont! Re: stdbool macro, take 2

[Guido Draheim]

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)