Re: remark on defining size of basic types

Liste des GroupesRevenir à l c 
Sujet : Re: remark on defining size of basic types
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.c
Date : 05. Apr 2024, 07:22:23
Autres entêtes
Organisation : None to speak of
Message-ID : <87zfu8idtc.fsf@nosuchdomain.example.com>
References : 1 2 3 4 5 6 7 8 9
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
On 4/4/24 13:04, Michael S wrote:
On Thu, 4 Apr 2024 12:02:16 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
 
On 4/4/24 09:15, Janis Papanagnou wrote:
...
Since I remember C had always just defined a '<=' (or '>=') relation
between the unsized basic integral data types. 
...
He meant sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long
long)
>
That's not actually the case. In the above, you are not using <= as the
C operator, but simply to indicate relative order over multiple items; I
will do the same. What is specified is equivalent to the following
>
LONGLONG_MIN <= LONG_MIN <= INT_MIN <= SHORT_MIN <= SCHAR_MAX
SCHAR_MAX <= SHORT_MAX <= INT_MAX <= LONG_MAX <= LONGLONG_MAX
UCHAR_MAX <= USHORT_MAX <= UINT_MAX <= ULONG_MAX <= ULONGLONG_MAX
>
SCHAR_MAX <= UCHAR_MAX
INT_MAX <= UINT_MAX
LONG_MAX <= ULONG_MAX
LONGLONG_MAX <= ULONGLONG_MAX

SHRT, not SHORT.
LLONG, not LONGLONG.

The sizes are not required to be in the same order as the maximum
values, nor in the opposite order of the minimum values. If they were in
a different order, it would imply a lot of padding bits, which would be
very odd, but not prohibited.

For completeness, the way it's described in the standard (quoting N3220
6.2.5p10-11) is :

    For any two integer types with the same signedness and different
    integer conversion rank (see 6.3.1.1), the range of values of the
    type with smaller integer conversion rank is a subrange of the
    values of the other type.

    The range of nonnegative values of a signed integer type is a
    subrange of the corresponding unsigned integer type, and the
    representation of the same value in each type is the same.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Date Sujet#  Auteur
4 Apr 24 * remark on defining size of basic types21fir
4 Apr 24 `* Re: remark on defining size of basic types20Lawrence D'Oliveiro
4 Apr 24  `* Re: remark on defining size of basic types19fir
4 Apr 24   `* Re: remark on defining size of basic types18Lawrence D'Oliveiro
4 Apr 24    `* Re: remark on defining size of basic types17fir
4 Apr 24     `* Re: remark on defining size of basic types16Janis Papanagnou
4 Apr 24      +* Re: remark on defining size of basic types7James Kuyper
4 Apr 24      i`* Re: remark on defining size of basic types6Michael S
4 Apr 24      i +- Re: remark on defining size of basic types1Keith Thompson
5 Apr 24      i +* Re: remark on defining size of basic types2Janis Papanagnou
5 Apr 24      i i`- Re: remark on defining size of basic types1James Kuyper
5 Apr 24      i `* Re: remark on defining size of basic types2James Kuyper
5 Apr 24      i  `- Re: remark on defining size of basic types1Keith Thompson
5 Apr 24      `* Re: remark on defining size of basic types8Lawrence D'Oliveiro
5 Apr 24       +* Re: remark on defining size of basic types6Janis Papanagnou
5 Apr 24       i`* Re: remark on defining size of basic types5Lawrence D'Oliveiro
5 Apr 24       i `* Re: remark on defining size of basic types4Janis Papanagnou
5 Apr 24       i  `* Re: remark on defining size of basic types3Lawrence D'Oliveiro
5 Apr 24       i   `* Re: remark on defining size of basic types2Michael S
5 Apr 24       i    `- Re: remark on defining size of basic types1Keith Thompson
5 Apr 24       `- Re: remark on defining size of basic types1Kenny McCormack

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal