arnold@audiofax.com (Arnold Robbins) (07/30/90)
From: arnold@audiofax.com (Arnold Robbins) Can someone with access to the 1003.1 standard tell me if the utime(2) system call is standardized, and if so if the definition of struct utimbuf is supposed to be in a particular header file? While we're at it, can anyone tell me why the stupid structure never made it into <sys/types.h>, and instead has to be redeclared over and over and over again from the man page??!? Sheesh. As they used to say in ancient net history, ``Thanks In Advance,'' -- Arnold Robbins AudioFAX, Inc. | Laundry increases 2000 Powers Ferry Road, #220 / Marietta, GA. 30067 | exponentially in the INTERNET: arnold@audiofax.com Phone: +1 404 933 7600 | number of children. UUCP: emory!audfax!arnold Fax: +1 404 933 7606 | -- Miriam Robbins Volume-Number: Volume 20, Number 149
heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) (08/01/90)
From: heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) My understanding is that not only has the utimbuf structure been standardized and included in sys/utime.h, but it was changed in a manner incompatible with current practice. Since the beginning of time, the structure has been documented as being a pair of time_t values (usually longs), the first specifying the access time and the second specifying the modification time. Now, it's been defined to be four time_t values. The additional two are for additional microseconds beyond the existing time in seconds. Do you think maybe the two new values could be put at the end of the structure where they would do little harm? No way! Where the modification time value *used* to be, now we find microseconds tacked onto the access time value. Also, since there was never before a header file for utimbuf, everyone who uses it has it hard coded into their own code (or their own .h file, if they're lucky). The thing that really gripes me about this is that I haven't found anyone who can explain to me why the access and modification times for a file have to be settable to the microsecond. It's simply ridiculous! -- Ron Heiby, heiby@chg.mcd.mot.com Moderator: comp.newprod "Mandatory Drug Testing? Just Say NO!!!" Volume-Number: Volume 20, Number 155
heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) (08/03/90)
From: heiby@mcdchg.chg.mcd.mot.com (Ron Heiby) I apologize for some inaccuracy in my previous article. As I've not yet managed to get my boss to get a copy of 1003.1 for the office, I was relying on my Release 1.1 Binary Compatibility Standard from the 88open Consortium Ltd. That document shows the microsecond elements included in the structure. According to another posting in this group, it seems that adding such items, although of questionable desirability, is allowed and not mandated by 1003.1 and is no longer allowed in the 1990 revision. I wonder what happens to the 88open BCS, when it is no longer compliant with 1003? BTW, I also happened to check my SVID, Issue 2, Volume 1, page 144. It says that utimbuf must have just the two time_t values. -- Ron Heiby, heiby@chg.mcd.mot.com Moderator: comp.newprod "Mandatory Drug Testing? Just Say NO!!!" Volume-Number: Volume 21, Number 7
guy@auspex.uucp (Guy Harris) (08/04/90)
From: guy@auspex.uucp (Guy Harris) >My understanding is that not only has the utimbuf structure been >standardized and included in sys/utime.h, but it was changed in >a manner incompatible with current practice. Your understanding is incorrect, if you're thinking of IEEE Std 1003.1-1988. Your description of the alleged change sounds like a description of the arguments to the 4.[2andup]BSD "utimes" call (*not* "utime" - that's still in 4.[2andup]BSD, and is specified to act in the V7 fashion - see below), which takes a pointer to an array of two "struct timeval"s, each one having a "tv_sec" and "tv_usec" member. IEEE Std 1003.1-1988 says, on page 104, that The 'utimbuf' structure is defined by the header <utime.h>, and includes the following members: Member Member Type Name Description ______ ______ ___________ time_t actime Access time time_t modtime Modification time which is just what S5 does (and what V7 did, more or less, although it took a pointer to an array of two "time_t"s - this would *probably* have the same binary format as the structure in question). Volume-Number: Volume 21, Number 4
donn@hpfcrn.fc.hp.com (Donn Terry) (08/05/90)
From: Donn Terry <donn@hpfcrn.fc.hp.com> (For string "is struct utimbuf...".) Don Heiby writes about the changes to utimbuf, with comments about the addition of microseconds, field ordering, and the use of a .h file. 1) The microseconds fields are present in some versions of UN*X, not in others. However, they ARE NOT present in POSIX. I believe you have confused implementation with specification. (I have the standard in front of me this instant, open to page 104.) (Watch out for ABIs, where the ordering IS important; however POSIX isn't and never will be an ABI.) 2) No-where in POSIX is there any specification about the order of fields in a structure. The members are just listed. Thus *if* microseconds were present, they could be moved around in various implementations. 3) My understanding is that make(1) can and does break in some systems if the access times are not of a finer resolution that seconds. This could be particularly true for a machine like an Amdahl, where the make of the kernel only takes about a minute. 4) It was recognized that hardcoding the utimbuf header was common practice. However, it was also recognized that portability of applications would NOT be served, because if a vendor wished to put in something like microseconds he could not do so unless the source for utimbuf was under his control, not the user's. This led to a lot of debate before it was done, but then the goal was portability of applications written to be portable, not to endorse every wierd possible implementation and variation. It was not expected that every existing program would suddenly become POSIX conforming. In this case, without the header, one of AT&T-derived or Berkeley-derived systems would have "lost". With the header, the application makes a straightforward change, and then it will run without modifications on both (presuming they're POSIX conformant) and the location of the microseconds field doesn't change. 5) Existing programs on existing systems, where the applicaiton doesn't "want" to be POSIX conformant can just ignore <utime.h>. Presumably the vendors provide backwards object (and source?) compatability to applications that used to run on that same implementation. Donn Terry, Chair 1003.1 Usual disclaimer about these being my opinons, not IEEE's, P1003.1's, or HP's. Volume-Number: Volume 21, Number 5
donn@hpfcrn.fc.hp.com (Donn Terry) (08/05/90)
From: Donn Terry <donn@hpfcrn.fc.hp.com> (For string "is struct utimbuf...".) Don Heiby writes about the changes to utimbuf, with comments about the addition of microseconds, field ordering, and the use of a .h file. 1) The microseconds fields are present in some versions of UN*X, not in others. However, they ARE NOT present in POSIX. I believe you have confused implementation with specification. (I have the standard in front of me this instant, open to page 104.) (Watch out for ABIs, where the ordering IS important; however POSIX isn't and never will be an ABI.) 2) No-where in POSIX is there any specification about the order of fields in a structure. The members are just listed. Thus *if* microseconds were present, they could be moved around in various implementations. 3) My understanding is that make(1) can and does break in some systems if the access times are not of a finer resolution that seconds. This could be particularly true for a machine like an Amdahl, where the make of the kernel only takes about a minute. 4) It was recognized that hardcoding the utimbuf header was common practice. However, it was also recognized that portability of applications would NOT be served, because if a vendor wished to put in something like microseconds he could not do so unless the source for utimbuf was under his control, not the user's. This led to a lot of debate before it was done, but then the goal was portability of applications written to be portable, not to endorse every wierd possible implementation and variation. It was not expected that every existing program would suddenly become POSIX conforming. In this case, without the header, one of AT&T-derived or Berkeley-derived systems would have "lost". With the header, the application makes a straightforward change, and then it will run without modifications on both (presuming they're POSIX conformant) and the location of the microseconds field doesn't change. 5) Existing programs on existing systems, where the applicaiton doesn't "want" to be POSIX conformant can just ignore <utime.h>. Presumably the vendors provide backwards object (and source?) compatability to applications that used to run on that same implementation. Donn Terry, Chair 1003.1 Usual disclaimer about these being my opinons, not IEEE's, P1003.1's, or HP's. Volume-Number: Volume 21, Number 9
donn@hpfcrn.fc.hp.com (Donn Terry) (08/05/90)
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
donn@hpfcrn.fc.hp.com (Donn Terry) (08/05/90)
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
guy@auspex.uucp (Guy Harris) (08/06/90)
Submitted-From: auspex!guy@uunet.UU.NET (Guy Harris) From: guy@auspex.uucp (Guy Harris) > In this case, without the header, one of AT&T-derived or Berkeley-derived > systems would have "lost". Actually, BSD being an AT&T-derived system, things aren't that bad. BSD still has the original V7-flavored "utime()" call, with the second argument a pointer to the first element of an array of 2 "time_t"s (that's right, "utime()" in BSD has no microseconds-field support). Somewhere in the "USG UNIX" chain, the structure was introduced; on most systems, the structure has the same memory layout as the array. 4.2BSD introduced a call named "utimes()" - note the "s" - that takes a pointer to an array of 2 "struct timeval"s; that's the call that supports microseconds fields. Too bad the 88Open folks didn't pay attention to this, and just called their call that supported microseconds fields "utime()".... Volume-Number: Volume 21, Number 12
buck@siswat.lonestar.org (08/06/90)
From: buck@siswat.uucp > 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. 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
guy@auspex.uucp (Guy Harris) (08/08/90)
From: guy@auspex.uucp (Guy Harris) >I am having some difficulty following the above. How can a portable >application do anything to vendor-defined fields? That's precisely the problem. >Isn't the application non-portable as soon as it does anything (read or write) >to a vendor-defined field? Yup. Unfortunately, the application is non-functional (at least not *correctly* functional) if it *doesn't* initialize the vendor-defined fields of a structure that's handed to the system, unless the system can somehow always figure out that they haven't been initialized - e.g., if there's some flag field in the structure that *is* specified by the standard, and you have to set some flag in that field *not* specified by the standard in order to get the system to look at the other fields not in the standard. Unfortunately, in the case of "utime()", there's no such flag, so a portable application can, at best, only avoid setting the microseconds values of a file's accessed or modified times to some random value by "memset"ting the entire "utimbuf" structure to zero before filling it in and using it (or otherwise ensuring that the structure is zero before using it, e.g. using a static structure). Volume-Number: Volume 21, Number 20
karish@mindcraft.com (08/08/90)
Submitted-From: mindcrf!karish@ucbvax.Berkeley.EDU From: karish@mindcraft.com In article <10980@cs.utexas.edu> guy@auspex.uucp (Guy Harris) writes: |Unfortunately, the application is non-functional (at least not |*correctly* functional) if it *doesn't* initialize the vendor-defined |fields of a structure that's handed to the system ... |... a |portable application can, at best, only avoid setting the microseconds |values of a file's accessed or modified times to some random value by |"memset"ting the entire "utimbuf" structure to zero before filling it in |and using it (or otherwise ensuring that the structure is zero before |using it, e.g. using a static structure). Keeping in mind, of course, that memset() may not be present on a POSIX system that provides common-usage C language-dependent support. Another ugly way to initialize the storage would be to make liberal use of calloc() and free(). -- Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000 Volume-Number: Volume 21, Number 22
donn@hpfcrn.fc.hp.com (Donn Terry) (08/09/90)
From: Donn Terry <donn@hpfcrn.fc.hp.com> (more for "is struct utimbuf". >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"? The point is that a portable application CAN'T know the names of the fields (otherwise it's not portable). Given that, how does it initialize them. It can't. Given that it can't, introducing extensions to structures that are not initialized by the OS, and which don't have an "enable feature" flag (as do some of the I/O related stuff with flag words) is a bad idea. (The "enable feature" flags get you out because setting bits other than those defined by the standard gets you into the "unspecified" space, thus the portable application cannot set those bits.) Donn Terry Same old disclaimer, again. Volume-Number: Volume 21, Number 25