egcs, does gcc fixincludes etc guarantee a stdlib.h exists?

[Philippe De Muyter]

> 
> 	Alternatively, we could put malloc, realloc, calloc and free outside of
> 	__USE_FIXED_PROTOTYPES__ in the generated stdlib.h.
> 
> I have been trying to discourage you from fixing this problem in stdlib.h
> because I believe it is unsafe to put stuff there by default.

I think that I understand your point of view, but that I was not clear enough.
On some systems, the native compiler does not provide a stdlib.h. The
behaviour of gcc on those systems is to provide a stdlib.h that is
basically empty, which is useless, unless we define __USE_FIXED_PROTOTYPES__.
On those systems only (and maybe only if enabled by some target macro),
I suggested to populate stdlib.h with some usefull prototypes or simply
extern declarations for functions known to be POSIX compliant.

> I just remembered another problem.  There exist many programs which have
> their own declarations of these C library functions.  Some of them them
> have wrong definitions.  Some of them have definitions which are not valid
> POSIX, but which agree with the system's man pages.  There may also be 
> declarations in the system header files in other files which are not POSIX.
> If we add our own POSIX declarations to stdlib.h, we run the risk that some
> programs won't compile with gcc anymore.  Dealing with all of these bug reports
> will be a hassle, and I would rather not have them in the first place.

I do not think that adding a stdlib.h file on a system where previously
there was none would make some program to not compile with gcc anymore.

Philippe