Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:Tim Rentsch <tr.17687@z991.linuxsc.com> writes:Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:Tim Rentsch <tr.17687@z991.linuxsc.com> writes:>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:>Note that in a context that requires a constant expression, overflow is>
a constraint violation. For example, a case label like:
>
case (INT_MAX + 1) * 0:
>
must be diagnosed at compile time.
gcc disagrees with you.
What makes you think so?
>
[...]
I'm skipping this and proceeding on to the original question.
What question? I made a statement.
Why?>
gcc is not authoritative. I didn't want to get into an argument
about whether gcc is conforming, or which version of gcc was used,
or any similar distractions. The C standard /is/ authoritative,
and I thought it would save time to cut to the chase.
I never said gcc is authoritative. *You* brought gcc into the
discussion.
It is a fact that gcc issues a diagnostic for that case label.
It is a fact that it's a non-fatal warning with "-pedantic" and a
fatal error with "-pedantic-errors", which implies, as I understand
it, that the authors of gcc believe that the diagnostic is required
by the standard.
You made a statement, "gcc disagrees with you". I demonstrated,>
in text that you snipped, that gcc does in fact agree with me.
No, you didn't.
Yes, I did.
You were wrong.>
No, I wasn't. Your testing was faulty.
Yes, you were. My testing was not faulty.
What exactly did you mean by "gcc disagrees with you"? I
think it's sufficiently obvious that gcc does not have opinions,
so you presumably were speaking figuratively in some sense.
Do you not see the same diagnostic I saw?
I don't know the basis of your error, so I asked.>
Or maybe I'm missing something, and you had a valid point that I
didn't understand.
I'm offended that you think I have an obligation to remedy your
habit of lazy thinking, especially when as here the answer was
staring you right in the face, and you simply ignored it.
OK. I'm offended by your superior attitude. I'm offended by your
refusal to consider that you might have made a mistake. I'm offended
by your refusal to explain what you meant by an unclear statement
after I repeatedly ask you to do so. I'm offended by your apparent
assumption that if the rest of us just *think really hard*, we'll
inevitably agree with you.
You're not required to answer my question, which I think was>
an extremely reasonable one, but quoting it and then explicitly
refusing to answer it is pointlessly rude.
I wasn't refusing to answer. What I was doing was trying to
answer the original question, and answer it in a way that wouldn't
get lost in pointless bickering. Silly me.
I'm assuming that by "the original question", you're referring to my
*statement* that a diagnostic is required for the above case label.
If you have some other "original question" in mind, please specify
it. Please do not insult me by assuming that I'll know exactly
what you mean if I just reread what you wrote and think hard enough.
If you were trying to answer the "original question", you failed.
You expressed your supposed disagrement by asserting, without
further explanation, that gcc disagrees with me -- when, in fact,
it does not, and when gcc's behavior is not directly relevant to
the original statement anyway (since, as you correctly point out,
gcc is not authoritative).
I'd like to know whether you still think you were right. If so,>
I'd like to see your explanation. If not, an admission that you
made a mistake would be appreciated. But I expect neither from you.
I'd like to know why you ignored my explanation, based directly on
text from the C standard, about why an implementation is allowed to
process the code in question, without giving a diagnostic, and
still be conforming. An explanation that Dan Cross agreed with,
even if he may not like the consequences.
That explanation is not relevant to your claim that gcc disagrees
with me, which is what I asked you about.
In investigating this question, I have run compilations using
multiple versions of gcc, on two different platforms. I have looked
carefully through the gcc man page. I have also run compilations
using multiple versions of clang, on two different platforms. After
doing all that, I ran compilations using godbolt, so I could check
the latest, or maybe almost latest, versions of gcc and clang. All
the different versions of gcc and clang that I have tried support my
hypothesis that gcc (and now also clang) interpret the C standard so
as to conclude that conforming to the C standard need not require a
diagnostic for situations like the code under discussion..
You've told us what you concluded from your compilations using godbolt.
You haven't told us what those compilations actually told you.
On the off chance that you're willing to answer a straightforward
question:
Here's one result I got on my system:
$ gcc16 --version | head -n 1
gcc16 (GCC) 16.1.0
$ cat c.c
#include <limits.h>
int main(void) {
switch(0) {
case (INT_MAX + 1) * 0:
break;
}
}
$ gcc16 -std=c23 -pedantic-errors -c c.c
c.c: In function ‘main’:
c.c:4:23: warning: integer overflow in expression of type ‘int’ results in ‘-2147483648’ [-Woverflow]
4 | case (INT_MAX + 1) * 0:
| ^
c.c:4:9: error: overflow in constant expression [-Woverflow]
4 | case (INT_MAX + 1) * 0:
| ^~~~
$
gcc emitted a fatal error message on that case label. Have you
seen any version of gcc, either on your system or on godbolt,
*not* issue a fatal error message when invoked on that source with
"-std=cNN -pedantic-errors" (NN=23, or any valid value you like)?
If so, have you seen it not at least issue a warning?
If not, what is the basis for your claim that gcc disagrees with me?
It's conceivable that what you meant is that gcc happens to issue
a diagnostic, but is not required to. If so, then (a) that's
sufficiently subtle that any reasonable person would have explained
that point, and (b) given that gcc produces a diagnostic, I see no
basis to assume that gcc "thinks" it's not required to do so.
I'd like to ask you to do two things. First, read through the
reasoning given in my previous post, try to assess whether that
reasoning is sound, and post the results of yours contemplations.
Second, look again at the question of whether gcc (and also clang,
if you're up to it) support the hypothesis that a conforming
implementation need not give a diagnostic for code like that under
discussion. See if you can find a way of framing the question that
supports my statement, rather than simply looking for one that
supports your preconceived ideas. Post the results of your
investigations, both what other experiments you tried, and what your
assessment is of the results you got.
You made a very simple claim, that gcc disagrees with me. I'm asking
you about *that statement*. Do you still assert that gcc disagrees
with me? (That is not a question about the C standard.)
Do these two things and I will endeavor to explain my views on the
questions you have raised here, if such explanations are still
needed after your further examinations and comments.
>[SNIP]>
>I see no basis for this belief. My conclusions are based on what>
the C standard actually says, rather than guesses about some
unstated "intentions". I think you would do well to reach your
conclusions based more on the actual text of the C standard, and
less on your interpretation of what the text was "intended" to
mean.
The actual text of the standard implies that 42 is not an expression.
I rely on the obvious intent to conclude that it is.
Now it is you who is changing the subject. Besides not being on
point to the question being considered, it's a silly argument, and I
would hope you are smart enough to realize that. However, if you do
what I have asked in the previous paragraph, I can try to explain
why I think your views on this unrelated matter are wrongheaded.
Please be less condescending.
Leaving gcc aside, my original statement was that a case label like:
case (INT_MAX + 1) * 0:
is a constraint violation (and therefore that it requires a diagnostic).
It's possible that I'm mistaken on that point. The constraint I claim
it violates is that "Each constant expression shall evaluate to a
constant that is in the range of representable values for its type."
We could have discussed that much more briefly if you hadn't dragged
gcc into it.
I acknowledge that it can also be reasonably argued that the
expression as a whole *can*, for a particular implementation, yield
a result of 0, and therefore that a diagnostic is not required *for
such an implementation*.
The committee response to C90 DR #031 contradicts that argument:
case (INT_MAX*4)/4: is a constraint violation.
When subclause 6.4 says on page 55, lines 11-12:
Each constant expression shall evaluate to a constant that is in the
range of representable values for its type.
the Committee's judgement of the intent is that the
``representable'' requirement applies to each subexpression of
a constant expression, as shown in the third example. A constant
expression is meant as defined by the syntax rules.
My judgement of the intent agrees with the Committee's, and, as
far as I can tell, with gcc's.
(I do think that the wording in the standard could and should be
improved.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
Les messages affichés proviennent d'usenet.