[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.
> > >
> > >       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.

                                 ( 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: