Em 2/10/2024 9:31 PM, Keith Thompson escreveu:
> bart <bc@freeuk.com> writes:
>> On 10/02/2024 01:59, Tim Rentsch wrote:
>>> bart <bc@freeuk.com> writes:
>>> [...]
>>>
>>>> This is something which has long been of fascination to me: how
>>>> exactly do you get a C compiler to actually fail a program with a
>>>> hard error when there is obviously something wrong, while not also
>>>> failing on completely harmless matters.
>
> The only thing that *requires* a compiler to reject a translation unit
> is the #error directive. For any violation of a syntax rule or
> constraint, the standard only requires a *diagnostic message*, which can
> be a non-fatal warning.

I haven't checked the standard but

#if 1/0
#endif

<source>:4:6: error: division by zero in preprocessor expression
4 | #if 1/0
| ~^~

stops compilation.

With constexpr in C23 I guess division by 0 will stop code generation as
well.

Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> We can compare this approach with C++ for instance, when in C++ we
> have an error and in C a warning, that means the error is part of the
> C++ language, it works in the same way in any compiler.

C++'s requirements for diagnostics are similar to C's:

If a program contains a violation of any diagnosable rule or an
occurrence of a construct described in this document as
“conditionally-supported” when the implementation does not support
that construct, a conforming implementation shall issue at least one
diagnostic message.

As in C, if a program violates language rule, the standard only requires
a diagnostic, which may be a non-fatal warning.

I've seen cases where similar errors are treated as warnings by gcc and
as fatal errors by g++ (in their default modes), but that's just a
choice by the implementers, not a choice imposed by the language. (The
choice for gcc is influenced by a perceived need to accept code that was
valid in earlier versions of the language, something that's less of a
concern in C++.)

And of course both gcc and g++ support the "-pedantic-errors" option.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Thiago Adams <thiago.adams@gmail.com> writes:
> Em 2/10/2024 9:31 PM, Keith Thompson escreveu:
>> bart <bc@freeuk.com> writes:
>>> On 10/02/2024 01:59, Tim Rentsch wrote:
>>>> bart <bc@freeuk.com> writes:
>>>> [...]
>>>>
>>>>> This is something which has long been of fascination to me: how
>>>>> exactly do you get a C compiler to actually fail a program with a
>>>>> hard error when there is obviously something wrong, while not also
>>>>> failing on completely harmless matters.
>> The only thing that *requires* a compiler to reject a translation
>> unit
>> is the #error directive. For any violation of a syntax rule or
>> constraint, the standard only requires a *diagnostic message*, which can
>> be a non-fatal warning.
>
> I haven't checked the standard but
>
> #if 1/0
> #endif
>
>
> <source>:4:6: error: division by zero in preprocessor expression
> 4 | #if 1/0
> | ~^~
>
>
> stops compilation.

Then I suggest you check the standard. It's perfectly valid for an
implementation to choose to stop compilation if it encounters 1/0 in a
preprocessor expression, but it's not required. "The resulting tokens
compose the controlling constant expression which is evaluated according
to the rules of 6.6." 6.6, Constraints: "Each constant expression shall
evaluate to a constant that is in the range of representable values for
its type." So that's simply a constraint violation, requiring a
diagnostic but not requiring the translation unit to be rejected.

> With constexpr in C23 I guess division by 0 will stop code generation
> as well.

No, it merely requires a constant expression.
constexpr int n = 1/0;
is a constraint violation, requiring a diagnostic but not requiring
rejection.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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:
>>> [snip discussion of a program that divides by zero]
>>>
>>>> An implementation can refuse to translate the program, but not
>>>> because undefined behavior occurs. The undefined behavior here
>>>> happens only when the program is executed, but just compiling the
>>>> program doesn't do that. No execution, no undefined behavior.
>>>> Still the program may be rejected, because it is not strictly
>>>> conforming (by virtue of having output depend on the undefined
>>>> behavior if the program is ever run).
>>>
>>> Just to be clear, would you say that a conforming hosted
>>> implementation may reject this program:
>>>
>>> #include <limits.h>
>>> #include <stdio.h>
>>> int main(void) {
>>> printf("INT_MAX = %d\n", INT_MAX);
>>> }
>>>
>>> solely because it's not strictly conforming?
>>
>> My understanding of the C standard is that a hosted implementation
>> may choose not to accept the above program and still be conforming,
>> because this program is not strictly conforming. (Please assume
>> subsequent remarks always refer to implementations that are both
>> hosted and conforming.)
>>
>> Also, assuming we have ruled out cases involving #error, a
>> conforming implementation may choose not to accept a given program
>> if and only if the program is not strictly conforming. Being
>> strictly conforming is the only criterion that matters (again
>> assuming there is no #error) in deciding whether an implementation
>> may choose not to accept the program in question.
>>
>> I'm guessing that what you mean by "may reject" is the same as what
>> I mean by "may choose not to accept". I'd like to know if you think
>> that's right, or if you think there is some difference between the
>> two. (My intention is that the two phrases have the same meaning.)
>>
>> Does the above adequately address the question you want answered?
>
> I'm not sure. As I recall, I gave up on trying to understand what
> you think "accept" means.
>
> N1570 5.1.2.3p6:
>
> A program that is correct in all other aspects, operating on
> correct data, containing unspecified behavior shall be a
> correct program and act in accordance with 5.1.2.3.
>
> Does that not apply to the program above? How can it do so if it's
> rejected (or not "accepted")?
>
> The same paragraph says that "A *conforming hosted implementation*
> shall accept any strictly conforming program". Are you reading
> that as implying that *only* strictly conforming programs must be
> accepted?
>
> As a practical matter, an implementation that accepts *only*
> strictly conforming programs would be very nearly useless. I
> don't see anything in the standard that says a program can be
> rejected purely because it's not strictly conforming, and I don't
> believe that was the intent.

My understanding of the C standard is that 'shall accept' is
meant in the sense of 'shall use its best efforts to complete
translation phases 1 through 8 successfully and produce an
executable'.

Where you say "5.1.2.3p6:" I expect you mean "4p3".

Where you say "the same paragraph" I expect you mean "4p6".

The word "reject" does not appear in the C standard. In my own
writing I am trying henceforth to use "accept" exclusively and
not use "reject". For the safe of discussion I can take "reject"
to mean the logical complement of "accept", which is to say a
program is either accepted or rejected, never both and never
neither. Does that last sentence match your own usage?

The C standard has only one place where a statement is made about
accepting a program, saying in 4p6 that implementations shall
accept any strictly conforming program; no other paragraph in the
standard mentions accepting a program. Given that, it's hard for
me to understand how someone could read the standard as saying
anything other than that a program must be accepted if it is
strictly conforming, but if the program is not strictly conforming
then there is no requirement that it be accepted. In short form, a
program must be accepted if and only if it is strictly conforming.
Does that summary mean something different than your phrase "*only*
strictly conforming programs must be accepted"?. My understanding
of the C standard is that strictly conforming programs must be
accepted, but implementations are not required to accept any
program that is not strictly conforming.

In response to your question about 4p3, the short answer is that
any non-strictly-conforming program that an implementation chooses
not to accept is not correct in all other aspects, so 4p3 does not
apply. If you want to talk about that further we should split that
off into a separate thread, because 4p3 has nothing to do with
program acceptance.

I agree that an implementation that chooses not to accept any
program that it can determine to be not strictly conforming has
very little practical utility. On the other hand I don't think
that matters because no one is going to put in the effort needed to
produce such an implementation.

Regarding your last sentence

I don't see anything in the standard that says a
program can be rejected purely because it's not
strictly conforming, and I don't believe that was
the intent.

One, there is nothing in the C standard about rejecting a program,
only about what programs must be accepted, and

Two, in the last clause, I'm not completely sure what the "that"
is that you don't believe, but in any case I have no idea what
reasoning underlies your belief (or lack thereof). Can you
explain what it is you mean by that part of the sentence, and
what your reasoning is or why you think it?

On 11/02/2024 19:43, Thiago Adams wrote:
> Em 2/11/2024 9:06 AM, David Brown escreveu:
>> The best that can be done, is what is done today - compilers have lots
>> of warnings that can be enabled or disabled individually.  Some are
>> considered important enough and universal enough that they are enabled
>> by default.  There will be a group of warnings (gcc -Wall) that the
>> compiler developers feel are useful to a solid majority of developers
>> without having too many false positives on things the developers
>> consider good code.  And there will be an additional group of warnings
>> (gcc -Wall -Wextra) as a starting point for developers who want
>> stricter code rules, and who will usually then have explicit flags for
>> fine-grained control of their particular requirements.
>
> I think it is possible having the following.
> A way to specify a set of warnings/errors. It can be a string for instance.
> Make some warning in this set standard.
>
>> And beyond that, there are a variety of niche checking tools for
>> particular cases, and large (and often expensive) code quality and
>> static checking tool suites for more advanced checks.
>>
>>
>
> Yes, I agree we can have tools, and each tool can solve the problem.
>
> But my point in having something standardized is because we can have
> "standardized safety" and "standardized mechanism to control static
> analyses tools".
>
> The same assumptions you have in on compiler you can have in another.
>

I entirely agree that it would be nice if warnings and warning sets were
standardised - or at least there was a subset of standard warnings
supported. You'd have to pick new names for the subsets, and they would
probably have to be picked explicitly to avoid conflict with existing
code. But you could have a range of named string options for different
warnings, and sets of "standard C warning levels" - "scw1", "scw2", etc.

gcc and clang already cooperate a lot with warning names. Intel icc
follows them. You'd have to get MS on board to make it a reality - and
they are the ones who would have to do a lot of work on their tools and
IDEs, since they currently use a number system. (It could have been
worse - if they had used names, but different names, it would be more
confusing.)

And for MS to be interested, and to avoid duplication of effort, you'd
want C++ included from day one.

> We can compare this approach with C++ for instance, when in C++ we have
> an error and in C a warning, that means the error is part of the C++
> language, it works in the same way in any compiler.

C++ diagnostics have the same rules as for C. And the main C++
compilers part of the same compiler suites as the main C compilers.

The difference is that when C++ started to become mainstream, there was
little in the way of existing code - compilers could mark bad practices
as warnings or even errors, by default. For C, however, there was a
significant body of code and some code that compiled and worked would
fail to compile if the new checks were enabled by default. Thus the C
compilers left them off by default.

So the reason for stricter defaults in the major C++ compilers compared
to their C siblings is backwards compatibility for older C source code.

>
> The other advantage is not having each tool with its own annotations.
> Today GCC has some annotations, MSVC has SAL for instance etc.
>

On Sat, 10 Feb 2024 19:54:13 -0800, Tim Rentsch
<tr.17687@z991.linuxsc.com> wrote in <86sf1z4pwa.fsf@linuxsc.com>:

> vallor <vallor@cultnix.org> writes:
>
>> [...] I'm curious why there is resistance to conditionals written
>> like this:
>>
>> if( 1 == a)
>>
>> ...that is to say, with the constant first.
>>
>> I've done that in C and Perl. Are the aesthetics so
>> bad that I should quit that? Isn't it safer to write
>> it that way, so that a dropped "=" is pointed out on
>> compilation?
>
> Do you know the phrase too clever by half? It describes
> this coding practice. A partial solution at best, and
> what's worse it comes with a cost for both writers and
> readers of the code. It's easier and more effective just
> to use -Wparentheses, which doesn't muck up the code and
> can be turned on and off easily. There are better ways
> for developers to spend their time than trying to take
> advantage of clever but tricky schemes that don't help
> very much and are done more thoroughly and more reliably
> by using pre-existing automated tools. Too much buck,
> not nearly enough bang.

Thank you all for setting me straight on this. I'll stop
my yoda-conditionals, and start using -Wall.

--
-v

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:
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> [snip discussion of a program that divides by zero]
>>>>
>>>>> An implementation can refuse to translate the program, but not
>>>>> because undefined behavior occurs. The undefined behavior here
>>>>> happens only when the program is executed, but just compiling the
>>>>> program doesn't do that. No execution, no undefined behavior.
>>>>> Still the program may be rejected, because it is not strictly
>>>>> conforming (by virtue of having output depend on the undefined
>>>>> behavior if the program is ever run).
>>>>
>>>> Just to be clear, would you say that a conforming hosted
>>>> implementation may reject this program:
>>>>
>>>> #include <limits.h>
>>>> #include <stdio.h>
>>>> int main(void) {
>>>> printf("INT_MAX = %d\n", INT_MAX);
>>>> }
>>>>
>>>> solely because it's not strictly conforming?
>>>
>>> My understanding of the C standard is that a hosted implementation
>>> may choose not to accept the above program and still be conforming,
>>> because this program is not strictly conforming. (Please assume
>>> subsequent remarks always refer to implementations that are both
>>> hosted and conforming.)
>>>
>>> Also, assuming we have ruled out cases involving #error, a
>>> conforming implementation may choose not to accept a given program
>>> if and only if the program is not strictly conforming. Being
>>> strictly conforming is the only criterion that matters (again
>>> assuming there is no #error) in deciding whether an implementation
>>> may choose not to accept the program in question.
>>>
>>> I'm guessing that what you mean by "may reject" is the same as what
>>> I mean by "may choose not to accept". I'd like to know if you think
>>> that's right, or if you think there is some difference between the
>>> two. (My intention is that the two phrases have the same meaning.)
>>>
>>> Does the above adequately address the question you want answered?
>>
>> I'm not sure. As I recall, I gave up on trying to understand what
>> you think "accept" means.
>>
>> N1570 5.1.2.3p6:
[CORRECTION: 3p4]
>>
>> A program that is correct in all other aspects, operating on
>> correct data, containing unspecified behavior shall be a
>> correct program and act in accordance with 5.1.2.3.
>>
>> Does that not apply to the program above? How can it do so if it's
>> rejected (or not "accepted")?
>>
>> The same paragraph says that "A *conforming hosted implementation*
>> shall accept any strictly conforming program". Are you reading
>> that as implying that *only* strictly conforming programs must be
>> accepted?
>>
>> As a practical matter, an implementation that accepts *only*
>> strictly conforming programs would be very nearly useless. I
>> don't see anything in the standard that says a program can be
>> rejected purely because it's not strictly conforming, and I don't
>> believe that was the intent.
>
> My understanding of the C standard is that 'shall accept' is
> meant in the sense of 'shall use its best efforts to complete
> translation phases 1 through 8 successfully and produce an
> executable'.

That sounds reasonable. I wish the standard actually defined "accept".

> Where you say "5.1.2.3p6:" I expect you mean "4p3".

Yes.

> Where you say "the same paragraph" I expect you mean "4p6".

Yes.

> The word "reject" does not appear in the C standard. In my own
> writing I am trying henceforth to use "accept" exclusively and
> not use "reject". For the safe of discussion I can take "reject"
> to mean the logical complement of "accept", which is to say a
> program is either accepted or rejected, never both and never
> neither. Does that last sentence match your own usage?

Yes, "reject" means "not accept". There might be some nuance that that
definition misses, so I'll try to avoid using the word "reject" in this
discussion.

> The C standard has only one place where a statement is made about
> accepting a program, saying in 4p6 that implementations shall
> accept any strictly conforming program; no other paragraph in the
> standard mentions accepting a program. Given that, it's hard for
> me to understand how someone could read the standard as saying
> anything other than that a program must be accepted if it is
> strictly conforming, but if the program is not strictly conforming
> then there is no requirement that it be accepted. In short form, a
> program must be accepted if and only if it is strictly conforming.
> Does that summary mean something different than your phrase "*only*
> strictly conforming programs must be accepted"?. My understanding
> of the C standard is that strictly conforming programs must be
> accepted, but implementations are not required to accept any
> program that is not strictly conforming.

Certainly a conforming implementation must accept any strictly
conforming program (insert handwaving about capacity limits).

I can understand how one might read that requirement as implying that an
implementation need not accept any program that is not strictly
conforming. I don't read it that way.

> In response to your question about 4p3, the short answer is that
> any non-strictly-conforming program that an implementation chooses
> not to accept is not correct in all other aspects, so 4p3 does not
> apply. If you want to talk about that further we should split that
> off into a separate thread, because 4p3 has nothing to do with
> program acceptance.

I say it does. Under 4p3, the above program (that prints the value of
INT_MAX) is a "correct program", so it must "act in accordance with
5.1.2.3". It cannot do so unless it is first accepted.

You're saying that the correctness of a program can depend on whether an
implementation chooses to accept it. I disagree.

An implementation that does not accept the above program is not
conforming because the implementation violates 4p3.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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:
>>>>
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>> [snip discussion of a program that divides by zero]
>>>>>
>>>>>> An implementation can refuse to translate the program, but not
>>>>>> because undefined behavior occurs. The undefined behavior here
>>>>>> happens only when the program is executed, but just compiling the
>>>>>> program doesn't do that. No execution, no undefined behavior.
>>>>>> Still the program may be rejected, because it is not strictly
>>>>>> conforming (by virtue of having output depend on the undefined
>>>>>> behavior if the program is ever run).
>>>>>
>>>>> Just to be clear, would you say that a conforming hosted
>>>>> implementation may reject this program:
>>>>>
>>>>> #include <limits.h>
>>>>> #include <stdio.h>
>>>>> int main(void) {
>>>>> printf("INT_MAX = %d\n", INT_MAX);
>>>>> }
>>>>>
>>>>> solely because it's not strictly conforming?
>>>>
>>>> My understanding of the C standard is that a hosted implementation
>>>> may choose not to accept the above program and still be conforming,
>>>> because this program is not strictly conforming. (Please assume
>>>> subsequent remarks always refer to implementations that are both
>>>> hosted and conforming.)
>>>>
>>>> Also, assuming we have ruled out cases involving #error, a
>>>> conforming implementation may choose not to accept a given program
>>>> if and only if the program is not strictly conforming. Being
>>>> strictly conforming is the only criterion that matters (again
>>>> assuming there is no #error) in deciding whether an implementation
>>>> may choose not to accept the program in question.
>>>>
>>>> I'm guessing that what you mean by "may reject" is the same as what
>>>> I mean by "may choose not to accept". I'd like to know if you think
>>>> that's right, or if you think there is some difference between the
>>>> two. (My intention is that the two phrases have the same meaning.)
>>>>
>>>> Does the above adequately address the question you want answered?
>>>
>>> I'm not sure. As I recall, I gave up on trying to understand what
>>> you think "accept" means.
>>>
>>> N1570 5.1.2.3p6:
>
> [CORRECTION: 3p4]
>
>>> A program that is correct in all other aspects, operating on
>>> correct data, containing unspecified behavior shall be a
>>> correct program and act in accordance with 5.1.2.3.
>>>
>>> Does that not apply to the program above? How can it do so if it's
>>> rejected (or not "accepted")?
>>>
>>> The same paragraph says that "A *conforming hosted implementation*
>>> shall accept any strictly conforming program". Are you reading
>>> that as implying that *only* strictly conforming programs must be
>>> accepted?
>>>
>>> As a practical matter, an implementation that accepts *only*
>>> strictly conforming programs would be very nearly useless. I
>>> don't see anything in the standard that says a program can be
>>> rejected purely because it's not strictly conforming, and I don't
>>> believe that was the intent.
>>
>> My understanding of the C standard is that 'shall accept' is
>> meant in the sense of 'shall use its best efforts to complete
>> translation phases 1 through 8 successfully and produce an
>> executable'.
>
> That sounds reasonable. I wish the standard actually defined
> "accept".
>
>> Where you say "5.1.2.3p6:" I expect you mean "4p3".
>
> Yes.
>
>> Where you say "the same paragraph" I expect you mean "4p6".
>
> Yes.
>
>> The word "reject" does not appear in the C standard. In my own
>> writing I am trying henceforth to use "accept" exclusively and
>> not use "reject". For the safe of discussion I can take "reject"
>> to mean the logical complement of "accept", which is to say a
>> program is either accepted or rejected, never both and never
>> neither. Does that last sentence match your own usage?
>
> Yes, "reject" means "not accept". There might be some nuance that
> that definition misses, so I'll try to avoid using the word "reject"
> in this discussion.
>
>> The C standard has only one place where a statement is made about
>> accepting a program, saying in 4p6 that implementations shall
>> accept any strictly conforming program; no other paragraph in the
>> standard mentions accepting a program. Given that, it's hard for
>> me to understand how someone could read the standard as saying
>> anything other than that a program must be accepted if it is
>> strictly conforming, but if the program is not strictly conforming
>> then there is no requirement that it be accepted. In short form, a
>> program must be accepted if and only if it is strictly conforming.
>> Does that summary mean something different than your phrase "*only*
>> strictly conforming programs must be accepted"?. My understanding
>> of the C standard is that strictly conforming programs must be
>> accepted, but implementations are not required to accept any
>> program that is not strictly conforming.
>
> Certainly a conforming implementation must accept any strictly
> conforming program (insert handwaving about capacity limits).

No handwaving needed. If "accept" is taken to mean 'shall use its
best efforts to ...', etc., there is no problem with those efforts
failing for reasons outside the implementation's control.

> I can understand how one might read that requirement as implying
> that an implementation need not accept any program that is not
> strictly conforming. I don't read it that way.

James Kuyper has said

The standard never talks about rejection. It requires that
"A conforming hosted implementation shall accept any
strictly conforming program.". No such requirement applies
to any program which is not strictly conforming. (4p6)

Clearly James thinks implementations are free not to accept any
program that is not strictly conforming. Do you think James is
wrong?

In an earlier posting you said

I don't see anything in the standard that says a program can
be rejected purely because it's not strictly conforming, and
I don't believe that was the intent.

What is the basis for that belief? Can you point to some passage in
the C standard, or some other materials, that supports it? Or do
you believe it just because you think no sensible person could
intend otherwise?

>> In response to your question about 4p3, the short answer is that
>> any non-strictly-conforming program that an implementation chooses
>> not to accept is not correct in all other aspects, so 4p3 does not
>> apply. If you want to talk about that further we should split that
>> off into a separate thread, because 4p3 has nothing to do with
>> program acceptance.
>
> I say it does. Under 4p3, the above program (that prints the value
> of INT_MAX) is a "correct program", so it must "act in accordance
> with 5.1.2.3". It cannot do so unless it is first accepted.

It's a circular argument. You assume that a non-strictly conforming
program does not violate the requirement that the program be "correct
in all other aspects" and then conclude that the program is correct.
You're assuming the very thing you set out to prove.

What is the purpose of 4p3? What is the motivation for including it
in the C standard? Do you think it's there only to make programs
like the INT_MAX program above be non-rejectable? What else does it
do? What do you think is meant by "act in accordance with 5.1.2.3"?
Besides the C standard, what other materials or resources have you
consulted in forming your opinions or drawing your conclusions?