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 <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. 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 up. 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, Bill
Attachment:
pgpdhNgyxs5_g.pgp
Description: PGP signature