In article <d2**********@n ews1.kornet.net >,
±èµ¿±Õ <na*******@game .hs.kr.NOSPAMOK > wrote:
Tell me why the symbol "_" use in the Library?
For example,
char *_itoa( int value, char *string, int radix );
But We use function "itoa(value,str ing,radix) "only.
I want to know the specific reason .
This is a matter which is dependant on the library implimentation and
upon the operating system library format and link procedures.
This topics are not generally considered to be "on topic" for
comp.lang.c as people here usually prefer to only talk about matters
which are standardized by one of the C standards.
You do not mention which operating system you are using, so we are
unable to make specific comments about why your particular system
choose that particular convention (and we probably do not personally
know the people who wrote your operating system in order to write them
and ask for "specific" reasons.)
The best I can do at the moment (other than to refer you to a newsgroup
more specific for your OS) is to comment on a -particular- OS that
uses that particular scheme.
In that particular OS, the OS creators provided mechanisms to
allow users to link routines with the same name as system
library routines. For example, it is often useful to link in
different versions of the code related to malloc() -- e.g., debugging
versions, or versions that use "pools" of fixed blocksize for
efficiency, or versions that allocate from shared memory so that
the memory can be easily given back to the operating system.
Allowing users to use their own versions of routines can become
a bit tricky, especially if you want the users to be sure they
can get at the original, system provided versions. The mechanism
chosen in the -particular- OS I am thinking of, was to use
a system of "strong" and "weak" symbols in libraries. By default,
all symbols in user-compiled code are "strong" symbols. When
the implimentation of a "strong" symbol is linked in, this particular
OS uses it and silently supresses all warnings about overlap with
the "weak" version of the same symbol. If, though, no "strong"
implimentations are linked in, then this linker silently promotes
the first "weak" definition it encountered to become equivilent
to the "strong" version of the symbol, and the linking proceeds.
In this way, if the user provided implimenting code for a
library routine, that implimenting code would be used by the
places in the code that called upon the "strong" symbol, and
the user would not be pestered with warnings about there being
conflicting symbols defined in the library. (This is useful
particularily for symbols which are -not- part of the C standard,
but might be part of some other standard that the user doesn't
happen to be choosing to employ at the time.) But if the user
did not provide an implimentation, then the library version of the
routine would get used. And anywhere that explicitly called
upon the weak symbol (such as from within the other modules of
the system library routines which count on things being done
just the way they expect) then those references would go to the
system routine, not to the user routine.
The convention that the implimenters of this scheme chose was
to name the weak symbol with a leading underscore; then,
to find the corresponding name of the strong symbol in order
to promote the weak symbol to a strong one, all that had to be done
was to remove the leading underscore.
Why an underscore? There are different possible reasons.
Double-underscore was reserved in some contexts. Any particular
alphabetic might have conflicted with a user-defined name.
The library code was often itself written in C, and numbers
are not valid at the beginning of C routine names, so leading
digits could not be used. THe only non-alphabetic non-digit
symbol that is accepted by the C standard as the leading character
in a routine name is underscore. The implimenters could perhaps
have chosen some system such as underscore followed by a digit
for the weak symbols, but at the time it was still important to keep
external identifier names short (especially for use with
Fortran), so a single underscore was the easiest choice.
--
This signature intentionally left... Oh, darn!
