Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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 3y ago by Lundin‭  ·  edited 2y ago by hkotsubo‭

Answer
#6: Post edited by user avatar hkotsubo‭ · 2021-09-27T14:25:58Z (over 2 years ago)
Linking to relevant (and related) question
  • 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 user avatar Lundin‭ · 2020-10-07T12:53:05Z (over 3 years ago)
Code formatting
  • 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 user avatar Lundin‭ · 2020-08-19T06:24:07Z (over 3 years ago)
  • 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 user avatar Lundin‭ · 2020-08-18T11:55:50Z (over 3 years ago)
  • 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 user avatar Lundin‭ · 2020-08-18T11:54:33Z (over 3 years ago)
  • 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 user avatar Lundin‭ · 2020-08-18T11:52:59Z (over 3 years ago)
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.