🚀 go-pugleaf

From:  Don_Lewine%dgc.ceo.dg.com@RELAY.CS.NET

CEO document contents:

In article <405@usenix.ORG> <uunet!samsung.com!audfax!arnold> writes:
>From:  arnold@audiofax.com (Arnold Robbins)
>
>Can someone with access to the 1003.1 standard tell me if the utime(2)
>system call is standardized, and if so if the definition of struct utimbuf
>is supposed to be in a particular header file?


>From POSIX 5.6.6.1:
       #include <sys/types.h>
       #include <utime.h>

       Int utime(path,times)
       char *path;
       struct utimebuf *times;

>From 5.6.6.2:
The utimbuf structure is defined by the header <utime.h>, and included the
following members:
       TYPE    NAME            Description
       time_t  actime          Access time
       time_t  modtime         Modification time

The 1990 revision of 1003.1 changes the definition to use an ANSI prototype:
       int utime(char *path, struct utimebuf *times);
and add the restriction the the utimebuf structure may not contain any members
other than the ones listed in the standard.

Note that utime() is the only function [I believe] where a structure is passed
into the system without having been obtained by a prior library call.  This 
makes it "special".  I would guess that this is why AT&T never put it into a
header file.

                       --Donald Lewine
                       uunet!dg!lewine

Volume-Number: Volume 20, Number 153

From:  heiby@mcdchg.chg.mcd.mot.com (Ron Heiby)

My understanding is that not only has the utimbuf structure been
standardized and included in sys/utime.h, but it was changed in
a manner incompatible with current practice.  Since the beginning
of time, the structure has been documented as being a pair of
time_t values (usually longs), the first specifying the access
time and the second specifying the modification time.  Now, it's
been defined to be four time_t values.  The additional two are
for additional microseconds beyond the existing time in seconds.
Do you think maybe the two new values could be put at the end
of the structure where they would do little harm?  No way!  Where
the modification time value *used* to be, now we find microseconds
tacked onto the access time value.  Also, since there was never
before a header file for utimbuf, everyone who uses it has it hard
coded into their own code (or their own .h file, if they're lucky).
The thing that really gripes me about this is that I haven't found
anyone who can explain to me why the access and modification times
for a file have to be settable to the microsecond.  It's simply
ridiculous!
-- 
Ron Heiby, heiby@chg.mcd.mot.com	Moderator: comp.newprod
"Mandatory Drug Testing?  Just Say NO!!!"

Volume-Number: Volume 20, Number 155

From:  heiby@mcdchg.chg.mcd.mot.com (Ron Heiby)

I apologize for some inaccuracy in my previous article.  As I've not
yet managed to get my boss to get a copy of 1003.1 for the office,
I was relying on my Release 1.1 Binary Compatibility Standard from
the 88open Consortium Ltd.  That document shows the microsecond
elements included in the structure.  According to another posting
in this group, it seems that adding such items, although of questionable
desirability, is allowed and not mandated by 1003.1 and is no longer
allowed in the 1990 revision.  I wonder what happens to the 88open
BCS, when it is no longer compliant with 1003?  BTW, I also happened
to check my SVID, Issue 2, Volume 1, page 144.  It says that utimbuf
must have just the two time_t values.
-- 
Ron Heiby, heiby@chg.mcd.mot.com	Moderator: comp.newprod
"Mandatory Drug Testing?  Just Say NO!!!"


Volume-Number: Volume 21, Number 7

From:  guy@auspex.uucp (Guy Harris)

>My understanding is that not only has the utimbuf structure been
>standardized and included in sys/utime.h, but it was changed in
>a manner incompatible with current practice.

Your understanding is incorrect, if you're thinking of IEEE Std
1003.1-1988.  Your description of the alleged change sounds like a
description of the arguments to the 4.[2andup]BSD "utimes" call (*not*
"utime" - that's still in 4.[2andup]BSD, and is specified to act in the
V7 fashion - see below), which takes a pointer to an array of two
"struct timeval"s, each one having a "tv_sec" and "tv_usec" member. 

IEEE Std 1003.1-1988 says, on page 104, that

	The 'utimbuf' structure is defined by the header <utime.h>, and
	includes the following members:

		Member		Member
		 Type		 Name		Description
		______		______		___________
		time_t		actime		Access time
		time_t		modtime		Modification time

which is just what S5 does (and what V7 did, more or less, although it
took a pointer to an array of two "time_t"s - this would *probably* have
the same binary format as the structure in question).

Volume-Number: Volume 21, Number 4

From:  Donn Terry <donn@hpfcrn.fc.hp.com>

(For string "is struct utimbuf...".)

Don Heiby writes about the changes to utimbuf, with comments about
the addition of microseconds, field ordering, and the use of a .h file.

1) The microseconds fields are present in some versions of UN*X, not in
   others.  However, they ARE NOT present in POSIX.  I believe you have
   confused implementation with specification.   (I have the standard
   in front of me this instant, open to page 104.)  (Watch out for
   ABIs, where the ordering IS important; however POSIX isn't and
   never will be an ABI.)

2) No-where in POSIX is there any specification about the order of fields
   in a structure.  The members are just listed.  Thus *if* microseconds
   were present, they could be moved around in various implementations.

3) My understanding is that make(1) can and does break in some systems if
   the access times are not of a finer resolution that seconds.  This
   could be particularly true for a machine like an Amdahl, where the
   make of the kernel only takes about a minute.

4) It was recognized that hardcoding the utimbuf header was common practice.
   However, it was also recognized that portability of applications would
   NOT be served, because if a vendor wished to put in something like 
   microseconds he could not do so unless the source for utimbuf was under
   his control, not the user's.  This led to a lot of debate before it
   was done, but then the goal was portability of applications written to
   be portable, not to endorse every wierd possible implementation and
   variation.  It was not expected that every existing program would
   suddenly become POSIX conforming.  In this case, without the header,
   one of AT&T-derived or Berkeley-derived systems would have "lost".
   With the header, the application makes a straightforward change, and
   then it will run without modifications on both (presuming they're
   POSIX conformant) and the location of the microseconds field doesn't
   change.

5) Existing programs on existing systems, where the applicaiton doesn't
   "want" to be POSIX conformant can just ignore <utime.h>.  Presumably
   the vendors provide backwards object (and source?) compatability 
   to applications that used to run on that same implementation.


Donn Terry, Chair 1003.1
Usual disclaimer about these being my opinons, not IEEE's, P1003.1's,
or HP's.

Volume-Number: Volume 21, Number 5

From:  Donn Terry <donn@hpfcrn.fc.hp.com>

(More to "is struct utimbuf...")

Don Lewine's posting reminded me (I can't remember EVERYTHING) about
the issue of additional fields in structures.  All my comments in my
previous posting stand, but apply primarily to structures that are
filled in (at least initially) by the system.  For ones that are 
sent to the system, created from "nowhere", there is an additional
problem, that of "how can a portable application know to/how to 
initialize additional (vendor-defined) fields?".

The solution in the 1990 revision is to prohibit additional fields
for the structures like that.  (A vendor is then required to provide
a new call to set microseconds, or whatever.)

It was agreed that this was not the most desireable solution, but it
was the only one that worked.

Donn Terry
Same disclaimer.

Volume-Number: Volume 21, Number 6

Submitted-From: auspex!guy@uunet.UU.NET (Guy Harris)
From:  guy@auspex.uucp (Guy Harris)

>   In this case, without the header, one of AT&T-derived or Berkeley-derived
>   systems would have "lost".

Actually, BSD being an AT&T-derived system, things aren't that bad.

BSD still has the original V7-flavored "utime()" call, with the second
argument a pointer to the first element of an array of 2 "time_t"s
(that's right, "utime()" in BSD has no microseconds-field support). 

Somewhere in the "USG UNIX" chain, the structure was introduced; on most
systems, the structure has the same memory layout as the array.

4.2BSD introduced a call named "utimes()" - note the "s" - that takes a
pointer to an array of 2 "struct timeval"s; that's the call that
supports microseconds fields.  Too bad the 88Open folks didn't pay
attention to this, and just called their call that supported
microseconds fields "utime()".... 


Volume-Number: Volume 21, Number 12