I was just rereading ANSI C X3J11 and noticed that strftime and mktime are in there. Since POSIX is a superset (by definition) of ANSI C, POSIX will have strftime and mktime, it isn't an option.
Actually, at the working group meeting last week, we changed the definition of POSIX a little bit. X/OPEN had some reservations about POSIX requiring X3J11, because it would increase the time before there could be conforming systems. Also, a number of people from different implementors felt that when their companies had signed onto the POSIX concept, they had not necessarily bought into X3. These same people also said that they were planning on providing an X3 conforming environment, but not in the same timeframe as POSIX. As a result of these discussions, we redefined the terms CONFORMING APPLICATION and CONFORMING PORTABLE APPLICATION. The new names are PORTABLE APPLICATION USING EXTENSIONS and POSIX CONFORMING <language> APPLICATION. The text of these definitions is: Portable Application Using Extensions A Portable Application Using Extensions shall meet the following requirements: All extensions beyond those permitted to a Posix Conforming Language Application and the corresponding language shall be clearly documented. The application developer documents all application requirements for the operating environment that are implementation dependent including <limits.h> S2.9 characteristics and other related configuration requirements (linear address space, file store requirements, etc.) POSIX Conforming Applications POSIX Conforming Standard C Language Application A POSIX Conforming Standard C Language Application is a strictly conforming program, as defined in the ANSI/X3.159-198x standard, which utilizes only those extensions as described by the service bindings in this standard. In addition, a POSIX Conforming Standard C Language Application shall not depend on any unspecified, undefined, or implementation defined behavior, nor shall it require that any symbolic constant in <limits.h> S2.9 be outside its most restrictive value. As a result of these changes, it is possible to have a Conforming Implementation of POSIX that does not supply an X3 conforming environment. What environment it does provide is unspecified at this time, but the P1003.1 Working Group expects to see something from X/OPEN about a K&R C Language binding, which uses the X/OPEN Portability Guide as the basis for the C Language and its libraries. The unfortunate implication of all this is that strftime and friends are not really required by the POSIX standard. And since the POSIX Working Group decided at the December meeteing to defer to X3 in all things relating to time, the issue is a bit confused. -- Shane P. McCarron UUCP ihnp4!meccts!ahby, ahby@MECC.MN.ORG MECC Technical Services ATT (612) 481-3589 Secretary, IEEE P1003.1
Date: 30 Apr 87 21:32:08 CDT (Thu) From: ahby@meccts.mecc.mn.org (Shane P. McCarron) Message-ID: <8704302132.AA14158@meccts.MECC.MN.ORG> Actually, at the working group meeting last week, we changed the definition of POSIX a little bit. I have always believed that the POSIX working group was comprised of emminently reasonable and sensible people, and this decision confirms it. Unlike X3J11 which seems to have taken off on the road of innovation, POSIX is very sensibly confining itself to standardisation. Please convey my appreciation to the group at the next meeting. The unfortunate implication of all this is that strftime and friends are not really required by the POSIX standard. I don't agree that this is unfortunate. These functions are innovation, and simply don't belong in POSIX, regardless of how useful they might be. In fact, its not clear to me that they would belong in POSIX in any case. Methods of formatting strings for output don't seem to belong in an operating systems standard. They do legitimately belong in a language standard. I know this whole issue is very much confused by the strong linage between POSIX and C. As a test whether something belongs or not, I would ask a question something like this ... "Would this still be the natural and proper way to perform the function inother (procedural) languages?" If the answer is yes, then the function properly belongs in POSIX, if no, then it belongs in the language specification. For example, the functionality of localtime() is to convert a binary internal time format to a struct containing integers representing the time. In Pascal a similar function would be natural (returning a record). In Fortran, again it would be natural to use a function for this purpose (returning an array). Similarly in Modula, Ada, Algol, etc. Strftime() taking a format string, and a struct, and producing a string containing the formatted time is a perfectly natural C operation, but isn't the way the operation would usually be expressed in other languages. In fact, its doubtful if nost other languages would have any immediate use for such an operation at all, this being more commonly performed as an output routine, with the formatted data appearing only on the external file. I confine the test to procedural languages, as the interface to POSIX is a procedural one, testing a proposed function against Smalltalk is not likely to give useful results. I think that if POSIX were to attempt to define more than is necessary for the operating system and its interface (in P1003.1) it will unnecessarily inhibit any future possibility of creating bindings for other languages. And since the POSIX Working Group decided at the December meeteing to defer to X3 in all things relating to time, the issue is a bit confused. I think this was a mistake, regardless of the dependance on X3J11. X3J11 is concerned to make sure that C programs can run in a variety of environments, not only POSIX. Because of that there are some things that they need to leave unspecified. The representation of times is one of those, they cannot really even depend on GMT being available. However, POSIX doesn't have this problem, it can, and should, specify th details of things such as exactly what a time_t is, and what range of times must be representable. So, I would appreciate it if you could suggest to the POSIX group that they reconsider that December decision, and return the fundamental operations on times to POSIX. I believe those to be a definition of time_t, the function time(), gmtime(), and localtime(). I do not really believe that asctime() (or ctime()) really belong in POSIX, though pragmatic considerations might dictate that they be included. Usage of the environment variable TZ clearly does belong. It would be nice to see (a reasonable definition of) mktime() included, however this falls into innovation, and should be left to a later revision. Robert Elz
participants (2)
-
Robert Elz -
seismo!meccts.mecc.mn.org!ahby