timelib.h: remove fallbacks for C99 integer types

[MaxKellermann]

These are mandatory in C99, and no compile-time check is needed.

See php/php-src#10304 for the PHP pull request.

[derickr]

These types are optional as per 7.18.11.3 of the ISO/IEC 9899:1999 spec.

[MaxKellermann]

These types are optional

A more exact description is in my PHP PR:

"Actually, the fixed-size integer types are not mandatory, but if they are really not available on some theoretical system, PHP's fallbacks won't work either, so nothing is gained from this check."

Your library is not buildable either on systems where those types are not available! Which makes your reason to reject this PR pointless.

[MaxKellermann]

btw. names beginning with uint and ending with _t are reserved according to the very spec you cited. Your library is, prior to this PR, not C99 compliant.
Please reconsider merging this PR for C99 compliance.

7.26: "All external names described below are reserved no matter what headers are included by the program."
7.26.8: "Typedef names beginning with int or uint and ending with _t may be added to the types defined in the <stdint.h> header."

[cmb69]

"Actually, the fixed-size integer types are not mandatory, but if they are really not available on some theoretical system, PHP's fallbacks won't work either, so nothing is gained from this check."

Why would the fallbacks not work? Is it because the SIZEOF_* macros may not be defined (that should/could be fixed then)? Or is it because neither SIZEOF_INT nor SIZEOF_LONG may be 4? Or is it because the assumptions for the fallback declarations are not conforming to the standard?

[MaxKellermann]

Or is it because neither SIZEOF_INT nor SIZEOF_LONG may be 4?

This.

If uint32_t does not exist, it means the architecture has no 32 bit (unsigned) integer. Then neither int nor long can possibly be 32 bit.

[MaxKellermann]

btw. in new code, I tend to use uint_least32_t (or uint_fast32_t, but with extra care) instead, because that's really mandatory. Because I love being 100% correct. I know that this is not relevant for anything except for theoretical correctness.

[cmb69]

These types are optional as per 7.18.11.3 of the ISO/IEC 9899:1999 spec.

I do not have an official spec at hand, but a draft says in 7.18.1.1.3:

These types are optional. However, if an implementation provides integer types with
widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a
two’s complement representation, it shall define the corresponding typedef names.

Assuming that the wording is the same in the final spec, since "shall" denotes a requirement, I'd argue that @MaxKellermann is correct (maybe except for signed integers wrt. the two's complement; timelib may not rely on that). This is, of course, only valid for a perfect world where all supported environments actually conform to this spec; on the other hand, we may never know until we try, and actually using the "classic" types such as int does guarantee almost nothing (not even that if SIZEOF_INT == 4, int is a 32bit type).

[derickr]

I am not intending to change this.