zig

commit 173bc4274446a14aca2eea128b70b35b0ba18ebe (tree)
parent aa65fd5d7ca2dda5da8454e863d196745b5a50d3
Author: Alex Kladov <aleksey.kladov@gmail.com>
Date:   Sat,  7 Jun 2025 18:07:53 +0100

langref: undefined _is_ materialized in all safe modes (#24107)

* trailing whitespace

* langref: undefined _is_ materialized in all safe modes

I am also not super happy about the clause that immediately follows. I
_believe_ what we want to say here is that, simultaneously:

* undefined is guaranteed to be matrerialized in in all safe modes.
  A Zig implementation that elides `ptr.* = undefined` in ReleaseSafe
  mode would be a non-conforming implementation.
* A Zig program that relies on undefined being materialized is buggy.

But I don't think it's the time to engage this level of language-lawering!
Diffstat:
M
doc/langref.html.in
 | 
4
++--

1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/langref.html.in b/doc/langref.html.in
@@ -777,7 +777,7 @@
       value. Using this value would be a bug. The value will be unused, or overwritten before being used."
       </p>
       <p>
-      In {#link|Debug#} mode, Zig writes {#syntax#}0xaa{#endsyntax#} bytes to undefined memory. This is to catch
+      In {#link|Debug#} and {#link|ReleaseSafe#} mode, Zig writes {#syntax#}0xaa{#endsyntax#} bytes to undefined memory. This is to catch
       bugs early, and to help detect use of undefined memory in a debugger. However, this behavior is only an
       implementation feature, not a language semantic, so it is not guaranteed to be observable to code.
       </p>
@@ -2295,7 +2295,7 @@ or
       {#code|test_aligned_struct_fields.zig#}
 
       <p>
-      Equating packed structs results in a comparison of the backing integer, 
+      Equating packed structs results in a comparison of the backing integer,
       and only works for the {#syntax#}=={#endsyntax#} and {#syntax#}!={#endsyntax#} {#link|Operators#}.
       </p>
       {#code|test_packed_struct_equality.zig#}