Mail Archives: djgpp/2004/08/07/12:02:55
> From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT Invalid>
> Newsgroups: comp.os.msdos.djgpp
> Date: Fri, 06 Aug 2004 19:57:39 GMT
>
> FWIW below is a list of library symbols that pollute the user global
> namespace in *ALL* C programs and are not mentioned in the libc
> documentation.
Thanks for posting this list.
> ISTM that a reasonable first step would be to document the existence
> of these symbols in the libc documentation
Patches to the docs are most welcome.
> and possibly add useful
> public interfaces to some header file, perhaps only for the case of
> environ, which seems to be the only symbol likely to be accessed by
> user level code.
Unfortunately, that's not easy to do; see below.
> A useful place for at least defining environ so that it could at least
> be found in a header file might be in .../include/libc/environ.h
No, that's not good: <libc/environ.h> (as well as all the other
headers in the `libc' subdirectory) are internal libc headers.
Applications should never use them.
> between the ANSI and POSIX excludes [1], unless _POSIX_SOURCE has to
> be defined to include it, in which case [2]:
>
> #ifndef __STRICT_ANSI__
>
> extern char **environ; [1]
>
> #ifndef _POSIX_SOURCE
>
> extern char **environ; [2]
Alas, the Posix standrad explicitly says that `environ' is not
declared in any system header.
So if we want to stop polluting the namespace of strictly ANSI
programs with this symbol, we need to devise something more creative.
Thanks anyway for your suggestions.
- Raw text -