Looking at the C23 draft N2596, section J.2 (but this AFAIK has been the
same forever), we see that there is undefined behavior, when "An
expression is shifted by a negative number or by an amount greater than
or equal to the width of the promoted expression (6.5.7)." or "An
expression having signed promoted type is left-shifted and either the
value of the expression is negative or the result of shifting would not
be representable in the promoted type (6.5.7)."
Does anyone know why this was made undefined (as opposed to yielding an unspecified value)? The C99 rationale doesn't mention anything.
The only idea that comes to my mind is that it would be to allow implementations to trap at runtime when shifting too far, which might
help with debugging.
On 2021-09-21, Philipp Klaus Krause <pkk@spth.de> wrote:
Looking at the C23 draft N2596, section J.2 (but this AFAIK has been the
same forever), we see that there is undefined behavior, when "An
expression is shifted by a negative number or by an amount greater than
or equal to the width of the promoted expression (6.5.7)." or "An
expression having signed promoted type is left-shifted and either the
value of the expression is negative or the result of shifting would not
be representable in the promoted type (6.5.7)."
Does anyone know why this was made undefined (as opposed to yielding an
unspecified value)? The C99 rationale doesn't mention anything.
The only idea that comes to my mind is that it would be to allow
implementations to trap at runtime when shifting too far, which might
help with debugging.
Another thing that comes to mind is that on a machine with N-bit
wordsize, the machine instruction for shifting might only use log2(N) bits
to specify the number of places to shift.
Shifting N places or more would not be possible on such hardware
(at least, not with a single shift instruction).
Looking at the C23 draft N2596, section J.2 (but this AFAIK has been the
same forever), we see that there is undefined behavior, when "An
expression is shifted by a negative number or by an amount greater than
or equal to the width of the promoted expression (6.5.7)." or "An
expression having signed promoted type is left-shifted and either the
value of the expression is negative or the result of shifting would not
be representable in the promoted type (6.5.7)."
Does anyone know why this was made undefined (as opposed to yielding an unspecified value)? The C99 rationale doesn't mention anything.
The only idea that comes to my mind is that it would be to allow implementations to trap at runtime when shifting too far, which might
help with debugging.
I looked at my Interdata 8/32 manual (1975), which describes
a 32-bit machine, and was amused to find, under the
"Shift Left Logical" instruction,
"... the shift count is specified by the least significant
five bits of the second operand."
Looking at the C23 draft N2596, section J.2 (but this AFAIK has been the
same forever), we see that there is undefined behavior, when "An
expression is shifted by a negative number or by an amount greater than
or equal to the width of the promoted expression (6.5.7)." or "An
expression having signed promoted type is left-shifted and either the
value of the expression is negative or the result of shifting would not
be representable in the promoted type (6.5.7)."
Does anyone know why this was made undefined (as opposed to yielding an unspecified value)? The C99 rationale doesn't mention anything.
The only idea that comes to my mind is that it would be to allow implementations to trap at runtime when shifting too far, which might
help with debugging.
Does anyone know why this was made undefined (as opposed to yielding an unspecified value)? The C99 rationale doesn't mention anything.
The only idea that comes to my mind is that it would be to allow implementations to trap at runtime when shifting too far, which might
help with debugging.
In article <sek2J.55967$jm6.46258@fx07.iad>,
Richard Damon <Richard@damon-family.org> wrote:
The wording probably could be changed to something like an unspecified[...]
value or a trap,
Note: an unspecified value or a trap = an indeterminate value
The wording probably could be changed to something like an unspecified[...]
value or a trap,
Vincent Lefevre <vincent-news@vinc17.net> writes:
In article <sek2J.55967$jm6.46258@fx07.iad>,
Richard Damon <Richard@damon-family.org> wrote:
The wording probably could be changed to something like an unspecified[...]
value or a trap,
Note: an unspecified value or a trap = an indeterminate value
An indeterminate value is either an unspecified value or a trap *representation". Richard didn't say "trap representation" (I won't
attempt to guess whether that's what he meant.)
A "trap" (not a term used by the standard) usually means that the
program terminates in some unfriendly way -- which might as well be
undefined behavior.
On 9/21/21 10:05 PM, Keith Thompson wrote:
Vincent Lefevre <vincent-news@vinc17.net> writes:
In article <sek2J.55967$jm6.46258@fx07.iad>,
Richard Damon <Richard@damon-family.org> wrote:
The wording probably could be changed to something like an unspecified >>>> value or a trap,[...]
Note: an unspecified value or a trap = an indeterminate value
An indeterminate value is either an unspecified value or a trap
*representation". Richard didn't say "trap representation" (I won't
attempt to guess whether that's what he meant.)
A "trap" (not a term used by the standard) usually means that the
program terminates in some unfriendly way -- which might as well be
undefined behavior.
True. But "perform a trap" is a term defined by the standard as meaning "interrupt execution of the program such that no further operations are performed". Per footnote 2, "fetching a trap representation might
perform a trap, but is not required to do so".
While I agree that "trap representation" is most likely what he meant, "perform a trap" is an alternative possibility.
On 9/21/21 10:05 PM, Keith Thompson wrote:
Vincent Lefevre <vincent-news@vinc17.net> writes:
In article <sek2J.55967$jm6.46258@fx07.iad>,
Richard Damon <Richard@damon-family.org> wrote:
The wording probably could be changed to something like an unspecified >>>> value or a trap,[...]
Note: an unspecified value or a trap = an indeterminate value
An indeterminate value is either an unspecified value or a trap
*representation". Richard didn't say "trap representation" (I won't
attempt to guess whether that's what he meant.)
A "trap" (not a term used by the standard) usually means that the
program terminates in some unfriendly way -- which might as well be
undefined behavior.
True. But "perform a trap" is a term defined by the standard as meaning "interrupt execution of the program such that no further operations are performed". Per footnote 2, "fetching a trap representation might
perform a trap, but is not required to do so".
While I agree that "trap representation" is most likely what he meant, "perform a trap" is an alternative possibility.
Looking at the C23 draft N2596, section J.2 (but this AFAIK has been the
same forever), we see that there is undefined behavior, when "An
expression is shifted by a negative number or by an amount greater than
or equal to the width of the promoted expression (6.5.7)." or "An
expression having signed promoted type is left-shifted and either the
value of the expression is negative or the result of shifting would not
be representable in the promoted type (6.5.7)."
Does anyone know why this was made undefined (as opposed to yielding an unspecified value)? The C99 rationale doesn't mention anything.
The only idea that comes to my mind is that it would be to allow implementations to trap at runtime when shifting too far, which might
help with debugging.
(BTW, you sent your reply to me by email as well as posting it here.)
On 9/22/21 12:02 AM, James Kuyper wrote:...
True. But "perform a trap" is a term defined by the standard as meaning
"interrupt execution of the program such that no further operations are
performed". Per footnote 2, "fetching a trap representation might
perform a trap, but is not required to do so".
While I agree that "trap representation" is most likely what he meant,
"perform a trap" is an alternative possibility.
Yes, that was the 'trap' I was referring to. The Standard basically uses perform a trap to mean a hardware based exception that the software may
or might not be able to intercept as a 'signal'.
True. But "perform a trap" is a term defined by the standard as meaning "interrupt execution of the program such that no further operations are performed". Per footnote 2, "fetching a trap representation might
perform a trap, but is not required to do so".
While I agree that "trap representation" is most likely what he meant, "perform a trap" is an alternative possibility.
Vincent Lefevre <vincent-news@vinc17.net> writes:
In article <sek2J.55967$jm6.46258@fx07.iad>,
Richard Damon <Richard@damon-family.org> wrote:
The wording probably could be changed to something like an unspecified[...]
value or a trap,
Note: an unspecified value or a trap = an indeterminate value
An indeterminate value is either an unspecified value or a trap *representation". Richard didn't say "trap representation" (I won't
attempt to guess whether that's what he meant.)
A "trap" (not a term used by the standard) usually means that the
program terminates in some unfriendly way -- which might as well be
undefined behavior.
However, those are not good reasons for leaving (E1 << E2) undefined for negative E1 in cases where E1 * 2 ^ E2 fits within the result type, or
for making (E1 >> E2) implementation defined for negative E1.
In article <sie9tb$5jg$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
True. But "perform a trap" is a term defined by the standard as meaning
"interrupt execution of the program such that no further operations are
performed". Per footnote 2, "fetching a trap representation might
perform a trap, but is not required to do so".
While I agree that "trap representation" is most likely what he meant,
"perform a trap" is an alternative possibility.
I wonder why it is defined, because it does not seem to be used at all
in the standard.
On 9/22/21 7:08 AM, Richard Damon wrote:Correction - since the definition of "perform a trap" says explicitly
On 9/22/21 12:02 AM, James Kuyper wrote:...
True. But "perform a trap" is a term defined by the standard as meaning
"interrupt execution of the program such that no further operations are
performed". Per footnote 2, "fetching a trap representation might
perform a trap, but is not required to do so".
While I agree that "trap representation" is most likely what he meant,
"perform a trap" is an alternative possibility.
Yes, that was the 'trap' I was referring to. The Standard basically uses
perform a trap to mean a hardware based exception that the software may
or might not be able to intercept as a 'signal'.
I don't think that raising a signal qualifies. The standard specifies
that "no further operations are performed". It doesn't add "unless the
signal is intercepted". I don't think that anything which allows
handlers registered using atexit(), abort_handler_s(),
ignore_handler_s(), or set_constraint_handler_s() to be executed
qualifies as performing a trap, either, since those would also allow
further operations to be performed.
Looking at the C23 draft N2596, section J.2 (but this AFAIK has been
the same forever), we see that there is undefined behavior, when "An expression is shifted by a negative number or by an amount greater
than or equal to the width of the promoted expression (6.5.7)." or
"An expression having signed promoted type is left-shifted and
either the value of the expression is negative or the result of
shifting would not be representable in the promoted type (6.5.7)."
Does anyone know why this was made undefined (as opposed to yielding
an unspecified value)?
The C99 rationale doesn't mention anything.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 293 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 233:57:47 |
| Calls: | 6,624 |
| Files: | 12,172 |
| Messages: | 5,319,637 |