🚀 go-pugleaf

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