[Top][All Lists]
[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
--------------------------------------------
- Re: C++ fix and test, (continued)
- Re: C++ fix and test, Raja R Harinath, 2000/12/20
- Re: C++ fix and test, Pavel Roskin, 2000/12/20
- Re: C++ fix and test, Assar Westerlund, 2000/12/20
- Re: C++ fix and test, Alexandre Oliva, 2000/12/20
- Re: C++ fix and test, Akim Demaille, 2000/12/20
- Re: C++ fix and test, Assar Westerlund, 2000/12/20
- Re: C++ fix and test, Mo DeJong, 2000/12/20
- Re: C++ fix and test, Alexandre Oliva, 2000/12/21
- Re: C++ fix and test, Raja R Harinath, 2000/12/20
- Re: C++ fix and test, Alexandre Oliva, 2000/12/21
RE: C++ fix and test,
Bernard Dautrevaux <=