home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 January
/
usenetsourcesnewsgroupsinfomagicjanuary1994.iso
/
sources
/
std_unix
/
v21
/
010
< prev
next >
Wrap
Internet Message Format
|
1990-12-05
|
2KB
From uucp@tic.com Sat Aug 4 23:12:38 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
id AA17393; Sat, 4 Aug 90 23:12:38 -0400
Posted-Date: 4 Aug 90 17:29:20 GMT
Received: by cs.utexas.edu (5.64/1.68)
id AA22230; Sat, 4 Aug 90 22:12:36 -0500
Received: by longway.tic.com (4.22/tic.1.2)
id AA00431; Sat, 4 Aug 90 21:13:18 cdt
From: Donn Terry <donn@hpfcrn.fc.hp.com>
Newsgroups: comp.std.unix
Subject: Re: is struct utimbuf in the standard sys/types.h?
Message-Id: <10885@cs.utexas.edu>
Sender: fletcher@cs.utexas.edu
Reply-To: std-unix@uunet.uu.net
Date: 4 Aug 90 17:29:20 GMT
Apparently-To: std-unix-archive@uunet.uu.net
From: Donn Terry <donn@hpfcrn.fc.hp.com>
(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.
Donn Terry
Same disclaimer.
Volume-Number: Volume 21, Number 10