tech-kern archive

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

Re: dtime_t

On Thu, Feb 21, 2008 at 07:21:28AM +0000, David Holland wrote:
> On Thu, Feb 21, 2008 at 01:11:25AM +0000, Steven M. Bellovin wrote:
>  > Simon Burge <> wrote:
>  > > and then never used.  I can't see any reason to keep it either - I
>  > > think all on-disk representations used fixed-size integers like
>  > > uint32_t or uint64_t for times.  
> This.
>  > > I'll remove it soonish unless someone else comes up with a good
>  > > reason not to.
>  >
>  > Actually, I suggest leaving it.  A number of people have been talking
>  > about a concerted effort -- I'd guess a branch -- to convert to 64-bit
>  > time; having this around might be a good idea for now.  Delete it
>  > *after* time_t is 64-bit.
> For what?
> I am one of those people, btw. Code should generally be written
> strictly in terms of time_t, and thus not care about the size. In
> cases where the size matters, like in file formats or network
> protocols, or compat code, an explicitly sized type should be used and
> explicitly converted to time_t for processing.
> The only exceptions I can think of to these rules are unfixable messes
> like timed; timed might want its own 32-bit symbolic time type but it
> can and should handle that itself.
> Also, in a world where we have ~30 filesystems (with more likely to
> appear) it doesn't make sense to define on-disk types globally.

Yeah, but if all 30 file systems use the EXACT same on-disk format, making 
a global can be a convenience. It'll make porting a little easier, and 
understanding code a little easier. And if we have one common one and a 
file system DOESN'T use it, we as readers then know something strange is 

Probably the thing to do is change the name. Indicate it's a compatability
define for things that depended on the previous size of time_t, rather 
than how it _should_ be stored on disk.

Take care,


Attachment: pgpdhNgyxs5_g.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index