<<On Mon, 9 Jan 2006 18:47:58 GMT, Andrew Josey <yyyyyy@xxxxxxxxxxxxxxxxx> said:
> <dirent.h>
> alphasort()
> dirfd()
> scandir()
Historic implementations defined an alphasort() that was incompatible
with the type signature required by qsort(). This seems to have been
fixed in FreeBSD and glibc, but (e.g.) OpenSolaris still has the
traditional declaration. I also note that some implementations use
strcmp() and some use strcoll().
> <stdio.h>
> dprintf()
The manual page in my Debian 3.1 reference system says:
These functions are GNU extensions, not in C or POSIX. Clearly, the
names were badly chosen. Many systems (like MacOS) have incompatible
functions called dprintf, usually some debugging version of printf,
perhaps with a prototype like
void dprintf (int level, const char *format, ...);
where the first parameter is a debugging level (and output is to
stderr). Moreover, dprintf (or DPRINTF) is also a popular macro name
for a debugging printf. So, probably, it is better to avoid this func-
tion in programs intended to be portable.
A better name would have been fdprintf.
I think one would be well-advised to heed the man page authors' advice.
> getdelim()
> getline()
The interface seems reasonable, if a bit baroque. Will there be
wide-character versions of these interfaces as well? And why these
and not the much simpler fgetln() interface from 4.4BSD?
> fmemopen()
> open_memstream()
> open_wmemstream()
Is there a reference implementation for these?
> <stdlib.h>
> mkdtemp()
Should be part of the base standard.
> <string.h>
> stpcpy()
> stpncpy()
Rather odd functions of questionable utility. Why these and not
strlcpy()/strlcat() from OpenBSD, which seem to have a wide following
and actually has improved semantics over the functions on which they
are based?
> strsignal()
Should be part of the base standard. It's always been something of a
wart that we have had perror()/strerror() and not psignal()/strsignal(),
given that the two indicators are otherwise very similar in
construction and both are needed for correct implementation of a shell.
> faccessat()
> fchmodat()
> fchownat()
I don't understand the naming of these functions. Surely fchown()
needs no *at() variant, since it already takes a file descriptor as an
argument. Presumably this is what I would expect to called chownat().
Is this (IMO unnecessarily confusing) nomenclature intentional, and if
so why? It seems to exist only in Solaris, of the systems readily
available for me to check; perhaps someone from Sun can comment on the
naming.
-GAWollman
|