Compiler-extension small int type promotion

[Tomás Ó hÉilidhe]

Here's a hypothetical:

(There's no padding bits in the integer types)
CHAR_BIT == 8
sizeof(short) == 2 (16-Bit)
sizeof(int) == 8 (64-Bit)

Let's say the compiler has its own extra type as an extension, such as
"longshort":

sizeof (longshort) == 4 (it's 32-Bit)

I want to find out whether the Standard requires this extended integer
type, which is smaller than an int, to undergo integer promotion to
become a "signed int". I've been reading the Standard for couple of
minutes but I'm not certain. Here's a relevant excerpt:

"The following may be used in an expression wherever an int or
unsigned int may
be used: An object or expression with an integer type whose integer
conversion rank is less
than or equal to the rank of int and unsigned int."

The rank is established as follows:

"The rank of long long int shall be greater than the rank of long int,
which
shall be greater than the rank of int, which shall be greater than the
rank of short
int, which shall be greater than the rank of signed char."

This doesn't clarify in my head whether "longshort" must undergo
integer promotion to a "signed int" in this case.

Here's another excerpt but I don't believe it gives any clarification:
"The rank of any standard integer type shall be greater than the rank
of any extended
integer type with the same width."

If you changed "with the same width" to "with same or lesser width",
then that would tell me that "longshort" must undergo promotion, but
currently I don't see any requirement for "longshort" to undergo
promotion.

Any thoughts?

 

[Barry Schwarz]

Here's a hypothetical:

(There's no padding bits in the integer types)
CHAR_BIT == 8
sizeof(short) == 2 (16-Bit)
sizeof(int) == 8 (64-Bit)

Let's say the compiler has its own extra type as an extension, such as
"longshort":

sizeof (longshort) == 4 (it's 32-Bit)

I want to find out whether the Standard requires this extended integer
type, which is smaller than an int, to undergo integer promotion to
become a "signed int". I've been reading the Standard for couple of
minutes but I'm not certain. Here's a relevant excerpt:

"The following may be used in an expression wherever an int or
unsigned int may
be used: An object or expression with an integer type whose integer
conversion rank is less
than or equal to the rank of int and unsigned int."

Why didn't you look at the next two sentences in the standard. The
second one states "If an int can represent all values of the original
type, the value is converted to an int; otherwise, it is converted to
an unsigned int. These are called the integer promotions. All other
types are unchanged by the integer promotions."

The rank is established as follows:

"The rank of long long int shall be greater than the rank of long int,
which
shall be greater than the rank of int, which shall be greater than the
rank of short
int, which shall be greater than the rank of signed char."

This doesn't clarify in my head whether "longshort" must undergo
integer promotion to a "signed int" in this case.

Here's another excerpt but I don't believe it gives any clarification:
"The rank of any standard integer type shall be greater than the rank
of any extended
integer type with the same width."

If you changed "with the same width" to "with same or lesser width",
then that would tell me that "longshort" must undergo promotion, but
currently I don't see any requirement for "longshort" to undergo
promotion.

How about the sentence just before the one you quoted for long long
int: "The rank of a signed integer type shall be greater than the
rank of any signed integer type with less precision."

 

[Tomás Ó hÉilidhe]

Why didn't you look at the next two sentences in the standard.  The
second one states "If an int can represent all values of the original
type, the value is converted to an int; otherwise, it is converted to
an unsigned int. These are called the integer promotions.  All other
types are unchanged by the integer promotions."

If that were an "umbrella paragraph" that covers all types, then an
"unsigned long long" promotes to "unsigned int". (Which it doesn't of
course).

How about the sentence just before the one you quoted for long long
int:  "The rank of a signed integer type shall be greater than the
rank of any signed integer type with less precision."

That paragraph explicitly says "signed". What about unsigned?
Furthermore I don't see where the standard says types of lower rank
than int get promoted, the language it uses refers to range.

 

[Harald van Dijk]

If that were an "umbrella paragraph" that covers all types, then an
"unsigned long long" promotes to "unsigned int". (Which it doesn't of
course).

It covers all types of the above paragraph:
-- An object or expression with an integer type whose integer conversion
rank is less than or equal to the rank of int and unsigned int.
-- A bit-field of type _Bool, int, signed int, or unsigned int.

That paragraph explicitly says "signed". What about unsigned?

The unsigned type has the same rank as the corresponding signed type.

Furthermore I don't see where the standard says types of lower rank than
int get promoted, the language it uses refers to range.

Rank determines whether a type gets promoted. Range determines what it is
promoted to.

 

[Tomás Ó hÉilidhe]

OK I think I understand. The two relevant paragraphs are as follows:

"The rank of a signed integer type shall be greater than the
rank of any signed integer type with less precision."

and:

"The unsigned type has the same rank as the corresponding signed
type."

So that means "longshort" has rank less than "int", which means that
it must undergo promotion.

....that right?

 

[Barry Schwarz]

If that were an "umbrella paragraph" that covers all types, then an
"unsigned long long" promotes to "unsigned int". (Which it doesn't of
course).




That paragraph explicitly says "signed". What about unsigned?
Furthermore I don't see where the standard says types of lower rank
than int get promoted, the language it uses refers to range.

On the outside chance you are not being deliberately obtuse, let's
start at the beginning:

Each signed integer type has a unique rank (6.3.1.1-1 and
6.3.1.1-1¶1).

The ranks of the standard signed integers form a "natural"
decreasing hierarchy starting with long long and ending with signed
char (6.3.1.1-1¶3).

Unsigned types have the same rank as the corresponding signed
type (6.3.1.1-1¶4). The rank of char is the same as the rank of
signed and unsigned char (6.3.1.1-1¶6).

The rank of a type shall be greater than the rank of a smaller
type (6.3.1.1-1¶2). (Therefore, the rank of longshort is between the
rank of integer and the rank of short.)

You can use an integer of lower rank anywhere an int or
unsigned int can be used (6.3.1.1-2¶1).

Since an int can hold any value a longshort can, the longshort
will be converted to int (6.3.1.1-2¶3).

Now:

Why do you think this sequence does not cover longshort?

Why do you think this sequence might cover long long?

Why do you think unsigned is omitted?

 

[CBFalconer]

Here's a hypothetical:

(There's no padding bits in the integer types)
CHAR_BIT == 8
sizeof(short) == 2 (16-Bit)
sizeof(int) == 8 (64-Bit)

Let's say the compiler has its own extra type as an extension,
such as "longshort":

sizeof (longshort) == 4 (it's 32-Bit)

I want to find out whether the Standard requires this extended
integer type, which is smaller than an int, to undergo integer
promotion to become a "signed int". I've been reading the
Standard for couple of minutes but I'm not certain. Here's a
relevant excerpt:

Of course not. It will depend on how you have defined longshort.
Extensions are not covered by the standard.

 

[Ben Bacarisse]

Of course not. It will depend on how you have defined longshort.
Extensions are not covered by the standard.

The standard goes to some considerable length to explain how such
extended integer types fit in with the others. Extensions may not be
covered, but the topic of the post -- extended integer types -- are.

 

[CBFalconer]

The standard goes to some considerable length to explain how such
extended integer types fit in with the others. Extensions may not
be covered, but the topic of the post -- extended integer types --
are.

Seems I have missed something again. Can you give me a reference
point in the C99 standard?

 

[Ben Bacarisse]

Ben Bacarisse wrote:

Seems I have missed something again. Can you give me a reference
point in the C99 standard?

6.2.5 p7, 6.3.1.1 p1, 6.4.4.1 p6 and 7.18 p4 pretty much covers it.

 

[Keith Thompson]

Let's say the compiler has its own extra type as an extension,
such as "longshort":

sizeof (longshort) == 4 (it's 32-Bit)

[...]
Of course not. It will depend on how you have defined longshort.
Extensions are not covered by the standard.

Specific extensions are not covered, but extensions in general
certainly are. Extensions are permitted by C99 4p6, and extended
integer types, and the requirements on them, are covered by C99 6.2.5.

The only problem is that "longshort" is in the user's namespace, and
cannot legally be used as the name of an extended integer type. An
implementation could legally provide a type "__longshort", and could
optionally add "typedef longshort __longshort" to an
implementation-defined header.

Assuming that such a type is provided, the standard has quite a lot to
say about the requirements for it -- as has been discussed in this
very thread.

 

[CBFalconer]

6.2.5 p7, 6.3.1.1 p1, 6.4.4.1 p6 and 7.18 p4 pretty much covers it.

It appears to me that those refer only to the known types,
mentioned in the standard, and/or inserted by the use of standard
header files. The original enquiry here was considering a
fictional type generated entirely by the user.

 

[CBFalconer]

Let's say the compiler has its own extra type as an extension,
such as "longshort":

sizeof (longshort) == 4 (it's 32-Bit)

[...]
Of course not. It will depend on how you have defined longshort.
Extensions are not covered by the standard.

Specific extensions are not covered, but extensions in general
certainly are. Extensions are permitted by C99 4p6, and extended
integer types, and the requirements on them, are covered by C99 6.2.5.

The only problem is that "longshort" is in the user's namespace, and
cannot legally be used as the name of an extended integer type. An
implementation could legally provide a type "__longshort", and could
optionally add "typedef longshort __longshort" to an
implementation-defined header.

Assuming that such a type is provided, the standard has quite a lot to
say about the requirements for it -- as has been discussed in this
very thread.

Exactly, and that has been my point. On review it appears that
6.2.5 p7 specifically defines what the integer types and extended
integer types can be. Thus the OPs proposal is illegal.

 

[Harald van Dijk]

It appears to me that those refer only to the known types, mentioned in
the standard, and/or inserted by the use of standard header files. The
original enquiry here was considering a fictional type generated
entirely by the user.

No, it wasn't. It was considering a non-standard integer type generated
by the implementation.

All the paragraphs Ben pointed you to mention extended integer types.
They are the non-standard integer types for which behaviour is defined by
the standard.

 

[Keith Thompson]

Let's say the compiler has its own extra type as an extension,
such as "longshort":

sizeof (longshort) == 4 (it's 32-Bit) [...]
Of course not. It will depend on how you have defined longshort.
Extensions are not covered by the standard.

Specific extensions are not covered, but extensions in general
certainly are. Extensions are permitted by C99 4p6, and extended
integer types, and the requirements on them, are covered by C99 6.2.5.

The only problem is that "longshort" is in the user's namespace, and
cannot legally be used as the name of an extended integer type. An
implementation could legally provide a type "__longshort", and could
optionally add "typedef longshort __longshort" to an
implementation-defined header.

Assuming that such a type is provided, the standard has quite a lot to
say about the requirements for it -- as has been discussed in this
very thread.

Exactly, and that has been my point. On review it appears that
6.2.5 p7 specifically defines what the integer types and extended
integer types can be. Thus the OPs proposal is illegal.

Unless I'm missing something, the only illegal thing about it is the
name. An implementation could legally provide an extended integer
type called "__longshort" with the specified characteristics, and the
behavior of that type would then be as specified in the cited portions
of the standard.

Since the OP wasn't asking about the spelling, I suggest that an
appropriate response (if one chose to respond) would be to point out
that minor issue and answer the original question.

 

[Tomás Ó hÉilidhe]

Since the OP wasn't asking about the spelling, I suggest that an
appropriate response (if one chose to respond) would be to point out
that minor issue and answer the original question.

I'm impressed.