Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!uwm.edu!rpi!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!usenix!std-unix
From: donn@hpfcrn.fc.hp.com (Donn Terry)
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Message-ID: <422@usenix.ORG>
Date: 4 Aug 90 17:23:33 GMT
References: <405@usenix.ORG> <415@usenix.ORG>
Sender: std-unix@usenix.ORG
Reply-To: std-unix@uunet.uu.net
Lines: 49
Approved: jsq@usenix.org (Moderator, John Quarterman)

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