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

On Thu, 8 Feb 2024 01:01:56 -0300, Thiago Adams wrote:

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

Do you want C to turn into Java? In Java, rules about reachability are
built into the language. And these rules are simplistic ones, based on
the state of the art back in the 1990s, not taking account of
improvements in compiler technology since then. For example, in the
following code, the uninitialized declaration of “Result” is a
compile-time error, even though a human looking at the code can figure
out that there is no way it will be left uninitialized at the point of
reference:

char Result; /* not allowed! */
boolean LastWasBackslash = false;
for (;;)
{
++ColNr;
final int ich = Input.read();
if (ich < 0)
{
--ColNr;
EOF = true;
Result = '\n';
break;
}
else if (LastWasCR && (char)ich == '\012')
{
/* skip LF following CR */
--ColNr;
LastWasCR = false;
LastWasBackslash = false;
}
else if (!LastWasBackslash && (char)ich == '\\')
{
LastWasBackslash = true;
LastWasCR = false;
}
else if (!LastWasBackslash || !IsEOL((char)ich))
{
Result = (char)ich;
break;
}
else
{
++LineNr;
ColNr = 0;
LastWasCR = (char)ich == '\015';
LastWasBackslash = false;
} /*if*/
} /*for*/
EOL = EOF || IsEOL(Result);
LastWasCR = Result == '\015';

On 2024-02-08, Thiago Adams <thiago.adams@gmail.com> 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?

ISO C doesn't distinguish "error" from "warning"; it speaks only about
diagnostics. It requires diagnostics for certain situations.

In compiler (not ISO C) parlance, we might understand "error" to be a
situation when a diagnostic is issued, and the implementation terminates
the translation, so that a translated program or translation unit is not
produced.

A "warning" is any other situation when a diagnostic is issued and
translation continues.

(These concepts extend into run-time. There could be a run-time diagnostic
which doesn't terminate the program, and one which does.)

With these definitions ...

> 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?

They might.

A programmer taking a standard-based view might remark that
the program is not required to be diagnosed by ISO C.

It does invoke undefined behavior if executed, though.

Based on the deduction that the program has unconditional undefined
behavior, it is legitimate to terminate translating the program with a
diagnostic, since that is a possible consequence of undefined behavior.

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

Implementations are free to implement arbitrary diagnostics, and also
nonconforming modes of translation, which stop translating a program
that does not violate any ISO C syntax or constraint rule.

Thus compilers can provide tools to help programmers enforce
rules that don't exist in the language as such.

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

I don't believe so. The C standard absolutely requires diagnostics
for certain situations. Everywhere else, it doesn't.

I don't remember seeing any text "encouraging" a diagnostic.
That's ambiguous: is it really required or not?

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

The standard specifies which constructs are required to do what under
what conditions, and those situations are safe.

Sometimes "do what" is unspecified (the implementation choices from a
range of safe behaviors) or implementation-defined (similar, but
implementation also documents the choice).

The standard also specifies that some situations must be diagnosed,
like syntax and type errors and other constraint rule violations.

Everything else is undefined behavior (some of it potentially
defined by the implementation as a "documented extension").

Avoidance of undefined behavior is left to the careful design
of the program, and whatever tools the implementation and third parties
provide for detecting undefined behavior.

Some languages, like Common Lisp, provide a notion of safety level.
Over individual expressions in Lisp, we can declare optimization
parameters: safety (0-3) and speed (0-3). We can also declare facts to
the Common Lisp compiler like types of operands and results. When we
lie to the compiler, the behavior becomes undefined, but the situation
is nuanced. Safe code diagnoses errors. If we tell the Lisp compiler
that some X is a cons cell, and then access (car X), but at run time, X
turns out to be a string, an error will be signaled. However, if we
compile the code with safety 0, all bets are off: the machine code may
blindly access the string object as if it were a cons cell, with
disastrous consequences.

C could benefit from an approach along these lines. The big problem is
that in C it's hard to impossible to make many undefined behaviors
safe (as in detect them and abort the program).

For isntance, there is no way to tell whether a pointer is valid
or not, or how large an array it points to.

Lisp is a safe, dynamic language first, and an aggressively optimized
language second. It's easy to tell that (car X) is accessing a string
and not a cons cell thanks to the run-time information in the objects.

It's easier to strip away safety from a safe language, and generate
unsafe code that works with lower level machine types, than to introduce
safety into a machine-oriented language, because the data
representations don't accomodate the needed run-time bits.

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

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.

But of course any compiler can reject anything it likes in
non-conforming mode. See for example "gcc -Werror".

But even ignoring that, a culture of paying very close attention to
non-fatal warnings could go a long way towards making C safer (assuming
compilers are clever enough to issue good warnings).

[...]

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

On 2024-02-08, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Thu, 8 Feb 2024 01:01:56 -0300, Thiago Adams wrote:
>
>> 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.
>
> Do you want C to turn into Java? In Java, rules about reachability are
> built into the language. And these rules are simplistic ones, based on
> the state of the art back in the 1990s, not taking account of
> improvements in compiler technology since then. For example, in the
> following code, the uninitialized declaration of “Result” is a
> compile-time error, even though a human looking at the code can figure
> out that there is no way it will be left uninitialized at the point of
> reference:

Because C doesn't mandate such a warning, GCC was able to rid itself
of naive, badly implemented diagnostics in this area.

I have some old installations of GCC which still warn about some of my
code (that some variable might be used uninitialized). Newer compilers
are silent on that code, due to doing better analysis.

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

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-02-08, Thiago Adams <thiago.adams@gmail.com> wrote:
[...]
>> The C standard is complacent with the lack of error messages. Sometimes
>> it says "message is encouraged...". This shifts the responsibility from
>
> I don't believe so. The C standard absolutely requires diagnostics
> for certain situations. Everywhere else, it doesn't.
>
> I don't remember seeing any text "encouraging" a diagnostic.
> That's ambiguous: is it really required or not?

Search for "Recommended practice" in the standard. For example,
N1570 6.7.4p9:

Recommended practice

The implementation should produce a diagnostic message for a
function declared with a _Noreturn function specifier that appears
to be capable of returning to its caller.

[...]

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

On 08/02/2024 05:59, Keith Thompson wrote:
> 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.
>

I'm not /entirely/ convinced. Such code is only undefined behaviour at
run-time, I believe. A compiler could reject the code (give a fatal
error) if it is sure that this will be reached when the code is run.
But can it be sure of that, even if it is in "main()" ? Freestanding
implementations don't need to run "main()" (not all my programs have had
a "main()" function), and the freestanding/hosted implementation choice
is a matter of the implementation, not just the compiler.

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

Indeed.

In particular, someone could write :

static inline void undefined_behaviour(void) {
1 / 0;
}

and use that for a "can never happen" indicator for compiler optimisation :

int foo(int x) {
if (x < 0) undefined_behaviour();
// From here on, the compiler can optimise using the
// assumption that x >= 0
...
}

gcc and clang have __builtin_unreachable() for this purpose - "calling"
that function that is always run-time undefined behaviour.

> But of course any compiler can reject anything it likes in
> non-conforming mode. See for example "gcc -Werror".
>

Yes. Once I have a project roughly in shape, I always enable that so
that I don't miss any warnings.

> But even ignoring that, a culture of paying very close attention to
> non-fatal warnings could go a long way towards making C safer (assuming
> compilers are clever enough to issue good warnings).
>

Yes.

I think it would be better if compilers were stricter in their default
modes, even if their stricter compliant modes have to reduce the
severity of some warnings. People should be allowed to write "weird"
code that looks very much like an error - but perhaps it is those people
who should need extra flags or other effort, not those that write
"normal" code and want to catch their bugs. (I know this can't be done
for tools like gcc, because it could cause problems with existing code.)

Still, I am happy to see that the latest gcc trunk has made some pre-C99
features into fatal errors instead of warnings - implicit function
declarations are now fatal errors.

Em 2/8/2024 1:40 AM, Lawrence D'Oliveiro escreveu:
> On Thu, 8 Feb 2024 01:01:56 -0300, Thiago Adams wrote:
>
>> 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.
>
> Do you want C to turn into Java?

No. In this topic I am assuming that the compilers can catch all sorts
of bugs in compile time.
With this assumption in mind, my point is that the standard is not
prepared to handle the implications.

Because:

1 - There is no universal mechanism for enable/disable warnings. Each
compiler does in a different way using pragma, and there is no guidance
in the standard with a rule number for instance.

2 - Because C avoids breaking code, it also needs something like a
warning profile.

3 - Maybe the standard is not prepared to assume the task of central
point of guidance about safety.

Another sample:

int main()
{ int a[2];
a[3] = 1;
}

GCC says

warning: array index 3 is past the end of the array (that has type
'int[2]') [-Warray-bounds]
5 | a[3] = 1;
| ^ ~

One more:

struct X {double d;};
struct Y {int i;};
int main()
{ struct X x;
struct Y *p;
p = &x;
}

GCC says:

warning: incompatible pointer types assigning to 'struct Y *' from
'struct X *' [-Wincompatible-pointer-types]
7 | p = &x;
| ^ ~~

For this one a C++ compiler gives:

<source>:7:6: error: cannot convert 'X*' to 'Y*' in assignment
7 | p = &x;

So, this may be also related with the "spirit of C". I like the idea of
the programmer can do whatever they want.
BUT, I think my default the compiler must complain.

Then I think we could have in the standard a better guidance about
safety defaults, and to avoid breaking code, the standard could define
safety profiles.

I also would like to note that some languages that have one main
implementation like rust does not have this problem..because the
specification is more or less the implementation of one compiler.

This will never be the case of C so I am wondering how the standard
could be written for at same time.

- keep compiling existing code
- give guidance and safety guarantees
- make code safe by default

Without this the C language is abstract about safety.

Consider the question

"Is C language safe?"

The answer will be , well, the language itself is very vague, depends
of the compiler you use.

The other problem is that we may need annotations and maybe other
changes on the type system. C23 now has attributes.

My point is also that safety , cannot be on the compiler side only,
because each compiler can have a different annotations.

Em 2/8/2024 5:17 AM, David Brown escreveu:
....
> I think it would be better if compilers were stricter in their default
> modes, even if their stricter compliant modes have to reduce the
> severity of some warnings.  People should be allowed to write "weird"
> code that looks very much like an error - but perhaps it is those people
> who should need extra flags or other effort, not those that write
> "normal" code and want to catch their bugs.  (I know this can't be done
> for tools like gcc, because it could cause problems with existing code.)

Yes this is my point.
But I believe we need a standard mechanism, and this is the first step
towards safety in C.

Consider this code.

int main(void)
{ int a = 1, b = 2;

#ifdef _MSC_VER
#pragma warning( push )
#pragma warning( disable : 4706 )
#else
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wparentheses"
#endif

if (a = b){}

#ifdef _MSC_VER
#pragma warning( pop )
#else
#pragma GCC diagnostic pop
#endif
}

This code wants to use a = b inside the if condition.
The code shows how to disable the warning in GCC and MSCV.

If we had in the standard a number for the warning, and a mechanism for
disabling then we could have something like

int main(void)
{ int a = 1, b = 2;

if (a = b) [[disable:4706]]
{
}
}

Maybe

int main(void)
{ int a = 1, b = 2;

if (a = b) _ignore("I want to assign here...")
{
}
}

That is applied to any warning on that specific line.
The advantage is the warning ID is not necessary

On 08/02/2024 12:48, Thiago Adams wrote:
> Em 2/8/2024 5:17 AM, David Brown escreveu:
> ...
>> I think it would be better if compilers were stricter in their default
>> modes, even if their stricter compliant modes have to reduce the
>> severity of some warnings.  People should be allowed to write "weird"
>> code that looks very much like an error - but perhaps it is those
>> people who should need extra flags or other effort, not those that
>> write "normal" code and want to catch their bugs.  (I know this can't
>> be done for tools like gcc, because it could cause problems with
>> existing code.)
>
>
> Yes this is my point.
> But I believe we need a standard mechanism, and this is the first step
> towards safety in C.
>
> Consider this code.
>
> int main(void)
> {
>     int a = 1, b = 2;
>
>     #ifdef _MSC_VER
>       #pragma warning( push )
>       #pragma warning( disable : 4706 )
>     #else
>       #pragma GCC diagnostic push
>       #pragma GCC diagnostic ignored "-Wparentheses"
>     #endif
>
>     if (a = b){}
>
>    #ifdef _MSC_VER
>       #pragma warning( pop )
>     #else
>       #pragma GCC diagnostic pop
>     #endif
> }
>
> This code wants to use a = b inside the if condition.
> The code shows how to disable the warning in GCC and MSCV.
>
> If we had in the standard a number for the warning, and a mechanism for
> disabling then we could have something like
>
> int main(void)
> {
>     int a = 1, b = 2;
>
>     if (a = b) [[disable:4706]]
>     {
>     }
> }
>
> Maybe
>
> int main(void)
> {
>     int a = 1, b = 2;
>
>     if (a = b) _ignore("I want to assign here...")
>     {
>     }
> }
>
> That is applied to any warning on that specific line.
> The advantage is the warning ID is not necessary
>
>
>
Which is a huge advantage. The first proposal creates something which is
a complete mystery to anyone who doesn't intimately know what has been
done. The second anyone can easily understand.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 08/02/2024 13:48, Thiago Adams wrote:
> Em 2/8/2024 5:17 AM, David Brown escreveu:
> ...
>> I think it would be better if compilers were stricter in their default
>> modes, even if their stricter compliant modes have to reduce the
>> severity of some warnings.  People should be allowed to write "weird"
>> code that looks very much like an error - but perhaps it is those
>> people who should need extra flags or other effort, not those that
>> write "normal" code and want to catch their bugs.  (I know this can't
>> be done for tools like gcc, because it could cause problems with
>> existing code.)
>
>
> Yes this is my point.
> But I believe we need a standard mechanism, and this is the first step
> towards safety in C.
>
> Consider this code.
>
> int main(void)
> {
>     int a = 1, b = 2;
>
>     #ifdef _MSC_VER
>       #pragma warning( push )
>       #pragma warning( disable : 4706 )
>     #else
>       #pragma GCC diagnostic push
>       #pragma GCC diagnostic ignored "-Wparentheses"
>     #endif
>
>     if (a = b){}
>
>    #ifdef _MSC_VER
>       #pragma warning( pop )
>     #else
>       #pragma GCC diagnostic pop
>     #endif
> }
>
> This code wants to use a = b inside the if condition.
> The code shows how to disable the warning in GCC and MSCV.
>
> If we had in the standard a number for the warning, and a mechanism for
> disabling then we could have something like

Standard numbers would be a /really/ bad idea - standard names would be
vastly better. There are already a couple of attributes that
standardise manipulation of warnings - [[nodiscard]] and
[[maybe_unused]]. But that syntax is not scalable. Perhaps :

[[ignored(parentheses)]]
[[warn(parentheses)]]
[[error(parentheses)]]

>
> int main(void)
> {
>     int a = 1, b = 2;
>
>     if (a = b) [[disable:4706]]
>     {
>     }
> }
>
> Maybe
>
> int main(void)
> {
>     int a = 1, b = 2;
>
>     if (a = b) _ignore("I want to assign here...")
>     {
>     }
> }
>
> That is applied to any warning on that specific line.
> The advantage is the warning ID is not necessary
>

The disadvantage then is that it affects all warnings, not the ones you
know are safe to ignore. And anything that applies to a specific line
is a non-starter for C - you would have to attach it to a statement or
other syntactic unit.

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/

David Brown <david.brown@hesbynett.no> writes:
> On 08/02/2024 05:59, Keith Thompson wrote:
>> 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.
>
> I'm not /entirely/ convinced. Such code is only undefined behaviour
> at run-time, I believe. A compiler could reject the code (give a
> fatal error) if it is sure that this will be reached when the code is
> run. But can it be sure of that, even if it is in "main()" ?
> Freestanding implementations don't need to run "main()" (not all my
> programs have had a "main()" function), and the freestanding/hosted
> implementation choice is a matter of the implementation, not just the
> compiler.

In a freestanding implementation, main() *might* be just another
function. In that case a compiler can't prove that the code will be
invoked.

I was assuming a hosted implementation -- and the compiler knows whether
its implementation is hosted or freestanding.

[...]

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

On 08/02/2024 16:04, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 08/02/2024 05:59, Keith Thompson wrote:
>>> 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.
>>
>> I'm not /entirely/ convinced. Such code is only undefined behaviour
>> at run-time, I believe. A compiler could reject the code (give a
>> fatal error) if it is sure that this will be reached when the code is
>> run. But can it be sure of that, even if it is in "main()" ?
>> Freestanding implementations don't need to run "main()" (not all my
>> programs have had a "main()" function), and the freestanding/hosted
>> implementation choice is a matter of the implementation, not just the
>> compiler.
>
> In a freestanding implementation, main() *might* be just another
> function. In that case a compiler can't prove that the code will be
> invoked.
>
Well sometimes it can. The boot routine or program entry point is by
defintion always invoked, and you can generally prove that at least some
code is always reached from that. However it is the halting problem, and
you can never prove for all cases, even if the code must be reached or
not reached regardless of runtime inputs.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Em 2/8/2024 12:25 PM, David Brown escreveu:
> On 08/02/2024 13:48, Thiago Adams wrote:
>> Em 2/8/2024 5:17 AM, David Brown escreveu:
>> ...
>>> I think it would be better if compilers were stricter in their
>>> default modes, even if their stricter compliant modes have to reduce
>>> the severity of some warnings.  People should be allowed to write
>>> "weird" code that looks very much like an error - but perhaps it is
>>> those people who should need extra flags or other effort, not those
>>> that write "normal" code and want to catch their bugs.  (I know this
>>> can't be done for tools like gcc, because it could cause problems
>>> with existing code.)
>>
>>
>> Yes this is my point.
>> But I believe we need a standard mechanism, and this is the first step
>> towards safety in C.
>>
>> Consider this code.
>>
>> int main(void)
>> {
>>      int a = 1, b = 2;
>>
>>      #ifdef _MSC_VER
>>        #pragma warning( push )
>>        #pragma warning( disable : 4706 )
>>      #else
>>        #pragma GCC diagnostic push
>>        #pragma GCC diagnostic ignored "-Wparentheses"
>>      #endif
>>
>>      if (a = b){}
>>
>>     #ifdef _MSC_VER
>>        #pragma warning( pop )
>>      #else
>>        #pragma GCC diagnostic pop
>>      #endif
>> }
>>
>> This code wants to use a = b inside the if condition.
>> The code shows how to disable the warning in GCC and MSCV.
>>
>> If we had in the standard a number for the warning, and a mechanism
>> for disabling then we could have something like
>
> Standard numbers would be a /really/ bad idea - standard names would be
> vastly better.  There are already a couple of attributes that
> standardise manipulation of warnings - [[nodiscard]] and
> [[maybe_unused]].  But that syntax is not scalable.  Perhaps :
>
>     [[ignored(parentheses)]]
>     [[warn(parentheses)]]
>     [[error(parentheses)]]
>
>
>>
>> int main(void)
>> {
>>      int a = 1, b = 2;
>>
>>      if (a = b) [[disable:4706]]
>>      {
>>      }
>> }
>>
>> Maybe
>>
>> int main(void)
>> {
>>      int a = 1, b = 2;
>>
>>      if (a = b) _ignore("I want to assign here...")
>>      {
>>      }
>> }
>>
>> That is applied to any warning on that specific line.
>> The advantage is the warning ID is not necessary
>>
>
> The disadvantage then is that it affects all warnings, not the ones you
> know are safe to ignore.  And anything that applies to a specific line
> is a non-starter for C - you would have to attach it to a statement or
> other syntactic unit.
>
>
>

I was having a look at C# specification. It uses pragma.

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives#nullable-context

Sample
#pragma warning disable 414, CS3021
#pragma warning restore CS3021

It also have warning numbers, I am not sure if other C# compilers uses
the same warnings "id".

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.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 08/02/2024 16:04, Keith Thompson wrote:
[...]
>> In a freestanding implementation, main() *might* be just another
>> function. In that case a compiler can't prove that the code will be
>> invoked.
>>
> Well sometimes it can. The boot routine or program entry point is by
> defintion always invoked, and you can generally prove that at least
> some code is always reached from that.

That's not the case in the example being discussed, which was an
unconditional division by zero in main().

> However it is the halting
> problem, and you can never prove for all cases, even if the code must
> be reached or not reached regardless of runtime inputs.

The halting problem is hardly relevant. A compiler *may* reject a
program if it can prove that undefined behavior will always occur.
It's under no obligation to do so, or even to diagnose it.

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

On 08/02/2024 12:20, Thiago Adams wrote:

> One more:
>
> struct X {double d;};
> struct Y {int i;};
> int main()
> {
>  struct X x;
>  struct Y *p;
>  p = &x;
> }
>
> GCC says:
>
> warning: incompatible pointer types assigning to 'struct Y *' from
> 'struct X *' [-Wincompatible-pointer-types]
>     7 |  p = &x;
>       |    ^ ~~
>
> For this one a C++ compiler gives:
>
> <source>:7:6: error: cannot convert 'X*' to 'Y*' in assignment
>     7 |  p = &x;
>
>
> So, this may be also related with the "spirit of C". I like the idea of
> the programmer can do whatever they want.

They can, they just have to write it like this:

p = (struct Y *)&x;

or, with a common extension:

p = (typeof(p))&x;

(or, in my language, it can be just 'p := cast(&x)'. Without a cast, it

> Consider the question
>
> "Is C language safe?"
>
> The answer  will be , well, the language itself is very vague, depends
> of the compiler you use.

And the options you provide that define the dialect of C and its strictness.

But even if compilers were strict by default, too many things in C are
unsafe, but still legal. That's due to the language design which is not
going to change.

Em 2/8/2024 2:02 PM, bart escreveu:
> On 08/02/2024 12:20, Thiago Adams wrote:
>
>> One more:
>>
>> struct X {double d;};
>> struct Y {int i;};
>> int main()
>> {
>>   struct X x;
>>   struct Y *p;
>>   p = &x;
>> }
>>
>> GCC says:
>>
>> warning: incompatible pointer types assigning to 'struct Y *' from
>> 'struct X *' [-Wincompatible-pointer-types]
>>      7 |  p = &x;
>>        |    ^ ~~
>>
>> For this one a C++ compiler gives:
>>
>> <source>:7:6: error: cannot convert 'X*' to 'Y*' in assignment
>>      7 |  p = &x;
>>
>>
>> So, this may be also related with the "spirit of C". I like the idea
>> of the programmer can do whatever they want.
>
> They can, they just have to write it like this:
>
>    p = (struct Y *)&x;
>
> or, with a common extension:
>
>    p = (typeof(p))&x;
>
> (or, in my language, it can be just 'p := cast(&x)'. Without a cast, it

Here casts are a very good solution. Another sample is when mixing enuns
types.

>> Consider the question
>>
>> "Is C language safe?"
>>
>> The answer  will be , well, the language itself is very vague, depends
>> of the compiler you use.
>
>
> And the options you provide that define the dialect of C and its
> strictness.
>
> But even if compilers were strict by default, too many things in C are
> unsafe, but still legal. That's due to the language design which is not
> going to change.
>

This depends on how strict you want to be.

Another sample

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

I wish this code would not compile if in strict mode. Because it
requires inter-procedural analysis.

But with this change:

void f(int a[3]){
a[2] = 1;
} it should compile.
Here is similar of cast, the language already have the mechanism to talk
with the static analyser.

With the progress of static analyses we need more. If we just leave the
problem for static analysers to solve then safety will not be portable.
Each one will have it own warning, annotations etc.

What is is the point of C standard?
To make the code portable? But not the code guarantees portable?

Em 2/8/2024 2:17 PM, Thiago Adams escreveu:
....
> Another sample
>
> void f(int a[]){
>   a[2] = 1;
> }
>
> I wish this code would not compile if in strict mode. Because it
> requires inter-procedural analysis.

The other reason is because the implementation may not be available.
But the interface of the function allow check at each caller.

Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> One more:
>
> struct X {double d;};
> struct Y {int i;};
> int main()
> {
> struct X x;
> struct Y *p;
> p = &x;
> }
>
> GCC says:
>
> warning: incompatible pointer types assigning to 'struct Y *' from
> 'struct X *' [-Wincompatible-pointer-types]
> 7 | p = &x;
> | ^ ~~
>
> For this one a C++ compiler gives:
>
> <source>:7:6: error: cannot convert 'X*' to 'Y*' in assignment
> 7 | p = &x;
>
>
> So, this may be also related with the "spirit of C". I like the idea
> of the programmer can do whatever they want.
> BUT, I think my default the compiler must complain.

That's simply a constraint violation; there is no implicit conversion
from struct X* to struct Y*. A conforming compiler must diagnose it
(and *may* treat it as a fatal error). (I believe the C++ rules are
equivalent. g++ just happens to be more strict than gcc in this case.)

gcc rejects it with "-pedantic-errors".

[...]

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

Em 2/8/2024 2:45 PM, Keith Thompson escreveu:
> Thiago Adams <thiago.adams@gmail.com> writes:
> [...]
>> One more:
>>
>> struct X {double d;};
>> struct Y {int i;};
>> int main()
>> {
>> struct X x;
>> struct Y *p;
>> p = &x;
>> }
>>
>> GCC says:
>>
>> warning: incompatible pointer types assigning to 'struct Y *' from
>> 'struct X *' [-Wincompatible-pointer-types]
>> 7 | p = &x;
>> | ^ ~~
>>
>> For this one a C++ compiler gives:
>>
>> <source>:7:6: error: cannot convert 'X*' to 'Y*' in assignment
>> 7 | p = &x;
>>
>>
>> So, this may be also related with the "spirit of C". I like the idea
>> of the programmer can do whatever they want.
>> BUT, I think my default the compiler must complain.
>
> That's simply a constraint violation; there is no implicit conversion
> from struct X* to struct Y*. A conforming compiler must diagnose it
> (and *may* treat it as a fatal error). (I believe the C++ rules are
> equivalent. g++ just happens to be more strict than gcc in this case.)
>
> gcc rejects it with "-pedantic-errors".

This sample shows a different mind set between C and C++ compilers.
I am suggesting a a "safe mindset" for C, that is basically a profile
for warnings.

Another one.

int * f() {
int i = 0;
return &i;
}

int main(){
int* p = f();
}

<source>:3:12: warning: function returns address of local variable
[-Wreturn-local-addr]
3 | return &i;
| ^~

The mindset is "well.. this may be an error..."
I wish a new mindset

"this code seems wrong and I will not compile this until you explicitly
annotate why you need this"

The idea that C programmers can do whatever they want still valid, but
not by default in a safer profile.

Another one

enum E1{A};
enum E2{B};
int main(){
if (A == B){}
}

<source>:4:9: warning: comparison between 'enum E1' and 'enum E2'
[-Wenum-compare]
4 | if (A == B){}

In C++ it is an warning as well.

enum E1{A};
enum E2{B};
int main(){
if (A == B){}
E1 a = B; //error in C++
}

enum E1{A};
enum E2{B};
int main(){
if (A == B){}
enum E1 a = B; //OK in C
}

(I know in C enumerators are int,
but static analysis can handle that internally)

Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> Here casts are a very good solution. Another sample is when mixing
> enuns types.

No casts are required for assignments between different enum types, or
between enums and integers. Stricter enums can be a nice feature, but C
doesn't have them. (C++ does.)

[...]

> This depends on how strict you want to be.
>
> Another sample
>
> void f(int a[]){
> a[2] = 1;
> }
>
> I wish this code would not compile if in strict mode. Because it
> requires inter-procedural analysis.

I think you mean either that you wish C allowed that sample to be
rejected or that your C compiler had the ability to reject it. In fact
it's valid C code (which *might* have undefined behavior depending on
what's passed by the caller).

> But with this change:
>
> void f(int a[3]){
> a[2] = 1;
> }
> it should compile.

Certainly. But all three of these:
void f(int a[])
void f(int a[3])
void f(int *a)

are exactly equivalent according to the C standard. (The fact that the
3 is ignored in the second example is IMHO unfortunate.)

A compiler can take notice of the [3] for the purpose of enabling or
disabling warnings, but there's no such requirement. And since
void f(int a[static 3])
can be used to assert that a points to the initial element of an array
with at least 3 elements, special handling for
void f(int a[3])
seems unlikely.

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

On 08/02/2024 17:15, Thiago Adams wrote:
> Em 2/8/2024 12:25 PM, David Brown escreveu:
>
> I was having a look at C# specification. It uses pragma.
>
> https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives#nullable-context
>
> Sample
> #pragma warning disable 414, CS3021
> #pragma warning restore CS3021
>

gcc and clang both accept #pragmas for controlling warnings. These
could be standardised as an alternative to (or in addition to) attributes.

> It also have warning numbers, I am not sure if other C# compilers uses
> the same warnings "id".
>

No. Warnings are determined by compilers. Well-designed tools use
names, and sometimes there can be compatibility (such as clang
originally copying gcc, then each copying the other for warning flag
names depending on who implements it first). Numbers are not IME at all
consistent - they are a left-over from the days when adding proper error
messages or flag names to a compiler would take too much code space. It
is amateurish that MS has yet to fix this.