Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #382072 > unrolled thread

Is C ready to become a safer language?

Back to article view | Back to comp.lang.c

Contents

  Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 01:01 -0300
    Re: Is C ready to become a safer language? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 04:40 +0000
      Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 05:00 +0000
      Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 09:20 -0300
        Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-08 17:02 +0000
          Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 14:17 -0300
            Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 14:19 -0300
            Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 09:57 -0800
        Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 09:45 -0800
          Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 14:56 -0300
    Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 04:58 +0000
      Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-07 21:33 -0800
    Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-07 20:59 -0800
      Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-08 09:17 +0100
        Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 09:48 -0300
          Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 14:42 +0000
          Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-08 16:25 +0100
            Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 13:15 -0300
              Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-08 21:42 +0100
        Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 08:04 -0800
          Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 16:14 +0000
            Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 08:32 -0800
            Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 08:19 +0100
              Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 07:46 +0000
                Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 09:33 +0100
                  Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 10:03 +0000
                    Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 11:17 +0100
                  Re: Is C ready to become a safer language? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 10:24 +0000
                    Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 11:24 +0000
                      Re: Is C ready to become a safer language? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 13:28 +0000
                        Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 14:04 +0000
                      Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 15:03 +0100
                        ustent on that. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 16:01 +0000
                          Re: ustent on that. David Brown <david.brown@hesbynett.no> - 2024-02-09 18:00 +0100
                            Re: ustent on that. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-10 01:20 +0000
                    Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-09 12:45 +0000
                      Re: Is C ready to become a safer language? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 13:01 +0000
                        Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 15:08 +0100
                Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 08:48 -0800
          Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 08:14 +0100
            Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 08:28 -0800
              Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 20:15 +0100
      Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 02:28 -0800
        Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 16:15 -0800
          Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 23:22 -0800
            Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 00:12 -0800
              Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-11 23:48 -0800
                Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-18 15:28 -0800
                  Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-23 10:35 -0700
    Re: Is C ready to become a safer language? Richard Kettlewell <invalid@invalid.invalid> - 2024-02-08 15:37 +0000
      Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 13:25 -0300
    Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-08 16:30 +0000
      Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-09 17:59 -0800
        Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-10 20:22 +0000
          Re: Is C ready to become a safer language? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-10 21:30 +0000
          Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-10 21:49 +0000
            Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-10 20:44 -0300
              Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:06 +0100
                Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-11 15:43 -0300
                  Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 13:33 -0800
                  Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-12 11:32 +0100
            Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 00:02 +0000
              Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 17:39 -0800
              Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-11 02:46 +0000
                Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 12:24 +0000
                  Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 15:06 +0100
                  Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-11 18:32 +0000
              Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:15 +0100
          Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 16:31 -0800
            Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-11 15:57 -0300
              Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 13:47 -0800
          Re: Is C ready to become a safer language? vallor <vallor@cultnix.org> - 2024-02-11 00:40 +0000
            Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 01:06 +0000
            Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 17:51 -0800
              Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:27 +0100
            Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 19:54 -0800
              Re: Is C ready to become a safer language? vallor <vallor@cultnix.org> - 2024-02-13 06:22 +0000
            Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-11 11:01 +0000
              Re: Is C ready to become a safer language? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-11 11:31 +0000
                Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 12:38 +0000
                  Re: Is C ready to become a safer language? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-11 13:23 +0000
                    Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 14:17 +0000
          Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 22:21 -0800

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#382203

David Brown <david.brown@hesbynett.no> writes:
[...]
> But I am not sure that the /compiler/ knows that it is compiling for a
> hosted or freestanding implementation.  The same gcc can be used for 
> Linux hosted user code  and a freestanding Linux kernel.
[...]

A conforming compiler must predefine the macro __STDC_HOSTED__ to either
0 or 1 (since C99).

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#382223

On 09/02/2024 17:28, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> But I am not sure that the /compiler/ knows that it is compiling for a
>> hosted or freestanding implementation.  The same gcc can be used for
>> Linux hosted user code  and a freestanding Linux kernel.
> [...]
> 
> A conforming compiler must predefine the macro __STDC_HOSTED__ to either
> 0 or 1 (since C99).
> 

Okay, that looks like a difference.  A compiler could, I believe, call 
itself "freestanding", define that to 0, and otherwise act exactly like 
a hosted implementation.  But it seems unlikely.

[toc] | [prev] | [next] | [standalone]

#382263

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Thiago Adams <thiago.adams@gmail.com> writes:
>
>> Let's say C compilers can detect all sorts of bugs at compile time.
>>
>> How would C compilers report that?  As an error or a warning?
>>
>> Let's use this sample:
>>
>> int main() {
>>     int a = 1;
>>     a = a / 0;
>> }
>>
>> GCC says:
>>
>> warning: division by zero is undefined [-Wdivision-by-zero]
>>     5 |  a = a / 0;
>>       |        ^ ~
>>
>> In case GCC or any other compiler reports this as an error, then C
>> programmers would likely complain.  Am I right?
>
> Someone will always complain, but a conforming compiler can report this
> as a fatal error.
>
> Division by zero has undefine behavior.  Under the standard's definition
> of undefined behavior, it says:
>
>     NOTE
>
>     Possible undefined behavior ranges from ignoring the situation
>     completely with unpredictable results, to behaving during
>     translation or program execution in a documented manner
>     characteristic of the environment (with or without the issuance
>     of a diagnostic message), to terminating a translation or
>     execution (with the issuance of a diagnostic message).
>
> Though it's not quite that simple.  Rejecting the program if the
> compiler can't prove that the division will be executed would IMHO
> be non-conforming.  Code that's never executed has no behavior, so
> it doesn't have undefined behavior.

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).

[toc] | [prev] | [next] | [standalone]

#382293

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?

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#382312

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?

[toc] | [prev] | [next] | [standalone]

#382313

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.

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#382369

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?

[toc] | [prev] | [next] | [standalone]

#382726

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 */

[toc] | [prev] | [next] | [standalone]

#383931

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?

Suppose 4p3 were not included in the C standard.  How would that
change the C language?  What would be different, besides questions
like the one we are considering now?

The C90 standard does not include any requirement along the lines of
4p3 in C99 and later.  Does that mean C90 is different in some way?
What prompted the insertion of 4p3 into C99?  What efforts have you
made to investigate that?  Or have you not made any?

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

Certainly whether a program is strictly conforming CAN make a
difference in whether a program is "correct in all other aspects"
with respect to whether 4p3 applies.  I have posted an example
actually observed in the behaviors of gcc and clang (having to do
with the size of an array type).  The example violates no
constraints or syntax rules, has no undefined behavior, and uses
only language features specified in the C standard.  Despite all
that clang rejects it.  The only basis for clang's rejecting the
program is that the program is not strictly conforming.  So one way
or another 4p3 is not relevant.

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

Your reasoning the 4p3 applies here is flawed, because it's a
circular argument.  More compellingly, you haven't presented any
evidence that 4p3 is meant to be relevant to the question of
acceptance.  I know you think it is, and you have offered some
reasoning why it should be, but your explanations are not evidence.
What leads you to believe that members of the ISO C committee look
at this issue the same way you do?  Have you made any effort to
answer that question?

[toc] | [prev] | [next] | [standalone]

#382108

Thiago Adams <thiago.adams@gmail.com> writes:
> From my point of view, we need an error, not a warning. But we also
> need a way to ignore the error in case the programmer wants to see
> what happens, with a division by zero, for instance. (Please note that
> this topic IS NOT about this specific warning; it is just a sample.)

All this already exists. Compilers warn about many possible or actual
problems (such as your example) and the warnings can be selectively or
globally turned into errors.  For example see:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Warning-Options.html#index-Werror

> Warnings work more or less like this. The problem with warnings is
> that they are not standardized - the "name/number" and the way to
> disable/enable them.

Having to configure warnings and errors separately for each compiler in
a multi-platform environment is a tiny cost compared to the cost of
developing and maintaining cross-platform source code, multiple build
platforms, multiple test platforms, etc. So I don’t think there’s much
benefit to be hand from standardization here. Historically the addition
of useful warning options to compilers has outpaced the development of
the C standard in any case.

> So this is the first problem we need to solve in C to make the
> language safer. We need a mechanism.
>
> I also believe we can have a standard profile for warnings that will
> change the compiler behaviour; for instance, making undefined
> behaviour an error.

This can’t be done completely at compile time, at least not without an
unacceptably high level of false positives.

Tools do exist to detect undefined behavior at runtime and terminate the
program, though. A couple of examples are:

  https://clang.llvm.org/docs/MemorySanitizer.html
  https://clang.llvm.org/docs/AddressSanitizer.html

However there are severe limitations:
* Coverage is only partial.
* Performance is impacted.
* Some of the tools are unsuited to production environments, see e.g.
  https://www.openwall.com/lists/oss-security/2016/02/17/9

You could also look at (partial) hardware-based responses to the
undefined behavior problem such as
https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#382114

Em 2/8/2024 12:37 PM, Richard Kettlewell escreveu:
> Thiago Adams <thiago.adams@gmail.com> writes:
>>  From my point of view, we need an error, not a warning. But we also
>> need a way to ignore the error in case the programmer wants to see
>> what happens, with a division by zero, for instance. (Please note that
>> this topic IS NOT about this specific warning; it is just a sample.)
> 
> All this already exists. Compilers warn about many possible or actual
> problems (such as your example) and the warnings can be selectively or
> globally turned into errors.  For example see:
> https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Warning-Options.html#index-Werror

It is not standard making safety not portable.

>> Warnings work more or less like this. The problem with warnings is
>> that they are not standardized - the "name/number" and the way to
>> disable/enable them.
> 
> Having to configure warnings and errors separately for each compiler in
> a multi-platform environment is a tiny cost compared to the cost of
> developing and maintaining cross-platform source code, multiple build
> platforms, multiple test platforms, etc. So I don’t think there’s much
> benefit to be hand from standardization here. Historically the addition
> of useful warning options to compilers has outpaced the development of
> the C standard in any case.

See my sample comparing GCC and MSVC pragma to disable warnings.
I believe that code can be improved.
>> So this is the first problem we need to solve in C to make the
>> language safer. We need a mechanism.
>>
>> I also believe we can have a standard profile for warnings that will
>> change the compiler behaviour; for instance, making undefined
>> behaviour an error.
> 
> This can’t be done completely at compile time, at least not without an
> unacceptably high level of false positives.

For now I am just assuming it can, them we can focus on the mechanism of 
control.
But since you pointed the problems.. going further, and comparing with 
Rust for instance, the static analysis will require flow analysis.
Imagine to have to specify how flow analysis should behave in all 
compilers? This is a problem that Rust does not have.
Basically it is an specification for static analysis not only the 
language. It could be an separated document.
What are the benefits? I believe C language as a whole would pass a new 
and important message of safety.

[toc] | [prev] | [next] | [standalone]

#382116

On 08/02/2024 04:01, Thiago Adams wrote:
> 
> Let's say C compilers can detect all sorts of bugs at compile time.
> 
> How would C compilers report that? As an error or a warning?
> 
> Let's use this sample:
> 
> int main() {
>      int a = 1;
>      a = a / 0;
> }
> 
> GCC says:
> 
> warning: division by zero is undefined [-Wdivision-by-zero]
>      5 |  a = a / 0;
>        |        ^ ~
> 
> In case GCC or any other compiler reports this as an error, then C 
> programmers would likely complain. Am I right?
> 
> So, even if we had compile-time checks for bugs, C compilers and the 
> standard are not prepared to handle the implications to make C a safer 
> language.
> 
>  From my point of view, we need an error, not a warning. But we also 
> need a way to ignore the error in case the programmer wants to see what 
> happens, with a division by zero, for instance.

Replace the 0 with a variable containing zero at runtime.

  (Please note that this
> topic IS NOT about this specific warning; it is just a sample.)
> 
> Warnings work more or less like this. The problem with warnings is that 
> they are not standardized - the "name/number" and the way to 
> disable/enable them.
> 
> So this is the first problem we need to solve in C to make the language 
> safer. We need a mechanism.
> 
> I also believe we can have a standard profile for warnings that will 
> change the compiler behaviour; for instance, making undefined behaviour 
> an error.
> 
> The C standard is complacent with the lack of error messages. Sometimes 
> it says "message is encouraged...". This shifts the responsibility from 
> the language. But when someone says "C is dangerous," the language as a 
> whole is blamed, regardless of whether you are using MISRA, for instance.
> 
> Thus, not only are the mechanics of the language is unprepared, but the 
> standard is also not prepared to assume the responsibility of being a 
> source of guidance and safety.

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.

So, taking gcc as an example, the same program may:

  * Pass, and generate a runnable binary

  * Warn, and generate a runnable binary still

  * Fail with a hard error.

But the latter is unusual; you might get it with a syntax error for example.

The compiler-behaviour yet get depends on the options that are supplied, 
which in turn depends on the programmer: THEY get to choose whether a 
program passes or not, something you that you might expect to be the 
compiler's job!

The compiler power-users here will have their own set-ups that define 
which classes of programs will pass or fail. But I think compilers 
should do that out of the box.


--------------------------------------------------

c:\c>type c.c
int main(void) {
         int a, b;
         a=b/0;
}

c:\c>tcc c.c

c:\c>gcc c.c
c.c: In function 'main':
c.c:3:5: warning: division by zero [-Wdiv-by-zero]
     3 |  a=b/0;
       |     ^

c:\c>mcc c
Compiling c.c to c.exe
Proc: main
MCL Error: Divide by zero Line:3 in:c.c

[toc] | [prev] | [next] | [standalone]

#382253

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.

I think the answer is obvious:  unless and until you find someone
who works on a C compiler and who has exactly the same sense that
you do of "when there is obviously something wrong" and of what
conditions fall under the heading of "completely harmless matters",
and also the same sense that you do of how a C compiler should
behave in those cases, you won't get exactly what you want unless
you do it yourself.

[toc] | [prev] | [next] | [standalone]

#382278

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.
> 
> I think the answer is obvious:  unless and until you find someone
> who works on a C compiler and who has exactly the same sense that
> you do of "when there is obviously something wrong" and of what
> conditions fall under the heading of "completely harmless matters",
> and also the same sense that you do of how a C compiler should
> behave in those cases, you won't get exactly what you want unless
> you do it yourself.


Take this function:

   void F() {
     F();
     F(1);
     F(1, 2.0);
     F(1, 2.0, "3");
     F(1, 2.0, "3", F);
   }

Even if /one/ of those calls is correct, the other four can't be 
possibly be correct as well.

Is there anyone here who doesn't think there is something obviously wrong?

How about this one:

   #include <stdio.h>
   int main(void) {
     int a;
     L1:
     printf("Hello, World!\n");
   }

Ramp up the warnings and a compiler will tell you about unused 'a' and 
'L1'. Use -Werror and the compilation will fail.

Is there anyone here who thinks that running this program with those 
unused identifiers is not completely harmless?

[toc] | [prev] | [next] | [standalone]

#382281

On 10/02/2024 20:22, bart wrote:
> 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.
>>
>> I think the answer is obvious:  unless and until you find someone
>> who works on a C compiler and who has exactly the same sense that
>> you do of "when there is obviously something wrong" and of what
>> conditions fall under the heading of "completely harmless matters",
>> and also the same sense that you do of how a C compiler should
>> behave in those cases, you won't get exactly what you want unless
>> you do it yourself.
> 
> 
> Take this function:
> 
>    void F() {
>      F();
>      F(1);
>      F(1, 2.0);
>      F(1, 2.0, "3");
>      F(1, 2.0, "3", F);
>    }
> 
> Even if /one/ of those calls is correct, the other four can't be 
> possibly be correct as well.
> 
> Is there anyone here who doesn't think there is something obviously wrong?

Gcc says, "warning: passing arguments to 'F' without a prototype is 
deprecated in all versions of C and is not supported in C2x 
[-Wdeprecated-non-prototype]"
> 
> How about this one:
> 
>    #include <stdio.h>
>    int main(void) {
>      int a;
>      L1:
>      printf("Hello, World!\n");
>    }
> 
> Ramp up the warnings and a compiler will tell you about unused 'a' and 
> 'L1'. Use -Werror and the compilation will fail.
> 
> Is there anyone here who thinks that running this program with those 
> unused identifiers is not completely harmless?

The point of the warning is that maybe you meant to use them.  Remove 
them if they're not needed, or fix the code so they do get used.

[toc] | [prev] | [next] | [standalone]

#382284

On 2024-02-10, bart <bc@freeuk.com> wrote:
>    #include <stdio.h>
>    int main(void) {
>      int a;
>      L1:
>      printf("Hello, World!\n");
>    }
>
> Ramp up the warnings and a compiler will tell you about unused 'a' and 
> 'L1'. Use -Werror and the compilation will fail.
>
> Is there anyone here who thinks that running this program with those 
> unused identifiers is not completely harmless?

Unused warnings exist because they help catch bugs.

  double distance(double x, double y)
  {
    return sqrt(x*x + x*x);
  }

The diagnostic will not catch all bugs of this type, since just one use is
enough to silence it, but catching something is better than nothing. 

Removing unused cruft also helps to keep the code clean. Stray material
sometimes gets left behind after refactoring, or careless copy paste.
Unused identifiers are a "code smell".

Sometimes something must be left unused. It's good to be explicit about
that: to have some indication that it's deliberately unused.

When I implemented unused warnings in my Lisp compiler, I found a bug right away.

https://www.kylheku.com/cgit/txr/commit/?id=5ee2cd3b2304287c010237e03be4d181412e066f

In this diff hunk against in the assembler:

@@ -217,9 +218,9 @@
              (q me.(cur-pos)))
         (inc c)
         me.(set-pos p)
-        (format t "~,5d: ~,08X ~a\n" (trunc p 4) me.(get-word) dis-txt)
+        (format stream "~,5d: ~,08X ~a\n" (trunc p 4) me.(get-word) dis-txt)
         (while (< (inc p 4) q)
-          (format t "~,5d: ~,08X\n" (trunc p 4) me.(get-word)))
+          (format stream "~,5d: ~,08X\n" (trunc p 4) me.(get-word)))
         me.(set-pos q)
         (set p q)))
     c))

The format function was given argument t, a nickname for standard output, so
this code ignored the stream parameter and always sent output to standard
output.

With the unused warnings, it got diagnosed.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#382289

Em 2/10/2024 6:49 PM, Kaz Kylheku escreveu:
> On 2024-02-10, bart <bc@freeuk.com> wrote:
>>     #include <stdio.h>
>>     int main(void) {
>>       int a;
>>       L1:
>>       printf("Hello, World!\n");
>>     }
>>
>> Ramp up the warnings and a compiler will tell you about unused 'a' and
>> 'L1'. Use -Werror and the compilation will fail.
>>
>> Is there anyone here who thinks that running this program with those
>> unused identifiers is not completely harmless?
> 
> Unused warnings exist because they help catch bugs.
> 
>    double distance(double x, double y)
>    {
>      return sqrt(x*x + x*x);
>    }


Unused warning is a good sample to explain my point of view.
I want a "warning profile" inside the compiler to do a "automatic code 
review".
The criteria is not only complain about UB etc..the criteria is the same
used by humans (in the context of the program, how critical etc) to 
approve or not a code.

Unused is a good sample, a human reviewing your code would ask why 
something is not used for instance.

In code review I also try to make a code review that does not depend on 
the review of the caller.

for instance

void f(int a[])
{
   a[1]= 1;
}


this code depends review of the caller.

We can create alternatives that will check input.

void f(int n, int a[n])
{

}
I wish a warning profile to catch this type of "caller" dependent function.
The other common sample is null pointers, where the function assumes the 
caller will not pass a null pointer.

I want to have a classification for that - a "name" - to classify 
function with "caller contract dependent" something like that.



One way I am thinking to create a warning profile is a set of warnings I 
want as as error etc..
then the user can configure the compiler according with the company 
guidelines.

The idea of making warnings part of the C standard helps to make "safety 
portable" then the program can have the same guarantees independent of 
the tool used.

[toc] | [prev] | [next] | [standalone]

#382321

On 11/02/2024 00:44, Thiago Adams wrote:
> Em 2/10/2024 6:49 PM, Kaz Kylheku escreveu:
>> On 2024-02-10, bart <bc@freeuk.com> wrote:
>>>     #include <stdio.h>
>>>     int main(void) {
>>>       int a;
>>>       L1:
>>>       printf("Hello, World!\n");
>>>     }
>>>
>>> Ramp up the warnings and a compiler will tell you about unused 'a' and
>>> 'L1'. Use -Werror and the compilation will fail.
>>>
>>> Is there anyone here who thinks that running this program with those
>>> unused identifiers is not completely harmless?
>>
>> Unused warnings exist because they help catch bugs.
>>
>>    double distance(double x, double y)
>>    {
>>      return sqrt(x*x + x*x);
>>    }
> 
> 
> Unused warning is a good sample to explain my point of view.
> I want a "warning profile" inside the compiler to do a "automatic code 
> review".
> The criteria is not only complain about UB etc..the criteria is the same
> used by humans (in the context of the program, how critical etc) to 
> approve or not a code.
> 

While I appreciate the desire here, it is completely impossible in 
practice.  There are two main hinders.  One is that different people 
want different things from code reviews - code that is fine and 
acceptable practice for one group or on one project might be banned 
outright in another project or group.  The other is that code reviewers 
generally know more than you can express in code (even if you have a 
language that supports assumptions, assertions, and contracts), and this 
knowledge is important in code reviews but cannot be available to 
automatic tools.

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.

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.

[toc] | [prev] | [next] | [standalone]

#382340

Em 2/11/2024 9:06 AM, David Brown escreveu:
> On 11/02/2024 00:44, Thiago Adams wrote:
>> Em 2/10/2024 6:49 PM, Kaz Kylheku escreveu:
>>> On 2024-02-10, bart <bc@freeuk.com> wrote:
>>>>     #include <stdio.h>
>>>>     int main(void) {
>>>>       int a;
>>>>       L1:
>>>>       printf("Hello, World!\n");
>>>>     }
>>>>
>>>> Ramp up the warnings and a compiler will tell you about unused 'a' and
>>>> 'L1'. Use -Werror and the compilation will fail.
>>>>
>>>> Is there anyone here who thinks that running this program with those
>>>> unused identifiers is not completely harmless?
>>>
>>> Unused warnings exist because they help catch bugs.
>>>
>>>    double distance(double x, double y)
>>>    {
>>>      return sqrt(x*x + x*x);
>>>    }
>>
>>
>> Unused warning is a good sample to explain my point of view.
>> I want a "warning profile" inside the compiler to do a "automatic code 
>> review".
>> The criteria is not only complain about UB etc..the criteria is the same
>> used by humans (in the context of the program, how critical etc) to 
>> approve or not a code.
>>
> 
> While I appreciate the desire here, it is completely impossible in 
> practice.  There are two main hinders.  One is that different people 
> want different things from code reviews - code that is fine and 
> acceptable practice for one group or on one project might be banned 
> outright in another project or group.  The other is that code reviewers 
> generally know more than you can express in code (even if you have a 
> language that supports assumptions, assertions, and contracts), and this 
> knowledge is important in code reviews but cannot be available to 
> automatic tools.
> 
> 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.

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.

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

[toc] | [prev] | [next] | [standalone]

#382349

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 */

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web