Path: utzoo!attcan!uunet!cs.utexas.edu!fletcher From: buck@siswat.lonestar.org Newsgroups: comp.std.unix Subject: Re: is struct utimbuf in the standard sys/types.h? Message-ID: <10937@cs.utexas.edu> Date: 6 Aug 90 06:42:00 GMT References: <423@usenix.ORG> Sender: fletcher@cs.utexas.edu Reply-To: std-unix@uunet.uu.net Lines: 36 Approved: fletcher@cs.utexas.edu (Guest Moderator, Fletcher Mattox) From: buck@siswat.uucp > From: Donn Terry > (More to "is struct utimbuf...") > > Don Lewine's posting reminded me (I can't remember EVERYTHING) about > the issue of additional fields in structures. All my comments in my > previous posting stand, but apply primarily to structures that are > filled in (at least initially) by the system. For ones that are > sent to the system, created from "nowhere", there is an additional > problem, that of "how can a portable application know to/how to > initialize additional (vendor-defined) fields?". > > The solution in the 1990 revision is to prohibit additional fields > for the structures like that. (A vendor is then required to provide > a new call to set microseconds, or whatever.) > > It was agreed that this was not the most desireable solution, but it > was the only one that worked. I am having some difficulty following the above. How can a portable application do anything to vendor-defined fields? Isn't the application non-portable as soon as it does anything (read or write) to a vendor-defined field? Is this explained by "strictly conforming" vs. "conforming"? Thanks, --- A. Lester Buck buck@siswat.lonestar.org ...!texbell!moray!siswat!buck Volume-Number: Volume 21, Number 13