home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 025 < prev    next >
Internet Message Format  |  1990-12-05  |  1KB
  1. From jsq  Tue Aug 14 21:10:47 1990
  2. Received: by uunet.uu.net (5.61/1.14) 
  3.     id AA13384; Tue, 14 Aug 90 21:10:47 -0400
  4. From: Donn Terry <donn@hpfcrn.fc.hp.com>
  5. Newsgroups: comp.std.unix
  6. Subject: Re: is struct utimbuf in the standard sys/types.h?
  7. Message-Id: <11027@cs.utexas.edu>
  8. Sender: fletcher@cs.utexas.edu
  9. Reply-To: std-unix@uunet.uu.net
  10. Date: 8 Aug 90 22:59:59 GMT
  11. Apparently-To: std-unix-archive
  12.  
  13. From:  Donn Terry <donn@hpfcrn.fc.hp.com>
  14.  
  15. (more for "is struct utimbuf".
  16.  
  17. >I am having some difficulty following the above.  How can a portable
  18. >application do anything to vendor-defined fields?  Isn't the
  19. >application non-portable as soon as it does anything (read or write)
  20. >to a vendor-defined field?
  21.  
  22. >Is this explained by "strictly conforming" vs. "conforming"?
  23.  
  24. The point is that a portable application CAN'T know the names of the
  25. fields (otherwise it's not portable).  Given that, how does it initialize
  26. them.  It can't.  Given that it can't, introducing extensions to structures
  27. that are not initialized by the OS, and which don't have an "enable feature"
  28. flag (as do some of the I/O related stuff with flag words) is a bad idea.
  29. (The "enable feature" flags get you out because setting bits other than
  30. those defined by the standard gets you into the "unspecified" space, thus
  31. the portable application cannot set those bits.)
  32.  
  33. Donn Terry
  34. Same old disclaimer, again.
  35.  
  36.  
  37. Volume-Number: Volume 21, Number 25
  38.  
  39.