Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

92%

+21 −0

Q&A What must a C compiler do when it finds an error?

The C standard does not speak of "errors" and "warnings", those are not formal terms. The compiler is only required to produce a diagnostic message, as specified in C11 5.1.1.3: Diagnostics A c...

posted 4y ago by Lundin‭ · edited 3y ago by hkotsubo‭

Answer

#6: Post edited by

hkotsubo‭ · 2021-09-27T14:25:58Z (over 3 years ago)
Linking to relevant (and related) question

Copy Link

Raw

Markdown

The C standard does not speak of "errors" and "warnings", those are not formal terms. The compiler is only required to produce a _diagnostic message_, as specified in C11 5.1.1.3:
> **Diagnostics**
> A conforming implementation shall produce at least one diagnostic message (identified in
an implementation-defined manner) if a preprocessing translation unit or translation unit
contains a violation of any syntax rule or constraint, even if the behavior is also explicitly
specified as undefined or implementation-defined. Diagnostic messages need not be
produced in other circumstances.
The nature of this diagnostic message could be anything: a compiler error, warning, log entry, blinking lights, blowing whistles or a hand-written letter delivered to the programmer's doorstep. As long as the compiler informs the programmer about the problem, it is compliant.
And the opposite: if the compiler does not inform the programmer about syntax or constraint violations, the compiler is non-conforming to the C language standard.
For this reason, you can't prove that your program is correct because "I only got a warning message". A warning message is sufficient for reporting that your program isn't valid C.
The informal term "compiles cleanly" typically refers to a compiled program that did not get any diagnostic messages reported, including warnings.
Popular compilers such as gcc, clang and icc can be configured to always produce errors instead of warnings, in case of syntax or constraint violations, by using `-std=c11 -pedantic-errors` which forces these compilers into a strict mode. I strongly recommend beginners learning the language to compile with these settings.
---
Notably, there is no requirement to produce a diagnostic message in case of undefined behavior or potential run-time bugs. For example the compiler need not inform about
int a[2];
a[10]=0;
even though it is an obvious bug that can be detected by static analysis in compile-time. Array out of bounds access does not violate a constraint and the syntax is ok, even though this code is explicitly invoking undefined behavior.
For this reason, you can't prove that something is not undefined behavior with "it compiles cleanly".
---
There is no requirement about what the compiler should do with its output files in case of syntax errors or constraint violations. It isn't specified if the compiler should refuse to generate an object file/binary executable, or if it may do so regardless. In case it does produce such output, despite the C program being non-conforming, there are no guarantees of how that executable will behave. It is no longer valid C, but a non-standard extension of the language.
For this reason, you can't prove that your program is correct because "it runs". It could still contain C language violations as well as undefined behavior.

The C standard does not speak of "errors" and "warnings", those are not formal terms. The compiler is only required to produce a _diagnostic message_, as specified in C11 5.1.1.3:
> **Diagnostics**
> A conforming implementation shall produce at least one diagnostic message (identified in
an implementation-defined manner) if a preprocessing translation unit or translation unit
contains a violation of any syntax rule or constraint, even if the behavior is also explicitly
specified as undefined or implementation-defined. Diagnostic messages need not be
produced in other circumstances.
The nature of this diagnostic message could be anything: a compiler error, warning, log entry, blinking lights, blowing whistles or a hand-written letter delivered to the programmer's doorstep. As long as the compiler informs the programmer about the problem, it is compliant.
And the opposite: if the compiler does not inform the programmer about syntax or constraint violations, the compiler is non-conforming to the C language standard.
For this reason, you can't prove that your program is correct because "I only got a warning message". A warning message is sufficient for reporting that your program isn't valid C.
The informal term "compiles cleanly" typically refers to a compiled program that did not get any diagnostic messages reported, including warnings.
Popular compilers such as gcc, clang and icc can be configured to always produce errors instead of warnings, in case of syntax or constraint violations, by using `-std=c11 -pedantic-errors` which forces these compilers into a strict mode. [I strongly recommend beginners learning the language to compile with these settings](https://software.codidact.com/posts/282565).
---
Notably, there is no requirement to produce a diagnostic message in case of undefined behavior or potential run-time bugs. For example the compiler need not inform about
int a[2];
a[10]=0;
even though it is an obvious bug that can be detected by static analysis in compile-time. Array out of bounds access does not violate a constraint and the syntax is ok, even though this code is explicitly invoking undefined behavior.
For this reason, you can't prove that something is not undefined behavior with "it compiles cleanly".
---
There is no requirement about what the compiler should do with its output files in case of syntax errors or constraint violations. It isn't specified if the compiler should refuse to generate an object file/binary executable, or if it may do so regardless. In case it does produce such output, despite the C program being non-conforming, there are no guarantees of how that executable will behave. It is no longer valid C, but a non-standard extension of the language.
For this reason, you can't prove that your program is correct because "it runs". It could still contain C language violations as well as undefined behavior.

#5: Post edited by

Lundin‭ · 2020-10-07T12:53:05Z (about 4 years ago)
Code formatting

Copy Link

Raw

Markdown

The C standard does not speak of "errors" and "warnings", those are not formal terms. The compiler is only required to produce a _diagnostic message_, as specified in C11 5.1.1.3:
> **Diagnostics**
> A conforming implementation shall produce at least one diagnostic message (identified in
an implementation-defined manner) if a preprocessing translation unit or translation unit
contains a violation of any syntax rule or constraint, even if the behavior is also explicitly
specified as undefined or implementation-defined. Diagnostic messages need not be
produced in other circumstances.
The nature of this diagnostic message could be anything: a compiler error, warning, log entry, blinking lights, blowing whistles or a hand-written letter delivered to the programmer's doorstep. As long as the compiler informs the programmer about the problem, it is compliant.
And the opposite: if the compiler does not inform the programmer about syntax or constraint violations, the compiler is non-conforming to the C language standard.
For this reason, you can't prove that your program is correct because "I only got a warning message". A warning message is sufficient for reporting that your program isn't valid C.
The informal term "compiles cleanly" typically refers to a compiled program that did not get any diagnostic messages reported, including warnings.
Popular compilers such as gcc, clang and icc can be configured to always produce errors instead of warnings, in case of syntax or constraint violations, by using `-std=c11 -pedantic-errors` which forces these compilers into a strict mode. I strongly recommend beginners learning the language to compile with these settings.
---
Notably, there is no requirement to produce a diagnostic message in case of undefined behavior or potential run-time bugs. For example the compiler need not inform about `int a[2]; a[10]=0;` even though it is an obvious bug that can be detected by static analysis in compile-time. Array out of bounds access does not violate a constraint and the syntax is ok, even though this code is explicitly invoking undefined behavior.
For this reason, you can't prove that something is not undefined behavior with "it compiles cleanly".
---
There is no requirement about what the compiler should do with its output files in case of syntax errors or constraint violations. It isn't specified if the compiler should refuse to generate an object file/binary executable, or if it may do so regardless. In case it does produce such output, despite the C program being non-conforming, there are no guarantees of how that executable will behave. It is no longer valid C, but a non-standard extension of the language.
For this reason, you can't prove that your program is correct because "it runs". It could still contain C language violations as well as undefined behavior.

The C standard does not speak of "errors" and "warnings", those are not formal terms. The compiler is only required to produce a _diagnostic message_, as specified in C11 5.1.1.3:
> **Diagnostics**
> A conforming implementation shall produce at least one diagnostic message (identified in
an implementation-defined manner) if a preprocessing translation unit or translation unit
contains a violation of any syntax rule or constraint, even if the behavior is also explicitly
specified as undefined or implementation-defined. Diagnostic messages need not be
produced in other circumstances.
The nature of this diagnostic message could be anything: a compiler error, warning, log entry, blinking lights, blowing whistles or a hand-written letter delivered to the programmer's doorstep. As long as the compiler informs the programmer about the problem, it is compliant.
And the opposite: if the compiler does not inform the programmer about syntax or constraint violations, the compiler is non-conforming to the C language standard.
For this reason, you can't prove that your program is correct because "I only got a warning message". A warning message is sufficient for reporting that your program isn't valid C.
The informal term "compiles cleanly" typically refers to a compiled program that did not get any diagnostic messages reported, including warnings.
Popular compilers such as gcc, clang and icc can be configured to always produce errors instead of warnings, in case of syntax or constraint violations, by using `-std=c11 -pedantic-errors` which forces these compilers into a strict mode. I strongly recommend beginners learning the language to compile with these settings.
---
Notably, there is no requirement to produce a diagnostic message in case of undefined behavior or potential run-time bugs. For example the compiler need not inform about
int a[2];
a[10]=0;
even though it is an obvious bug that can be detected by static analysis in compile-time. Array out of bounds access does not violate a constraint and the syntax is ok, even though this code is explicitly invoking undefined behavior.
For this reason, you can't prove that something is not undefined behavior with "it compiles cleanly".
---
There is no requirement about what the compiler should do with its output files in case of syntax errors or constraint violations. It isn't specified if the compiler should refuse to generate an object file/binary executable, or if it may do so regardless. In case it does produce such output, despite the C program being non-conforming, there are no guarantees of how that executable will behave. It is no longer valid C, but a non-standard extension of the language.
For this reason, you can't prove that your program is correct because "it runs". It could still contain C language violations as well as undefined behavior.

#4: Post edited by

Lundin‭ · 2020-08-19T06:24:07Z (over 4 years ago)

Copy Link

Raw

Markdown

The C standard does not speak of "errors" and "warnings", those are not formal terms. The compiler is only required to produce a _diagnostic message_, as specified in C11 5.1.1.3:
> **Diagnostics**
> A conforming implementation shall produce at least one diagnostic message (identified in
an implementation-defined manner) if a preprocessing translation unit or translation unit
contains a violation of any syntax rule or constraint, even if the behavior is also explicitly
specified as undefined or implementation-defined. Diagnostic messages need not be
produced in other circumstances.
The nature of this diagnostic message could be anything: a compiler error, warning, log entry, blinking lights, blowing whistles or a hand-written letter delivered to the programmer's doorstep. As long as the compiler informs the programmer about the problem, it is compliant.
And the opposite: if the compiler does not inform the programmer about syntax or constraint violations, the compiler is non-conforming to the C language standard.
For this reason, you can't prove that your program is correct because "I only got a warning message". A warning message is sufficient for reporting that your program isn't valid C.
The informal term "compiles cleanly" typically refers to a compiled program that did not get any diagnostic messages reported, including warnings.
Popular compilers such as gcc, clang and icc can be configured to always produce errors instead of warnings, in case of syntax or constraint violations, by using `-std=c11 -pedantic-errors` which forces these compilers into a strict mode. I strongly recommend beginners learning the language to compile with these settings.
---
Notably, there is no requirement to produce a diagnostic message in case of undefined behavior or potential run-time bugs. For example the compiler need not inform about `int a[2]; a[10]=0;` even though it is an obvious bug that can be detected by static analysis in compile-time. Array out of bounds access does not violate a constraint and the syntax is ok, even though this code is explicitly invoking undefined behavior.
For this reason, you can't prove that something is not undefined behavior with "it compiles cleanly".
---
There is no requirement about what the compiler should do with its output files in case of syntax errors or constraint violations. It isn't specified if the compiler should refuse to generate an object file/binary executable, or if it may do so regardless. In case it does produce such output, despite the C program being non-conforming, there are no guarantees of how that executable will behave. It is no longer valid C, but a non-standard extension of the language.
~~For this reason, you can't prove that your program is correct because "it runs". It could contain undefined behavior still.~~

The C standard does not speak of "errors" and "warnings", those are not formal terms. The compiler is only required to produce a _diagnostic message_, as specified in C11 5.1.1.3:
> **Diagnostics**
> A conforming implementation shall produce at least one diagnostic message (identified in
an implementation-defined manner) if a preprocessing translation unit or translation unit
contains a violation of any syntax rule or constraint, even if the behavior is also explicitly
specified as undefined or implementation-defined. Diagnostic messages need not be
produced in other circumstances.
The nature of this diagnostic message could be anything: a compiler error, warning, log entry, blinking lights, blowing whistles or a hand-written letter delivered to the programmer's doorstep. As long as the compiler informs the programmer about the problem, it is compliant.
And the opposite: if the compiler does not inform the programmer about syntax or constraint violations, the compiler is non-conforming to the C language standard.
For this reason, you can't prove that your program is correct because "I only got a warning message". A warning message is sufficient for reporting that your program isn't valid C.
The informal term "compiles cleanly" typically refers to a compiled program that did not get any diagnostic messages reported, including warnings.
Popular compilers such as gcc, clang and icc can be configured to always produce errors instead of warnings, in case of syntax or constraint violations, by using `-std=c11 -pedantic-errors` which forces these compilers into a strict mode. I strongly recommend beginners learning the language to compile with these settings.
---
Notably, there is no requirement to produce a diagnostic message in case of undefined behavior or potential run-time bugs. For example the compiler need not inform about `int a[2]; a[10]=0;` even though it is an obvious bug that can be detected by static analysis in compile-time. Array out of bounds access does not violate a constraint and the syntax is ok, even though this code is explicitly invoking undefined behavior.
For this reason, you can't prove that something is not undefined behavior with "it compiles cleanly".
---
There is no requirement about what the compiler should do with its output files in case of syntax errors or constraint violations. It isn't specified if the compiler should refuse to generate an object file/binary executable, or if it may do so regardless. In case it does produce such output, despite the C program being non-conforming, there are no guarantees of how that executable will behave. It is no longer valid C, but a non-standard extension of the language.
For this reason, you can't prove that your program is correct because "it runs". It could still contain C language violations as well as undefined behavior.

#3: Post edited by

Lundin‭ · 2020-08-18T11:55:50Z (over 4 years ago)

Copy Link

Raw

Markdown

The C standard does not speak of "errors" and "warnings", those are not formal terms. The compiler is only required to produce a _diagnostic message_, as specified in C11 5.1.1.3:
> **Diagnostics**
> A conforming implementation shall produce at least one diagnostic message (identified in
an implementation-defined manner) if a preprocessing translation unit or translation unit
contains a violation of any syntax rule or constraint, even if the behavior is also explicitly
specified as undefined or implementation-defined. Diagnostic messages need not be
produced in other circumstances.
The nature of this diagnostic message could be anything: a compiler error, warning, log entry, blinking lights, blowing whistles or a hand-written letter delivered to the programmer's doorstep. As long as the compiler informs the programmer about the problem, it is compliant.
And the opposite: if the compiler does not inform the programmer about syntax or constraint violations, the compiler is non-conforming to the C language standard.
~~For this reason, you can't prove that your program is correct because "I only got a warning message". A warning message is sufficient for reporting that your program isn't valid C.~~
Popular compilers such as gcc, clang and icc can be configured to always produce errors instead of warnings, in case of syntax or constraint violations, by using `-std=c11 -pedantic-errors` which forces these compilers into a strict mode. I strongly recommend beginners learning the language to compile with these settings.
---
Notably, there is no requirement to produce a diagnostic message in case of undefined behavior or potential run-time bugs. For example the compiler need not inform about `int a[2]; a[10]=0;` even though it is an obvious bug that can be detected by static analysis in compile-time. Array out of bounds access does not violate a constraint and the syntax is ok, even though this code is explicitly invoking undefined behavior.
For this reason, you can't prove that something is not undefined behavior with "it compiles cleanly".
---
There is no requirement about what the compiler should do with its output files in case of syntax errors or constraint violations. It isn't specified if the compiler should refuse to generate an object file/binary executable, or if it may do so regardless. In case it does produce such output, despite the C program being non-conforming, there are no guarantees of how that executable will behave. It is no longer valid C, but a non-standard extension of the language.
For this reason, you can't prove that your program is correct because "it runs". It could contain undefined behavior still.

The C standard does not speak of "errors" and "warnings", those are not formal terms. The compiler is only required to produce a _diagnostic message_, as specified in C11 5.1.1.3:
> **Diagnostics**
> A conforming implementation shall produce at least one diagnostic message (identified in
an implementation-defined manner) if a preprocessing translation unit or translation unit
contains a violation of any syntax rule or constraint, even if the behavior is also explicitly
specified as undefined or implementation-defined. Diagnostic messages need not be
produced in other circumstances.
The nature of this diagnostic message could be anything: a compiler error, warning, log entry, blinking lights, blowing whistles or a hand-written letter delivered to the programmer's doorstep. As long as the compiler informs the programmer about the problem, it is compliant.
And the opposite: if the compiler does not inform the programmer about syntax or constraint violations, the compiler is non-conforming to the C language standard.
For this reason, you can't prove that your program is correct because "I only got a warning message". A warning message is sufficient for reporting that your program isn't valid C.
The informal term "compiles cleanly" typically refers to a compiled program that did not get any diagnostic messages reported, including warnings.
Popular compilers such as gcc, clang and icc can be configured to always produce errors instead of warnings, in case of syntax or constraint violations, by using `-std=c11 -pedantic-errors` which forces these compilers into a strict mode. I strongly recommend beginners learning the language to compile with these settings.
---
Notably, there is no requirement to produce a diagnostic message in case of undefined behavior or potential run-time bugs. For example the compiler need not inform about `int a[2]; a[10]=0;` even though it is an obvious bug that can be detected by static analysis in compile-time. Array out of bounds access does not violate a constraint and the syntax is ok, even though this code is explicitly invoking undefined behavior.
For this reason, you can't prove that something is not undefined behavior with "it compiles cleanly".
---
There is no requirement about what the compiler should do with its output files in case of syntax errors or constraint violations. It isn't specified if the compiler should refuse to generate an object file/binary executable, or if it may do so regardless. In case it does produce such output, despite the C program being non-conforming, there are no guarantees of how that executable will behave. It is no longer valid C, but a non-standard extension of the language.
For this reason, you can't prove that your program is correct because "it runs". It could contain undefined behavior still.

#2: Post edited by

Lundin‭ · 2020-08-18T11:54:33Z (over 4 years ago)

Copy Link

Raw

Markdown

The C standard does not speak of "errors" and "warnings", those are not formal terms. The compiler is only required to produce a _diagnostic message_, as specified in C11 5.1.1.3:
> **Diagnostics**
> A conforming implementation shall produce at least one diagnostic message (identified in
an implementation-defined manner) if a preprocessing translation unit or translation unit
contains a violation of any syntax rule or constraint, even if the behavior is also explicitly
specified as undefined or implementation-defined. Diagnostic messages need not be
produced in other circumstances.
The nature of this diagnostic message could be anything: a compiler error, warning, log entry, blinking lights, blowing whistles or a hand-written letter delivered to the programmer's doorstep. As long as the compiler informs the programmer about the problem, it is compliant.
And the opposite: if the compiler does not inform the programmer about syntax or constraint violations, the compiler is non-conforming to the C language standard.
For this reason, you can't prove that your program is correct because "I only got a warning message". A warning message is sufficient for reporting that your program isn't valid C.
Popular compilers such as gcc, clang and icc can be configured to always produce errors instead of warnings, in case of syntax or constraint violations, by using `-std=c11 -pedantic-errors` which forces these compilers into a strict mode. I strongly recommend beginners learning the language to compile with these settings.
---
Notably, there is no requirement to produce a diagnostic message in case of undefined behavior or potential run-time bugs. For example the compiler need not inform about `int a[2]; a[10]=0;` even though it is an obvious bug that can be detected by static analysis in compile-time. Array out of bounds access does not violate a constraint and the syntax is ok, even though this code is explicitly invoking undefined behavior.
~~For this reason, you can't prove undefined behavior with "it compiles cleanly".~~
---
There is no requirement about what the compiler should do with its output files in case of syntax errors or constraint violations. It isn't specified if the compiler should refuse to generate an object file/binary executable, or if it may do so regardless. In case it does produce such output, despite the C program being non-conforming, there are no guarantees of how that executable will behave. It is no longer valid C, but a non-standard extension of the language.
For this reason, you can't prove that your program is correct because "it runs". It could contain undefined behavior still.

The C standard does not speak of "errors" and "warnings", those are not formal terms. The compiler is only required to produce a _diagnostic message_, as specified in C11 5.1.1.3:
> **Diagnostics**
> A conforming implementation shall produce at least one diagnostic message (identified in
an implementation-defined manner) if a preprocessing translation unit or translation unit
contains a violation of any syntax rule or constraint, even if the behavior is also explicitly
specified as undefined or implementation-defined. Diagnostic messages need not be
produced in other circumstances.
The nature of this diagnostic message could be anything: a compiler error, warning, log entry, blinking lights, blowing whistles or a hand-written letter delivered to the programmer's doorstep. As long as the compiler informs the programmer about the problem, it is compliant.
And the opposite: if the compiler does not inform the programmer about syntax or constraint violations, the compiler is non-conforming to the C language standard.
For this reason, you can't prove that your program is correct because "I only got a warning message". A warning message is sufficient for reporting that your program isn't valid C.
Popular compilers such as gcc, clang and icc can be configured to always produce errors instead of warnings, in case of syntax or constraint violations, by using `-std=c11 -pedantic-errors` which forces these compilers into a strict mode. I strongly recommend beginners learning the language to compile with these settings.
---
Notably, there is no requirement to produce a diagnostic message in case of undefined behavior or potential run-time bugs. For example the compiler need not inform about `int a[2]; a[10]=0;` even though it is an obvious bug that can be detected by static analysis in compile-time. Array out of bounds access does not violate a constraint and the syntax is ok, even though this code is explicitly invoking undefined behavior.
For this reason, you can't prove that something is not undefined behavior with "it compiles cleanly".
---
There is no requirement about what the compiler should do with its output files in case of syntax errors or constraint violations. It isn't specified if the compiler should refuse to generate an object file/binary executable, or if it may do so regardless. In case it does produce such output, despite the C program being non-conforming, there are no guarantees of how that executable will behave. It is no longer valid C, but a non-standard extension of the language.
For this reason, you can't prove that your program is correct because "it runs". It could contain undefined behavior still.

#1: Initial revision by

Lundin‭ · 2020-08-18T11:52:59Z (over 4 years ago)

Copy Link

Raw

Markdown

The C standard does not speak of "errors" and "warnings", those are not formal terms. The compiler is only required to produce a _diagnostic message_, as specified in C11 5.1.1.3:

> **Diagnostics**
> A conforming implementation shall produce at least one diagnostic message (identified in
an implementation-defined manner) if a preprocessing translation unit or translation unit
contains a violation of any syntax rule or constraint, even if the behavior is also explicitly
specified as undefined or implementation-defined. Diagnostic messages need not be
produced in other circumstances.

The nature of this diagnostic message could be anything: a compiler error, warning, log entry, blinking lights, blowing whistles or a hand-written letter delivered to the programmer's doorstep. As long as the compiler informs the programmer about the problem, it is compliant.

And the opposite: if the compiler does not inform the programmer about syntax or constraint violations, the compiler is non-conforming to the C language standard.

For this reason, you can't prove that your program is correct because "I only got a warning message". A warning message is sufficient for reporting that your program isn't valid C.

Popular compilers such as gcc, clang and icc can be configured to always produce errors instead of warnings, in case of syntax or constraint violations, by using `-std=c11 -pedantic-errors` which forces these compilers into a strict mode. I strongly recommend beginners learning the language to compile with these settings.

---

Notably, there is no requirement to produce a diagnostic message in case of undefined behavior or potential run-time bugs. For example the compiler need not inform about `int a[2]; a[10]=0;` even though it is an obvious bug that can be detected by static analysis in compile-time. Array out of bounds access does not violate a constraint and the syntax is ok, even though this code is explicitly invoking undefined behavior.

For this reason, you can't prove undefined behavior with "it compiles cleanly".

---

There is no requirement about what the compiler should do with its output files in case of syntax errors or constraint violations. It isn't specified if the compiler should refuse to generate an object file/binary executable, or if it may do so regardless. In case it does produce such output, despite the C program being non-conforming, there are no guarantees of how that executable will behave. It is no longer valid C, but a non-standard extension of the language.

For this reason, you can't prove that your program is correct because "it runs". It could contain undefined behavior still.

Communities

Post History