Mail Archives: djgpp/2004/08/10/06:30:25
Brian Inglis <Brian DOT Inglis AT SystematicSw DOT Invalid> writes:
> 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.
Actually, most of them don't pollute the namespace at all.
> It was produced by compiling and linking a small dummy program, then
> running nm -Cg, stripping the addresses, and editing out the
> documented names.
Giving the -C switch to nm is a bad idea, because you need the leading
underscores to know if a symbol can pollute the namespace; those with no
underscores don't pollute because they are inacessible from C, those
with more than one don't pollute because they are reserved to the
library. Only the symbols with exactly one leading underscore can
pollute, and not even all of those do.
> The first letter tells you whether it's defined in a text, data or bss
> segment.
>
> D djgpp_first_ctor
> D djgpp_first_dtor
> D djgpp_last_ctor
> D djgpp_last_dtor
> D edata
> B end
> B environ
> T etext
> B exception_stack
> T start
Of these, the only one that does pollute at all is environ.
> ISTM that a reasonable first step would be to document the existence
> of these symbols in the libc documentation, 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.
No, the reasonable first step is to fix it, since it's very easy to do.
I'll post the fix to the djgpp-workers list.
--
Esa Peuha
student of mathematics at the University of Helsinki
http://www.helsinki.fi/~peuha/
- Raw text -