Type of time_t

[komh]

Hi/2.

tv_sec of struct timeval in sys/_timeval.h is declared as time_t which is int. However, prior to LIBCn, it's declared as long. Especially, OS/2 Toolkit declares it as long.

So, when compiling kLIBC sources and others, warnings may occur. For example, when showing values of tv_sec like this:

printf("sec = %ld\n", tv.tv_sec);

In addition, declarations of time_t do not match in headers. Unlike any other time_t, time_t in sys/timeb.h is declared asunsigned long. This mismatch should be fixed.

Consequently, it would be better to typedef time_t to long than int for the compatibility with kLIBC and others.

[dmik]

This was an intentional change, please refer to #80. The OS/2 Toolkit is very old and very outdated. Having tv_sec long for compatibility produced warnings and even errors in many modern software including Qt 5 that's why it was changed to match the current POSIX.

Given that one should never mix kLIBC and LIBCn, it shouldn't be an issue. As for mixing with the OS/2 Toolkit, this is also very rare nowadays and in general POSIX and the OS/2 Toolkit shouldn't be mixed either. In rare cases warnings may be shut up inline and/or types redefined using the respective macros.

As for timeb.h, you are right, I will put it in sync. Thanks!

[komh]

What I meant is to typedef __time_t to long not having tv_sec to long in struct timeval.

[dmik]

Okay, but still, it would break modern POSIX compatibility. Makes no sense to sacrifice it just to be compatible with the outdated and rarely used OS/2 toolkit.

[komh]

I don't understand why typedefing __time_t to long breaks modern POSIX compatibilty, because POSIX does not require time_t to be a specific type, but just an integer type. Because of this, according to systems, it may be 32-bit integer type or 64-bit integer type. if using 32-bit integer type, it may be int or long on 32-bit systems. So if possible to choice, there is no need to break backward-compatibility.

[dmik]

Now I get you. The __time_t definition comes from FreeBSD (which is a base for kLIBC and LIBCn) and there it is __int32_t. On GNU/Linux it seems to be long int on 32-bit systems. If we change it this way, it may cause just the same warnings but the other way around (where the code uses %d to print it). So I'm not sure we should actually do that unless you have a really convincing real life case.