Re: Is the size of "int" implementation-defined?

[Ian Collins]

On 21/09/18 10:21, Stefan Ram wrote:
> I suspect that the size of »int« (and of »long« and other types)
> is implementation-defined.
>
> But does the standard say so explicitly?

The standard states a minimum range, so I'd argue this is equivalent to
saying the size is implementation defined.

--
Ian.

[Alf P. Steinbach]

It refers to the C standard. And although it states that the C standard
is "incorporated" into the C++ standard, that part of the C++ standard
is inexplicably non-normative text. It's like someone's played politics.


Cheers!,

- Alf

[bitrex]

Prostitution was legal in Rhode Island from circa late 1970s to 2009
because the state legislature accidentally forgot to make it explicitly
illegal.

[James Kuyper]

implementation-defined behavior is

"behavior, for a well-formed program construct and correct data, that
depends on the implementation and that each implementation documents"
(C++ 1.3.11).
"unspecified behavior where each implementation documents how the choice
is made" (C 3.4.1p1).

Behavior is implementation-defined only if the relevant standard
explicitly requires it to be. C 5.2.4.2p1 says "An implementation is
required to document all the limits specified in this subclause,
which are specified in the headers <limits.h> and <float.h>."

However, that does not mean that it's required to document the sizes of
those types. "The representations of all types are unspecified except as
stated in this subclause." (C 6.2.6.1p1). The size of a type is one
aspect of that type's representation, and the only thing that subclause
says about the size is what is implied by the immediately following
paragraph: that all non-bit-fields have a size that is an integer number
of bytes. That implication is supported by the fact that sizeof
expressions are required to have an integer type and also to return the
size of the type they are applied to.

[Tim Rentsch]

James Kuyper <james...@alumni.caltech.edu> writes:

> On 09/20/2018 06:25 PM, Ian Collins wrote:
>
>> On 21/09/18 10:21, Stefan Ram wrote:
>>
>>> I suspect that the size of >>int<< (and of >>long<< and other
>>> types) is implementation-defined.
>>>
>>> But does the standard say so explicitly?
>>
>> The standard states a minimum range, so I'd argue this is
>> equivalent to saying the size is implementation defined.
>

> implementation-defined behavior is [...]

>
> Behavior is implementation-defined only if the relevant standard
> explicitly requires it to be. C 5.2.4.2p1 says "An implementation
> is required to document all the limits specified in this
> subclause, which are specified in the headers <limits.h> and
> <float.h>."
>
> However, that does not mean that it's required to document the

> sizes of those types. [...]

In C, the sizes of all types are implementation-defined (if not
explicitly specified).

C N1570 6.2.6.1 p2:

Except for bit-fields, objects are composed of contiguous
sequences of one or more bytes, the number, order, and
encoding of which are either explicitly specified or
implementation-defined.

C N1570 6.5.3.4 [sizeof and _Alignof operators] p5:

The value of the result of both operators is
implementation-defined, [...]

[Tim Rentsch]

r...@zedat.fu-berlin.de (Stefan Ram) writes:

> [.. are sizes, and/or ranges, of integer types specified
> as being implementation defined in C++? ..]


For ranges:

C N1570 section 5.2.4.2 p1:

An implementation is required to document all the limits
specified in this subclause, which are specified in the

headers <limits.h> and <float.h>. [...]

C++ N4762 section 16.3.5 p1:

The header <climits> defines all macros the same as the C
standard library header <limits.h>. [...]


For sizes:

C N1570 section 6.2.6.1 p2:

Except for bit-fields, objects are composed of contiguous
sequences of one or more bytes, the number, order, and
encoding of which are either explicitly specified or
implementation-defined.

C N1570 section 6.5.3.4 [sizeof and _Alignof operators] p5:

The value of the result of both operators is
implementation-defined, [...]

C++ N4762 section 7.6.2.3 p1:

[..corner cases such as bitfields or function types..]
The result of sizeof applied to any other fundamental type
(6.7.1) is implementation-defined. [...]

[Vir Campestris]

On 22/09/2018 13:08, Tim Rentsch wrote:
> Except for bit-fields, objects are composed of contiguous
> sequences of one or more bytes, the number, order, and
> encoding of which are either explicitly specified or
> implementation-defined.

.. which neatly leaves in those odd machines that use a BCD
representation for their numbers (a byte holds 0-99).

Though I haven't seen one in 30 odd years, and not running C, never mind
C++!

Andy

[Scott Lurndal]

I still use one now and again, albeit generally in emulation. It never
had a C compiler, although we looked into it in the 1980's, but since
operands ranged from 1 to 100 units (BCD digits or EBCDIC bytes with the
zone digit ignored) for arithmetic operations, there was no consensus
internally on how that would map to 'int' (7-digit with leading sign or
8 unsigned digits consumed 32-bits of memory, so that was one of the choices
we looked at, but in the end, there was no customer demand for C on
that platform and that was that).

[Alf P. Steinbach]

On 24.09.2018 22:15, Vir Campestris wrote:
> On 22/09/2018 13:08, Tim Rentsch wrote:
>>      Except for bit-fields, objects are composed of contiguous
>>      sequences of one or more bytes, the number, order, and
>>      encoding of which are either explicitly specified or
>>      implementation-defined.

I almost wrote that in C++ a bit-field is not an object. But it is.
Learned something. :)

> .. which neatly leaves in those odd machines that use a BCD
> representation for their numbers (a byte holds 0-99).

In C++ integers must be represented in pure binary systems, no BCD.

C++17 §6.9.1/3 “The representations of integral types shall define
values by use of a pure binary numeration system.”

However, in C++17 §21.3.4.1/23 `std::numeric_limits<T>::radix` is
described as “For integer types, specifies the base of the
representation”, with a (non-normative) note, numbered 194,
“Distinguishes types with bases other than 2 (e.g. BCD)”.

For floating point types the same paragraph says that
`std::numeric_limits<T>::radix` just “specifies the base or radix of the
exponent representation (often 2)”. As I understand it this accommodates
decimal arithmetic types where the digits are represented as a single
binary integer. Still I can't quite totally grok it.

Apparently `std::numeric_limits` doesn't support fixed point types, like
a `Currency` type with four fraction part digits?

> Though I haven't seen one in 30 odd years, and not running C, never mind
> C++!

The x86-based processors in our PCs have some rudimentary support for
BCD, but I forget exactly what. :)


Cheers!,

- Alf

[Scott Lurndal]

That support, such as it was, was removed when AMD designed the 64-bit extensions and
re-used the instruction opcodes when running in long-mode.

[Vir Campestris]

So I need to rewrite the cover on my assembly book - it doesn't start
with AAA any more?

(Ascii Adjust After Add)

Andy

[Scott Lurndal]

It's still there when long-mode is not set.