home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 010 < prev    next >
Internet Message Format  |  1990-12-05  |  2KB
  1. From uucp@tic.com  Sat Aug  4 23:12:38 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA17393; Sat, 4 Aug 90 23:12:38 -0400
  4. Posted-Date: 4 Aug 90 17:29:20 GMT
  5. Received: by cs.utexas.edu (5.64/1.68)
  6.     id AA22230; Sat, 4 Aug 90 22:12:36 -0500
  7. Received: by longway.tic.com (4.22/tic.1.2)
  8.     id AA00431; Sat, 4 Aug 90 21:13:18 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: <10885@cs.utexas.edu>
  13. Sender: fletcher@cs.utexas.edu
  14. Reply-To: std-unix@uunet.uu.net
  15. Date: 4 Aug 90 17:29:20 GMT
  16. Apparently-To: std-unix-archive@uunet.uu.net
  17.  
  18. From:  Donn Terry <donn@hpfcrn.fc.hp.com>
  19.  
  20. (More to "is struct utimbuf...")
  21.  
  22. Don Lewine's posting reminded me (I can't remember EVERYTHING) about
  23. the issue of additional fields in structures.  All my comments in my
  24. previous posting stand, but apply primarily to structures that are
  25. filled in (at least initially) by the system.  For ones that are 
  26. sent to the system, created from "nowhere", there is an additional
  27. problem, that of "how can a portable application know to/how to 
  28. initialize additional (vendor-defined) fields?".
  29.  
  30. The solution in the 1990 revision is to prohibit additional fields
  31. for the structures like that.  (A vendor is then required to provide
  32. a new call to set microseconds, or whatever.)
  33.  
  34. It was agreed that this was not the most desireable solution, but it
  35. was the only one that worked.
  36.  
  37. Donn Terry
  38. Same disclaimer.
  39.  
  40.  
  41. Volume-Number: Volume 21, Number 10
  42.  
  43.