autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: C++ fix and test


From: Bernard Dautrevaux
Subject: RE: C++ fix and test
Date: Thu, 21 Dec 2000 14:57:08 +0100

> -----Original Message-----
> From: Mo DeJong [mailto:address@hidden
> Sent: Wednesday, December 20, 2000 6:44 PM
> To: address@hidden
> Subject: Re: C++ fix and test
> 
> 
> 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.

Anyway, supporting such broken systems in our tests would not be enough; if
stdlib.h is not safe, we'd better warn the user never to include stdlib.h as
a system header on such a broken system may include it ;-(

More seriously, I don't think a test like

#include <stdlib.h>

main() {
    exit(0);
}

may fail for ANY other reason than exit not being properly declared. 

Then any test including other system header files and stdlib.h should
compile OK, or even simple C programs could not be compiled without severe
hacking like:

#include <foo.h>
#include <bar.h>
#ifndef FOO_H_INCLUDES_STDLIB_H_AND_STDLIB_H_UNSAFE
#ifndef BAR_H_INCLUDES_STDLIB_H_AND_STDLIB_H_UNSAFE
#include <stdlib.h>
#endif
#endif

(and writing all the AC_DOES_FOO_H_INCLUDES_UNSAFE_STDLIB_H tests...)

Seriously, I don't know if such broken systems exists, but I'd solve the
problem by a simple bit of documentation saying:

    WARNING: If your stdlib.h (or any other system header by the way) is NOT
    protected against multiple inclusion as it should be you MUST add a file
    looking like this in some directory located in the include path BEFORE
    the directory where stdlib.h lies (usually "/usr/include"):

        /* Fix for broken stdlib.h */
        #ifndef __STDLIB_H_ALREADY_INCLUDED__
        #define __STDLIB_H_ALREADY_INCLUDED__
        #include </usr/include/stdlib.h>
        #endif

Anyway, I don't think anybody can expect to port ANY package to such a
system without resorting to this kind of hack... :-)

Regards,

        Bernard

PS: Although it could be possible, I would NEVER advocate adding to AUtoconf
a fixheader-like script generating such wrappers during the configure
process; if a system is such braindead, the user must be aware of it! :-)
 
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:    +33 (0) 1 47 68 80 80
Fax:    +33 (0) 1 47 88 97 85
e-mail: address@hidden
                address@hidden
-------------------------------------------- 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]