home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 January
/
usenetsourcesnewsgroupsinfomagicjanuary1994.iso
/
sources
/
std_unix
/
v21
/
006
< prev
next >
Wrap
Internet Message Format
|
1990-12-05
|
2KB
From uucp@tic.com Sat Aug 4 16:16:50 1990
Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP
id AA05018; Sat, 4 Aug 90 16:16:50 -0400
Posted-Date: 4 Aug 90 17:29:20 GMT
Received: by cs.utexas.edu (5.64/1.68)
id AA05016; Sat, 4 Aug 90 15:16:47 -0500
Received: by longway.tic.com (4.22/tic.1.2)
id AA01773; Sat, 4 Aug 90 15:09:02 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: <423@usenix.ORG>
References: <405@usenix.ORG> <415@usenix.ORG> <422@usenix.ORG>
Sender: std-unix@usenix.ORG
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 6