[tz] strftime %s

[Arthur David Olson]

> C for the Univac/Unisys 36-bit systems and the Burroughs/Unisys
48+3-tag-bits systems need not provide the intN_t/uintN_t types, although
power-of-2 word-size two's complement machines would.

I'm wondering if an implementation is required to support all the features
of the hardware it is meant for. (If not, implementations on power-of-2
word-size two's complement machines might not have some of the intN_t
types.)

   --ado

On Tue, Jan 23, 2024 at 3:59 PM Guy Harris via tz <tz at iana.org> wrote:

> On Jan 23, 2024, at 4:55 AM, Clive D.W. Feather via tz <tz at iana.org>
> wrote:
> >
> > Paul Eggert via tz said:
> >
> >> and (if they exist) the intN_t and
> >> uintN_t types. In the C standard the intN_t and uintN_t types are
> optional;
> >> POSIX requires them only for N equal to 8, 16, and 32.
> >
> > C requires them for N equal to 8, 16, 32, and 64 if the implementation
> has
> > a type with the required properties. So they would be required on things
> > like x86 and ARM architectures.
>
> At least as I read 5.2.4.2.1 "Sizes of integer types <limits.h>":
>
>         The values given below shall be replaced by constant expressions
> suitable for use in #if preprocessing directives. Moreover, except for
> CHAR_BIT and MB_LEN_MAX, the following shall be replaced by expressions
> that have the same type as would an expression that is an object of the
> corresponding type converted according to the integer promotions. Their
> implementation-defined values shall be equal or greater in magnitude
> (absolute value) to those shown, with the same sign.
>
>                 ...
>
>         — minimum value for an object of type long long int
>                 LLONG_MIN       -9223372036854775807 // −(2^63−1)
>
>         — maximum value for an object of type long long int
>                 LLONG_MAX       +9223372036854775807 // 2^63−1
>
>         — maximum value for an object of type unsigned long long int
>                 ULLONG_MAX      18446744073709551615 // 2^64−1
>
> and 6.2.5 "Types" in C11:
>
>                 ...
>
>         There are five standard signed integer types, designated as signed
> char, short int, int, long int, and long long int. (These and other types
> may be designated in several additional ways, as described in 6.7.2.) There
> may also be implementation-defined extended signed integer types.) The
> standard and extended signed integer types are collectively called signed
> integer types.
>
>                 ...
>
>         For each of the signed integer types, there is a corresponding
> (but different) unsigned integer type (designated with the keyword
> unsigned) that uses the same amount of storage (including sign information)
> and has the same alignment requirements. The type _Bool and the unsigned
> integer types that correspond to the standard signed integer types are the
> standard unsigned integer types. The unsigned integer types that correspond
> to the extended signed integer types are the extended unsigned integer
> types. The standard and extended unsigned integer types are collectively
> called unsigned integer types.)
>
> that C11 requires the existence of long long int data types that support,
> at minimum, 64-bit integral values, *even if the machine's "word size" is
> smaller*, so even 32-bit x86 (IA-32) and 32-bit ARM (A32/T32) need to
> support 64-bit integral values - and the same applies to PowerPC/Power ISA,
> SPARCv{7,8,9}, 32-bit and 64-bit RISC-V, and z/Architecture (and any
> now-dead ISAs that existed in 2011).
>
> As for the intN_t/uintN_t types, as I read 7.20.1.1 "Exact-width integer
> types":
>
>         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.
>
> C for the Univac/Unisys 36-bit systems and the Burroughs/Unisys
> 48+3-tag-bits systems need not provide the intN_t/uintN_t types, although
> power-of-2 word-size two's complement machines would.
>
> And as I read 7.20.1.2 "Minimum-width integer types":
>
>         The following types are required:
>
>                 int_least8_t            uint_least8_t
>                 int_least16_t           uint_least16_t
>                 int_least32_t           uint_least32_t
>                 int_least64_t           uint_least64_t
>
> all of them would have to provide those types, even if, for example, the
> least64_t type are 72-bit or 96-bit-with-two-3-bit-tags-for-each-48-bits on
> the Unisys machines.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20240123/e1e7f790/attachment.htm>