Xref: utzoo comp.sources.d:6929 comp.mail.elm:4082 comp.sys.m88k:696
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!lanai!ron
From: ron@Eyring.COM (Ron Holt)
Newsgroups: comp.sources.d,comp.mail.elm,comp.sys.m88k
Subject: Re: utime (was "Interesting bug in compress on 88000 Systems")
Message-ID: <1991May6.180127.23911@Eyring.COM>
Date: 6 May 91 18:01:27 GMT
References: <1991May5.005124.3271@xavax.com>
Organization: Eyring, Inc.
Lines: 44

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