home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0004.txt < prev    next >
Encoding:
Internet Message Format  |  1990-10-26  |  2.4 KB
  1. From:  Donn Terry <donn@hpfcrn.fc.hp.com>
  2.  
  3. (For string "is struct utimbuf...".)
  4.  
  5. Don Heiby writes about the changes to utimbuf, with comments about
  6. the addition of microseconds, field ordering, and the use of a .h file.
  7.  
  8. 1) The microseconds fields are present in some versions of UN*X, not in
  9.    others.  However, they ARE NOT present in POSIX.  I believe you have
  10.    confused implementation with specification.   (I have the standard
  11.    in front of me this instant, open to page 104.)  (Watch out for
  12.    ABIs, where the ordering IS important; however POSIX isn't and
  13.    never will be an ABI.)
  14.  
  15. 2) No-where in POSIX is there any specification about the order of fields
  16.    in a structure.  The members are just listed.  Thus *if* microseconds
  17.    were present, they could be moved around in various implementations.
  18.  
  19. 3) My understanding is that make(1) can and does break in some systems if
  20.    the access times are not of a finer resolution that seconds.  This
  21.    could be particularly true for a machine like an Amdahl, where the
  22.    make of the kernel only takes about a minute.
  23.  
  24. 4) It was recognized that hardcoding the utimbuf header was common practice.
  25.    However, it was also recognized that portability of applications would
  26.    NOT be served, because if a vendor wished to put in something like 
  27.    microseconds he could not do so unless the source for utimbuf was under
  28.    his control, not the user's.  This led to a lot of debate before it
  29.    was done, but then the goal was portability of applications written to
  30.    be portable, not to endorse every wierd possible implementation and
  31.    variation.  It was not expected that every existing program would
  32.    suddenly become POSIX conforming.  In this case, without the header,
  33.    one of AT&T-derived or Berkeley-derived systems would have "lost".
  34.    With the header, the application makes a straightforward change, and
  35.    then it will run without modifications on both (presuming they're
  36.    POSIX conformant) and the location of the microseconds field doesn't
  37.    change.
  38.  
  39. 5) Existing programs on existing systems, where the applicaiton doesn't
  40.    "want" to be POSIX conformant can just ignore <utime.h>.  Presumably
  41.    the vendors provide backwards object (and source?) compatability 
  42.    to applications that used to run on that same implementation.
  43.  
  44.  
  45. Donn Terry, Chair 1003.1
  46. Usual disclaimer about these being my opinons, not IEEE's, P1003.1's,
  47. or HP's.
  48.  
  49. Volume-Number: Volume 21, Number 5
  50.  
  51.