Re: [PATCH 0/4] replace unsinged long with time_t

On Thu, 6 Nov 2008, david@statichacks.org wrote:

I actually don't much like this.

"time_t" is one of those totally broken unix types. The standards say that it's an "arithmetic" type, but leaves it open to be just about anything. Traditionally, it's a signed integer (bad), and in theory it could even be a floating point value, I think.

And in _all_ such cases, it's actually better to cast it to "unsigned long" than keep time in a system-dependent format that is most likely either _already_ "unsigned long", or alternatively broken.

IOW, "unsigned long" is practically always either the same, or better than, time_t. Do you actually have a platform where that isn't the case?

And we do end up casting it to "unsigned long" in the end anyway - the date format in the commit is fundamentally not a signed one, and we use "%lu" to print those things. Again, if we were to use "time_t", we'd now have a huge and fundamental confusion about how to print them out, and what to do if they were negative.

So "time_t" really is a pretty damn worthless type. It's not _quite_ as broken as "socklen_t" (which is just a broken name for "int", and anybody who declares it to be anythign else is a total moron), but it's close.

In theory, some platform might have a 64-but "unsigned long long" time_t even if the architecture is 32-bit (apparently windows used to do that if you included <time64.h>, for example), but since we wouldn't take advantage of that anyway, even then there is no real advantage.

				Linus