On Thu, 6 Nov 2008, david@xxxxxxxxxxxxxxx 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
