hi Garrett,All.
Thanks for your comments. The intent of my mail is
really a heads up at this stage on what possibly might
be coming since we asked for notice by Jan 9. No decisions
are made on if and how they will be merged. That discussion
will start in Ottawa.
regards
Andrew
On Jan 9, 2:47pm in "Proposed submissions", Garrett Wollman wrote:
> <<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
>-- End of excerpt from Garrett Wollman
|