Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: uint32_t is not the same as long unsigned int ?
Date: Sat, 04 Jan 2020 14:48:42 -0800
Organization: None to speak of
Lines: 69
Message-ID: <8736cuon1x.fsf@nosuchdomain.example.com>
References: <qup223$eje$1@dont-email.me> <qup3ng$krp$1@dont-email.me> <87k167odry.fsf@nosuchdomain.example.com> <quq8k3$4he$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="ae6c07825fe602dea7ed53b20475ec70"; logging-data="13454"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/cArSsHhs+ecXkiWXvuKhC"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
Cancel-Lock: sha1:Gv021ymPh2CCrKtjWChMqDNzL0k= sha1:CiFmmjR7z8YQQPcYijdD48yhPXY=
Xref: csiph.com comp.lang.c++:71120

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 1/4/20 2:56 AM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> [...]
>>> The actual requirements are in terms of the required range of values
>>> that each standard integer type must be able to represent, and are
>>> incorporated by reference from the C standard. I've converted those
>>> ranges into bit counts to better match your question.
>> 
>> A quibble: the required ranges of values for the standard integer types
>> are copied from the C standard, but are not incorporated by reference.
>
> In my copy of n4567.pdf, 18.3.3 says:
>
> "1 Table 31 describes the header <climits>.
> 2 The contents are the same as the Standard C library header <limits.h>"
>
> 18.3.3p2 is precisely the kind of wording that "incorporated by
> reference" means to me. What does it mean to you?
>
> The "description" in table 31 is the only place that the C++ standard
> that all of the *_MIN and *_MAX macros are referred to. The meanings of
> those macros and the maximum and minimum (respectively) permitted values
> for those macros which are only given in the C standard. If you read
> only the C++ standard, you might not even realize that it imposes any
> limits on the sizes of integer types, however indirectly.

You're right.  N4567 3.9.1 [basic.fundamental] paragraph 3 says:

    The signed and unsigned integer types shall satisfy the constraints
    given in the C standard, section 5.2.4.2.1.

My earlier post was based on N4842, which is a working draft for C++20
(and happens to be the document that I had open at the time).  In that
draft, 6.8.1 [basic.fundamental] paragraph 3 includes a table showing
the minimum widths of the 5 signed integer types:

    Type              Minimum width N
    signed char       8
    short             16
    int               16
    long              32
    long long         64

The widths are sufficient to specify the ranges, since unlike the
current edition of the C++ standard, N4842 mandates 2's-complement
for signed integers, including the extra negative value:

    The range of representable values for a signed integer type is
    −2**(N−1) to 2**(N−1) − 1 (inclusive), where N is called the *width*
    of the type.
    ...
    An unsigned integer type has the same object representation,
    value representation, and alignment requirements (6.7.6) as
    the corresponding signed integer type. For each value x of a
    signed integer type, the value of the corresponding unsigned
    integer type congruent to x modulo 2**N has the same value of
    corresponding bits in its value representation.

(expressions tweaked to avoid superscripts).

Of course N4842 is not a standard, and I should have checked the current
edition.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */