Liste des Groupes | Revenir à c arch |
mitchalsup@aol.com (MitchAlsup1) writes:The ckd_add, ckd_sub and ckd_mul functions from C23 make it easy to check for integer overflow in C23. And of course C has had guaranteed 64-bit support since C99 - it's very rare to overflow these.
On Sat, 7 Sep 2024 13:52:02 +0000, Tim Rentsch wrote:[...]
>mitchalsup@aol.com (MitchAlsup1) writes:
>On Fri, 6 Sep 2024 13:37:13 +0000, Tim Rentsch wrote:>>>The idea is not to make more of the language defined but to give>
less freedom to cases of undefined behavior. (It might make
sense to define certain cases that are undefined behavior now but
that is a separate discussion.) Let me take an example from
another of your postings:
>
int a;
>
...
>
if (a > a + 1) {
...
}
>
>
Stipulating that 'a' has a well-defined int value, what behaviors
are allowable here? [...] If a == INT_MAX, it also should be
possible for the addition to abort the program. [...]
It is also possible if a == INT_MAX that the exception will
transfer control to a signal handler to do some SW orchestrated
recovery.
Philosophically this reaction doesn't fit with the others. Assuming
for the sake of discussion that raising an implementation-defined
signal is an important behavior to support, it should go into the
C standard in a different way than making it part of the "limited
undefined behavior" idea outlined above.
With it "being difficult" to determine when an integer overflow
has occurred in may architectures, it is unlikely that integer
overflow could ever be put into the C standard.
It could easily be added to the C standard just by making theThe C standard doesn't have anything where implementations have an option between a particular behaviour or undefined behaviour - because that would simply be the same as undefined behaviour. It sometimes has footnotes with suggestions of possible results, and it could add such a footnote for signed integer arithmetic overflow treatment. But it would not have any greater blessing from the standard than wrapping, saturating, or assuming it is impossible.
signal-raise option be conditional: give each implementation
the choice of either (a) stipulating that overflow causes an
implementation-defined signal to be raised, or (b) letting the
operation be limited undefined behavior. Limited undefined
behavior can be provided simply by naively compiling the code
in question, so that can be accommodated regardless of how
unsophisticated the processor is.
Les messages affichés proviennent d'usenet.