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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 6 Nov 2008, david@statichacks.org wrote:
> 
> Here is a patch set from the Janitor page to replace unsigned long with time_t.

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