ron@Eyring.COM (Ron Holt) (05/03/91)
Yes, the struct utimbuf issue caused major controversy during the development of the OCS. The main reason it was defined with the usec fields was for compatibility with the BCS interface. It was recognized that adding these fields would cause problems for some existing source code, but since the usec fields could be in the utimbuf struct and still be POSIX.1 conformant they were left in. POSIX.1 simply says that the utimbuf struct includes actime and modtime and does not preclude adding other fields. It could be considered a problem with POSIX that extensions can be added to POSIX structures without saying how applications should treat the extensions in a portable way. -- Ron Holt ron@Eyring.COM uunet!lanai!ron Eyring Inc. +1 801-375-2434 x434
jat@xavax.com (John Tamplin) (05/05/91)
In article <1991May2.180543.12254@Eyring.COM> ron@Eyring.COM (Ron Holt) writes: >Yes, the struct utimbuf issue caused major controversy during the >development of the OCS. The main reason it was defined with the >usec fields was for compatibility with the BCS interface. It was >recognized that adding these fields would cause problems for some >existing source code, but since the usec fields could be in the utimbuf >struct and still be POSIX.1 conformant they were left in. POSIX.1 >simply says that the utimbuf struct includes actime and modtime >and does not preclude adding other fields. It could be considered >a problem with POSIX that extensions can be added to POSIX structures without >saying how applications should treat the extensions in a portable way. The real problem is not that the members were added to the structure -- that is also the case for stat(2), but there is no problem there. utime(2) was originally documented as taking an array as its argument, so programmers followed that documentation and pass an array. Now additional members are added to this structure, but all the programs that used arrays now are broken since element #1 no longer has the same meaning. In the case of stat(2), old code (that doesn't know about the usec fields) won't look at those fields but there isn't a problem since they use a structure definition. My gripe is that the problem could have been fixed by placing the utime fields at the end of the structure passed to utime(2) and it wasn't. -- John Tamplin Xavax jat@xavax.COM 2104 West Ferry Way ...!uunet!xavax!jat Huntsville, AL 35801
ron@Eyring.COM (Ron Holt) (05/07/91)
In article <1991May5.005124.3271@xavax.com> jat@xavax.com (John Tamplin) writes: > >The real problem is not that the members were added to the structure -- that >is also the case for stat(2), but there is no problem there. utime(2) was >originally documented as taking an array as its argument, so programmers >followed that documentation and pass an array. Now additional members are >added to this structure, but all the programs that used arrays now are broken >since element #1 no longer has the same meaning. In the case of stat(2), >old code (that doesn't know about the usec fields) won't look at those fields >but there isn't a problem since they use a structure definition. No, there is a big difference between stat and utime. With stat, a stat structure is never passed back to the kernel. This is not true with utime. Remember, utime is used to set the time, not read it. Thus, the values of all fields passed to the kernel are significant. If the usec fields aren't initialized and contain garbage, several bad things can happen. If the system doesn't actually keep track of time stamps down to the usec level, the uninitialized usec field can cause the seconds field to be rounded up if the garbage value happens to be >= 500,000. The second bad thing that can happen is the usec field could be out of range (> 999,999) and utime will return EINVAL. >My gripe is that the problem could have been fixed by placing the utime fields >at the end of the structure passed to utime(2) and it wasn't. Changing the order of the fields would perhaps make some programs seem to work some of the time. But no matter where the usec fields are located, if they aren't initialized, the problems mentioned above will occur. The only real solution to this backwards compatibility problem would have been to not have added the usec fields in the first place and then either provide no way from the OCS level to set the usecs or to add an additional function to the OCS (with a name other than "utime") that set the usec fields. Neither of these options seemed appealing to the majority of the OCS committee at the time this issue was discussed. I believe the various System V ABIs chose to add usec (or some such fractional seconds) fields to stat yet provided no way to set them with utime. It's sometimes hard to see why a committee made the decisions they made by simply looking at the resultant spec. I wish 88open had created a "Rationale" section to the specs similar to what POSIX and ANSI-C provides. -- Ron Holt ron@Eyring.COM uunet!lanai!ron Eyring Inc. +1 801-375-2434 x434
guy@auspex.auspex.com (Guy Harris) (05/08/91)
>or to add an additional function to the OCS (with a name other than >"utime") that set the usec fields. A name such as, oh, say, "utimes()"? :-) (Yes, "utimes()" is descended from the pre-"struct utimbuf" "utime()", so it takes a pointer to "struct timeval" rather than a pointer to a "struct utimesbuf" or whatever as its argument. That is fixable, of course....)