Various typo changes, fixes, more links for sources, etc.

Author: tomice

_posts/2025-04-27-undefined-behavior-vs-expected-behavior.md

@@ -41,10 +41,10 @@ ranges from ignoring the situation completely with unpredictable results, to
 behavior 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).
+issuance of a diagnostic message)."
 
 For some, those lines might be a bit hard to follow, but the
-[C FAQ](https://c-faq.com/ansi/undef.html) nicely:
+[C FAQ](https://c-faq.com/ansi/undef.html) sums it up nicely:
 
 > Anything at all can happen; the Standard imposes no requirements.
 > The program may fail to compile, or it may execute incorrectly (either
@@ -77,7 +77,7 @@ an example stating, "EXAMPLE An example of unspecified behavior is the order in
 which the arguments to a function are evaluated."
 
 Summed up, the compiler team is free to do whatever they want in certain
-scenarios when they face undefined behavior, and they never need to report it
+scenarios when they face unspecified behavior, and they never need to report it
 or document it in any way.
 
 There are two more defined behaviors in the spec worth touching on briefly:
@@ -178,7 +178,8 @@ int main(void) {
 This allows you to work with the color data at both the bit level and as
 floating-point values without having to copy or cast the data. Cool, right?
 As described earlier, this has caveats. Let's take a look at what the C99 and
-C11 ISO specifications say about this.
+[C11 ISO](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf)
+specifications say about this.
 
 ### The C99 and C11 Standard Definition
 
@@ -219,7 +220,7 @@ undefined behavior when accessed.
 
 This change is important because it guarantees that type punning itself is not
 undefined behavior according to the actual specification. However, there is a
-subtle edge case not mentioned, and that is that reading an invalid object
+subtle edge case not mentioned, one being that reading an invalid object
 representation resulting from the punning could still cause undefined behavior.
 
 To handle this, devs relied on `{0}` to zero the entire union. This was
@@ -231,7 +232,9 @@ valid memory state.
 ### The C++11 Standard Definition
 
 For completion's sake, let's take a look at what C++ states regarding unions.
-We'll take a look at the C++14 ISO draft spec, specifically:
+We'll take a look at the
+[C++14 ISO draft spec](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf),
+specifically:
 
 > In a union, at most one of the non-static data members can be active at any
 > time, that is, the value of at most one of the non-static data members can be
@@ -280,12 +283,13 @@ set of rules applies to the other. They are different specs, after all.
 
 ## Compiler Wars
 
-The two main compilers we tend to use these days in C are GNU GCC and Clang.
-The latest news of GNU GCC 15.1 changing the behavior of zero'ing a union had
-me check into what Clang is doing, and the most interesting this is that they
-almost swapped their own unspecified behaviors.
+The two main compilers we tend to use these days in C are GNU GCC and
+[Clang](https://clang.llvm.org/). The latest news of GNU GCC 15.1 changing the
+behavior of zero'ing a union had me check into what Clang is doing, and the
+most interesting this is that they almost swapped their own unspecified
+behaviors.
 
-### GCC (old) - Initialize Entire Union
+### Creating an Example
 
 We'll start with the first base-case of GNU GCC and its historic behavior of
 zero'ing a union. We'll use this example code:
@@ -319,10 +323,14 @@ int main(void) {
 }
 ```
 
+Now let's run this into [godbolt](https://godbolt.org/) and see what happens!
+
+### GCC (old) - Initialize Entire Union
+
 The following is the resulting x86-64 assembly from GCC 11.1. We will focus
 on the `init_f` assembly that is generated:
 
-```asm
+```bash
 init_f:
         push    rbp
         mov     rbp, rsp
@@ -340,7 +348,7 @@ is the expected behavior devs have come to know.
 
 In memory, it would look something like this:
 
-```ascii
+```bash
 Memory:
 [00][00][00][00][00][00][00][00]
 ^^^^^^^^ first 4 bytes = float f
@@ -356,7 +364,7 @@ Result:
 
 Now, let's take a look at how GCC 15.1 handles it with the new change:
 
-```asm
+```bash
 init_f:
         push    rbp
         mov     rbp, rsp
@@ -371,7 +379,7 @@ init_f:
 
 Here, we see the following:
 
-```asm
+```bash
 pxor xmm0, xmm0
 movss DWORD PTR [rax], xmm0
 ```
@@ -381,7 +389,7 @@ the full 8 bytes like we were back with GCC 11.1.
 
 In memory, it would look something like this:
 
-```ascii
+```bash
 Memory:
 [00][00][00][00][??][??][??][??]
 ^^^^^^^^ first 4 bytes = float f
@@ -399,7 +407,7 @@ is doing...
 
 Same code, same model. We'll take a look at Clang 6.0.0 first:
 
-```asm
+```bash
 init_f:
         push    rbp
         mov     rbp, rsp
@@ -416,7 +424,7 @@ init_d:
 
 So this is interesting. The real key points are here:
 
-```asm
+```bash
 xorps   xmm0, xmm0     # zero xmm0
 movss   [rbp-16], xmm0 # write 4 bytes (float)
 mov     rax, [rbp-16]
@@ -433,7 +441,7 @@ see what the very latest version of Clang does.
 
 This is from Clang 20.1.0:
 
-```asm
+```bash
 init_f:
         push    rbp
         mov     rbp, rsp
@@ -458,7 +466,7 @@ init_f:
 
 This is doing a lot more under the hood than before. The key point is here:
 
-```asm
+```bash
 xorps   xmm0, xmm0     # zero xmm0
 movss   [rbp-16], xmm0 # write 4 bytes (float)
 
@@ -484,10 +492,10 @@ For anyone who wants to verify this, I created some godbolt links.
 
 ## Where GCC Breaks Historical Behavior
 
-So here is where we get to the crux of the issue. For over a decade, C devs
-have expected `{0}` to fully clear unions. Type punning is allowed in the newer
-C standards, and compilers have gone to great lengths to try to maintain memory
-safety by adhering to expected behavior, even if it is undefined or
+So here is where we get to the main point of the issue. For over a decade, C
+devs have expected `{0}` to fully clear unions. Type punning is allowed in the
+newer C standards, and compilers have gone to great lengths to try to maintain
+memory safety by adhering to expected behavior, even if it is undefined or
 unspecified.
 
 The latest change in GCC's handling of this breaks what I consider to be
@@ -506,10 +514,14 @@ code that "worked fine" and are porting it to purpose-built embedded
 Yocto-based distros will be the ones to start finding all these fun bugs.
 
 I completely understand why the GNU GCC team is allowed to do this given how
-the spec reads. There's also no such thing as truly historical behavior in the
-spec. However, there are certain things programmers rely on to be valid, even
-if they aren't well-defined. This is one of those cases where I think the
-compiler team might want to re-evaluate their decision.
+the spec reads. Many GCC devs claim that
+[type punning via unions is undefined](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141#c13).
+There's also no such thing as truly historical behavior in the spec. However,
+there are certain things programmers rely on to be valid, even if they aren't
+well-defined. This is one of those cases where I think the compiler team might
+want to re-evaluate their decision, or at the very least present a solid
+argument as to why they are breaking away from a historical behavior that many
+of us have come to rely on, even if it was considered UB.
 
 ## Further Reading