home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 005 < prev    next >
Internet Message Format  |  1990-12-05  |  3KB
  1. From uucp@tic.com  Sat Aug  4 16:16:15 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA04913; Sat, 4 Aug 90 16:16:15 -0400
  4. Posted-Date: 4 Aug 90 17:23:33 GMT
  5. Received: by cs.utexas.edu (5.64/1.68)
  6.     id AA04977; Sat, 4 Aug 90 15:16:12 -0500
  7. Received: by longway.tic.com (4.22/tic.1.2)
  8.     id AA01752; Sat, 4 Aug 90 15:08:06 cdt
  9. From: Donn Terry <donn@hpfcrn.fc.hp.com>
  10. Newsgroups: comp.std.unix
  11. Subject: Re: is struct utimbuf in the standard sys/types.h?
  12. Message-Id: <422@usenix.ORG>
  13. References: <405@usenix.ORG> <415@usenix.ORG>
  14. Sender: std-unix@usenix.ORG
  15. Reply-To: std-unix@uunet.uu.net
  16. Date: 4 Aug 90 17:23:33 GMT
  17. Apparently-To: std-unix-archive@uunet.uu.net
  18.  
  19. From:  Donn Terry <donn@hpfcrn.fc.hp.com>
  20.  
  21. (For string "is struct utimbuf...".)
  22.  
  23. Don Heiby writes about the changes to utimbuf, with comments about
  24. the addition of microseconds, field ordering, and the use of a .h file.
  25.  
  26. 1) The microseconds fields are present in some versions of UN*X, not in
  27.    others.  However, they ARE NOT present in POSIX.  I believe you have
  28.    confused implementation with specification.   (I have the standard
  29.    in front of me this instant, open to page 104.)  (Watch out for
  30.    ABIs, where the ordering IS important; however POSIX isn't and
  31.    never will be an ABI.)
  32.  
  33. 2) No-where in POSIX is there any specification about the order of fields
  34.    in a structure.  The members are just listed.  Thus *if* microseconds
  35.    were present, they could be moved around in various implementations.
  36.  
  37. 3) My understanding is that make(1) can and does break in some systems if
  38.    the access times are not of a finer resolution that seconds.  This
  39.    could be particularly true for a machine like an Amdahl, where the
  40.    make of the kernel only takes about a minute.
  41.  
  42. 4) It was recognized that hardcoding the utimbuf header was common practice.
  43.    However, it was also recognized that portability of applications would
  44.    NOT be served, because if a vendor wished to put in something like 
  45.    microseconds he could not do so unless the source for utimbuf was under
  46.    his control, not the user's.  This led to a lot of debate before it
  47.    was done, but then the goal was portability of applications written to
  48.    be portable, not to endorse every wierd possible implementation and
  49.    variation.  It was not expected that every existing program would
  50.    suddenly become POSIX conforming.  In this case, without the header,
  51.    one of AT&T-derived or Berkeley-derived systems would have "lost".
  52.    With the header, the application makes a straightforward change, and
  53.    then it will run without modifications on both (presuming they're
  54.    POSIX conformant) and the location of the microseconds field doesn't
  55.    change.
  56.  
  57. 5) Existing programs on existing systems, where the applicaiton doesn't
  58.    "want" to be POSIX conformant can just ignore <utime.h>.  Presumably
  59.    the vendors provide backwards object (and source?) compatability 
  60.    to applications that used to run on that same implementation.
  61.  
  62.  
  63. Donn Terry, Chair 1003.1
  64. Usual disclaimer about these being my opinons, not IEEE's, P1003.1's,
  65. or HP's.
  66.  
  67. Volume-Number: Volume 21, Number 5
  68.  
  69.