Re: projected life of the ext2 filesystem format
> > In article <[🔎] Pine.A32.3.93.980129115217.42428A-100000@seminole.gate.net>,
> > Scott Ellis <storm@gate.net> wrote:
> > >Well, since the time function is documented as returning -1 on errors,
> > >that pretty much rules out time_t being unsigned.
> > >
> > >RETURN VALUE
> > > On success, the value of time in seconds since the Epoch
> > > is returned. On error, ((time_t)-1) is returned, and
> > > errno is set appropriately.
> >
> >
> > Note that there's an explicit cast to time_t. It is not nessecarily
> > true that (time_t)-1 == (int)-1. It could be true that
> > (time_t)-1 == (unsigned int)-1
>
> Okay, point made. However, a vast majority of code out there (I assume)
> is probably written to assume that time_t is signed, I expect making it
> unsigned will break more than it's worth. And I still think that you
> should be able to use a negative time_t as seconds before the epoch.
If the code has already been compiled, then it won't make any difference
since (int)(-1) and (unsigned int)(-1) are necessarily identical numbers.
If you compile the code, you'll get a warning from GCC about comparing
signed and unsigned numbers. This will make the mistake (and it _is_ a
mistake) fairly obvious.
Using time_t as a date storage mechansism is probably not wise overall
because of these limitations. Even allowing negative time_t doesn't
solve the problem of representing a date in 1901.
Brian
( bcwhite@verisim.com )
-------------------------------------------------------------------------------
Generated by Signify v1.03. For this and more, visit http://www.verisim.com/
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: