I am the moderator, but I don’t seem to have received that message. But it seems your message has gone through.
From: firstname.lastname@example.org <email@example.com>
On Behalf Of Scott Schurr
Sent: Tuesday, January 29, 2019 5:56 PM
To: WG21 UB study group SG12 <firstname.lastname@example.org>
Subject: Re: [ub] P1407R0: Tell Programmers About Signed Integer Overflow Behavior
I sent the following email yesterday, but received a response that the email to the group was being held for moderation. After waiting more than 24 hours I've not heard back regarding moderation. I'm unsure how to directly contact the
moderator. So I'm trying again. I beg your pardon if this leads to duplication.
Hello Mr. Glisse,
Thanks very much for your interest in paper P1407R0. I appreciate your information about gcc's behavior. If an R1 version of the paper is published it will incorporate both of your points with attribution to you.
As for the appropriate target, I hear your concerns. Certainly the approach proposed in the paper is far from ideal. The problem comes from arriving at consensus regarding what an ideal, or even good enough, approach would be. My personal
opinion is that the status quo is about as far from ideal as we could get. But I also understand that there are plenty of people who disagree with my view.
just a couple points missing from the paper:
1) with g++-7 -O2 -Wall, the motivating example on the left produces:
<source>: In function 'int32_t add_100_without_wrap(int32_t)':
<source>:8:3: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow]
if (ret < a)
However, we removed the warning from gcc-8 because it was too noisy and
impossible to work around when the optimization is what you actually want.
2) At least with gcc, -ftrapv doesn't really work. You need
-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error for
something roughly equivalent to what -ftrapv is supposed to do.
Now my opinion: you have the wrong target. Compilers that have a -fwrapv
option (or -ftrapv or ubsan or ...) already indirectly describe the
default behavior as undefined (and the standard already describes it as
undefined), so it is already documented. Adding a sentence or 2 in the
standard and on pages that nobody reads won't help. It seems that you want
to talk either to teachers, so they warn their students more about the
properties of signed overflow, or to compiler writers, to convince them to
change the default to -fwrapv or -ftrapv (I hope they don't) or add more