On Wed, 26 Jan 2005, Matthias Buelow wrote:

> > Just my thought: why signed 32 bit values? Unsigned should buy something
> > like
> > 100 more years, and I don't think many programs use negative values (but I
> > might be very wrong)
>
> time(3) (and a number other functions that return time_t) returns -1 as an
> error condition.  And time(3) is a standard C function, so it can't just be
> changed.

Standards can and do change.  The Open Group Issue 6 spec, at least, does
not comment on the signedness of time_t except to say that error values for
things like time(3) are "(time_t)-1" -- indicating that unsigned values are
likely allowed by the spec thanks to the cast.

That said, there's a lot of legacy code that does "... < 0" or "... == -1"
rather than the standard specified "... == (time_t)-1", which will break if
time_t is unsigned (but gcc will warn about this condition).

> Apart from that, I seriously hope that in 30+ years, we won't be using C-based
> operating systems anymore but I'm rather sure that I will be disappointed...

C-based operating systems existed 32 years ago, and C has only become more
popular as a language since, so I could definitely see C (and C++)
persisting for another 30+.  We may have major advances in programming
concepts in the interim, and C might not be so popular for user-facing
applications by then, but something still has to provide the lowest level of
operating code to get the higher levels of instruction moving.

Unlike the fast paced PC hardware and Redmond-OS vendors, the "server class"
of operating systems (and hardware) tends to run at a much steadier pace.
There's a reason that names like "ls", "mv", "cp", and "usr" still persist
to this day.  8-)

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>