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