Mail Archives: djgpp/2004/08/10/21:00:41
On 10 Aug 2004 13:18:28 +0300 in comp.os.msdos.djgpp, Esa A E Peuha
<esa DOT peuha AT helsinki DOT fi> wrote:
>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
Looks like you're correct about -Cg not being entirely truthful about
globals without leading _. The revised list of non-Standard globals
from a dummy program with no #includes compiled with -ansi -pedantic
are:
T _close close *
D _edata edata
B _end end
B _environ environ
T _etext etext
T _sbrk sbrk *
where the routines marked * are Unix compatible routines called by the
startup/exit code. Can be worked around, as you indicate below?
So djgpp_*, exception_stack, and start do not pollute, as you said.
>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.
Eli Z pointed out that it must be available for POSIX compatible code
that requires it, but should not be present for ANSI compiles.
I would be interested in how you can have it defined, if it is
declared, but not defined as a global, and have it not be defined if
it is already defined?
--
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
- Raw text -