X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Trace-PostClient-IP: 68.147.131.211 From: Brian Inglis Newsgroups: comp.os.msdos.djgpp Subject: Re: Environment Variables Organization: Systematic Software Message-ID: References: <41115A5F DOT 7DDC6318 AT yahoo DOT com> <41127AF9 DOT 26DEA37C AT yahoo DOT com> <4112BE04 DOT 3B151CA1 AT yahoo DOT com> <7494-Fri06Aug2004121205+0300-eliz AT gnu DOT org> <7137-Sat07Aug2004185953+0300-eliz AT gnu DOT org> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 65 Date: Sat, 07 Aug 2004 19:28:16 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse AT shaw DOT ca X-Trace: pd7tw1no 1091906896 24.71.223.147 (Sat, 07 Aug 2004 13:28:16 MDT) NNTP-Posting-Date: Sat, 07 Aug 2004 13:28:16 MDT To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Sat, 07 Aug 2004 18:59:54 +0300 in comp.os.msdos.djgpp, "Eli Zaretskii" wrote: >> From: Brian Inglis >> 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. I'll look at libc and maybe post to the workers list. >> 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: (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. Boggle! Aargh! Then perhaps an internal header would be the place to declare it, just so that the declaration is explicitly documented and can be found by searching *ALL* the headers. Similarly with the other symbols, once again, mainly for documentation purposes, so that if someone asks, we can say it's declared and documented somewhere. >So if we want to stop polluting the namespace of strictly ANSI >programs with this symbol, we need to devise something more creative. I guess I need to look at the latest POSIX specs for brighter ideas. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian DOT Inglis AT CSi DOT com (Brian dot Inglis at SystematicSw dot ab dot ca) fake address use address above to reply