Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 30 Oct 1999 15:59:08 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
Cc:        jin@george.lbl.gov, freebsd-bugs@FreeBSD.ORG, sheldonh@uunet.co.za
Subject:   Re: bin/14472: date for Y#K
Message-ID:  <Pine.BSF.4.10.9910301535310.8879-100000@alphplex.bde.org>
In-Reply-To: <199910292000.QAA96945@khavrinen.lcs.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Oct 1999, Garrett Wollman wrote:

> <<On Fri, 29 Oct 1999 12:18:30 -0700 (PDT), jin@george.lbl.gov said:
> 
> > What happens if we change the definition of _BSD_TIME_T to int64_t?
> > Is it a performance issue or may it break an enormous things?
> 
> Filesystems and many system calls break.

More details:
(1) Fields in ffs's super block and cylinder group block and ufs's disk quota
    struct that are incorrectly declared as having type time_t will break.
    These fields must have size 4 octets for binary compatibility with old
    file systems.
(2) Timestamp fields in ufs' dinode struct are declared as having type int32_t
    to give binary compatibility.  These won't break, but they won't actually
    hold 64-bit time_t's either.
(3) I think the breakage of system calls is limited to binary incompatibility,
    mainly for time_t's in structs.

> > "long" seems to be a bad type definition in C program since it is not in
> > a fixed variable size.
> 
> As Nate has pointed out, no C type is fixed in size.

time_t actually has to have size 32 bits with no padding to avoid breaking
filesystems (see (1)).  Thus _BSD_TIME_T must not be declared as "long"
on alphas; it is actually declared as "int".  On i386's, both "int" and
"long" nomally have size 32 bits with no padding, so either can be used.
"long" is used mainly to avoid exposing bad assumptions that time_t is
"long".

Bruce



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9910301535310.8879-100000>