Re: dtime_t

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Feb 21, 2008 at 01:11:25AM +0000, Steven M. Bellovin wrote:
 > Simon Burge <simonb%NetBSD.org@localhost> 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.

-- 
David A. Holland
dholland%netbsd.org@localhost