I believe the way out of this 'who should do it?' problem is
to only place those functions that are uniquely OS-related into POSIX.
They are 'time()' and 'stime()'. Our task would then be to decide
what arguments they take and what errors are defined.
X3J11 should deal with the C library functions -- those in
section 3 of some Unix manuals.
This isn't an adequate definition of a "C library function".
"getpwent" is in section 3 of some UNIX manuals, but it is definitely
not a C function.
Additional functions can be created within the domain of
X3J11 but these should not be required for POSIX. As Robert
Elz and others pointed out, POSIX should be the base on which
different language environments may run. Imagine how a
program would be written using Pascal's date/time
manipulation functions. There probably won't be an asctime()
call.
I wouldn't bet on that. There may have to be some equivalent
procedure; Pascal doesn't *have* any date/time manipulation
functions. Frankly, I don't think C should have them, either.
The standard UNIX library is called the "C library", but this is a
misnomer. It contains some functions that may be considered language
support for C, some functions that can be considered part of the
operating system, and some functions that are really just useful
utilities.
The Standard I/O library routines are probably best considered to be
language support for C (one might also consider them to be part of
the operating system, except that the same interfaces have been
implemented under other operating systems, and the intent seems to be
that all C implementations should have those routines). "open" is
clearly part of the operating system, as is "getpwent". "lsearch" is
clearly just a utility; the code for "lsearch" could be transplanted
to another OS with no trouble (except for possibly writing a "memcpy"
routine), and could also be rewritten in any other language that
supports the requisite data types.
Neither POSIX nor X3J11 includes "lsearch". Although this means that
portable code can't use it (or other potentially more interesting
utility routines), this is arguably the correct thing to do.
However, X3J11 includes some routines that could be considered
utility routines or operating system interfaces. The date/time
conversion routines fall into these categories:
If the format of a "time_t" is considered to be a
characteristic of the operating system (since, in most cases,
it is the OS that supplies date/time information),
"localtime" and "gmtime" are really operating system
interfaces.
"asctime" is clearly a utility, since it can be expressed in
any sufficiently expressive language in an operating-system
independent fashion (note that, in fact, a portable
implementation of "asctime" is published as part of the
current X3J11 draft!). The same is true of "ctime" (for
which a portable implementation is also published).
"strftime" could also be considered a utility routine, except
that it is dependent on the "locale", which is currently
considerered part of the C environment. As long as the
"locale" is considered part of the C environment, and *not* a
part of the operating system, "strftime" should be a part of
the C standard.
If the ANSI C standard included a definition of low-level routines
for obtaining, say, the locale's full name for a month, given a month
number of that month, "strftime" could also be written in portable
ANSI C and published in the X3J11 draft. It does not include any
OS dependencies.
I would argue that this sort of "internationalization" belongs
neither in an OS standard nor in a language standard; there should be
a separate standard which, like e.g. various graphics standards, has
bindings for several languages and can be implemented under various
OSes. I'm not sure *where* the time-related stuff (i.e., the stuff
that deals with "struct tm" values) belongs, although I'd argue in
favor of putting it in POSIX.
Unfortunately, I don't think the time-related and
internationalization stuff is going to be moved out of ANSI C, and
I'm also not sure how to split the OS-related and
internationalization-environment-related time handling stuff between
POSIX and some C-language or other-language binding of an
internationalization standard.
