zefram wrote: > Steve Summit wrote: >> Hoo, boy. I would love to, but that's a project for another day, >> and has nothing directly to do with leap seconds. > > It's pretty relevant to the way you're encoding leap seconds in struct > timespec. If your gmtime_ts_r() doesn't produce a tm_nsec output, > then any caller interested in the nanoseconds needs to extract it from > the struct timespec emself, and thus needs to know about the irregular > encoding therein of leap seconds.
I know exactly what you mean; in fact -- true confession -- the very first time I tested my brand-new kernel and brand-new gmtime_ts_r across a simulated leap second, I forgot to do that tricky and non-obvious handling in my top-level calling code, leading to a goofy bug. Okay, so maybe I'll bump the priority of tm_nsec. >> if struct tm had tm_nsec, what should strftime do with it? > > I'd expect strftime() to adopt the %N format specifier from GNU date(1). An obvious choice, which I'm personally less than fond of. It's great for printing human-readable nanoseconds, but if you want to print milliseconds or microseconds, you have to extract it and manipulate it yourself. >> *Interfaces*? Really? Struct stat64, maybe, but struct stat >> can't, without breaking backwards compatibility. (Unless it's >> playing tricky games with unions or something.) > > It is playing tricky games. At the source level... > but depending on preprocessor flags... > There's also some support at the syscall interface for different layouts... > glibc also has some logic to mediate... > The linkage games that it plays allow... > This is the mechanism you'd need to compatibly add tm_nsec to struct tm. Oh, my. I knew about some of that, suspected a few other bits, but was blissfully unaware of the rest. (Anybody know of a, like, college-level course anywhere on this stuff? I despair of ever reverse-engineering it all...) >> To extend the *range*? What's wrong with just making tv_sec >> (like time_t) 64 bits, which is happening everywhere else anyway? (That was a rhetorical question, of course.) > That might be interpreted as a profligate use of inode bits. Yeah, especially since the promised zettabyte drives are still nowhere in sight, and we're all having to make do with these cramped old terabyte ones. > I'd probably have gone straight to 64 integral bits if it had been my > decision, but one can see why saving four bytes per inode for another > two centuries would be an attractive choice. Oh, yeah, I can see why; I just wouldn't have *liked* it. _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
