Re: C++ fix and test

[Mo DeJong]

On 20 Dec 2000, Alexandre Oliva wrote:

> On Dec 20, 2000, Assar Westerlund <address@hidden> wrote:
> 
> > Alexandre Oliva <address@hidden> writes:
> >> On Dec 20, 2000, Akim Demaille <address@hidden> wrote:
> >> 
> >> > Why do you want to try without stdlib.h?
> >> 
> >> Because stdlib.h may not be safe for multiple inclusion, and the
> >> user test may already #include it.
> 
> > IIRC, Standard C says that all header files should be
> > multiple-inclusion safe.  It seems reasonable to be able to assume it
> > holds with common C++ compilers too, doesn't it?
> 
> There are OSs that whose stdlib.h isn't safe for multiple inclusion,
> and g++, for one, won't override the system's stdlib.h, so, yes, there
> are C++ compilers with broken headers, and I don't think providing
> minimal support for running tests with such compilers is doing way too
> much.  I've already explained the solution.  Now it's just a matter of
> coding a few lines of shell to make it true.  I may eventually get to
> do it, but if people are in a hurry to get a new snapshot out, I may
> not be able to make it.  I just wouldn't like to see a release of
> autoconf going out without minimal support for g++ on a number of OSs
> out there.

I think the default should be to support working systems and
then add workarounds for the "known broken" ones. If the
issues is just a double #include, we can just run a test
like:

#include <stdlib.h>
#include <stdlib.h>

int main(int argc, char ** argv) {
    exit(0);
}

If that works, then #include <stdlib.h> can be used
everywhere. After that, I really don't care what
happens. At the very least, it should work correctly
for the non-broken system.

Sure, you could go adding an exit() proto but you
could also just leave it up to the user to include
or not include <stdlib.h> in the test they write.
Some folks might have to rewrite a test or two
but I am not sure that would be too much to ask.

Mo DeJong
Red Hat Inc