> You could say that there's no such thing as "C library functions".

Sure there are.

> There *are* libraries of functions that are available on
> various releases
> of Unix (and, indeed, most are intended to be called from C) ...
> but that doesn't give them the same air of respectability
> that the phrase
> "C library function" would seem to bestow.

The set of standard C library functions is as old as Standard C
itself: ANS X3.159-1989, which became ISO/IEC 9899:1990, specifies 15
standard header files and the library functions introduced by those
headers. Normative Addendum 1 to ISO/IEC 9899:1990 added a number of
additional required library functions, most related to localization
issues. I haven't yet figured out if the "C99" version added any more.
Any C compiler that wants to claim compliance with the standard--which
effectively means any C compiler that wants to get sold--must support
the standard library functions.

IEEE 1003.1, the Posix specification, also specifies mandatory library
functions.

However, there are numerous non-mandatory functions that, as Stan
mentions, have been around for a long time, may or may not appear in
any given implementation, and can't be relied on by code that wants to
be portable. 'itoa' and 'ltoa' both fall into this category; the
"Standard C way" (and the expensive way, which is why 'ltoa' exists)
to get a string representation of a numeric value is ssprintf().

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *