Deploying to gh-pages from @ 6a2a8c1 🚀

Author: matu3ba

articles/shennanigans_in_c/index.html

@@ -16,7 +16,7 @@ <h1><span class="reset_a"><a href="/">Jans Website</a></span></h1>
             <h2>Some C++ footgun avoidance.</h2>
           </div>
           <div class='static_double_column3'>
-            <div><div id=intro><p> Here is a list of footguns taken from my notes I found worthwhile to write up to remind myself not to do the same mistake again or how to workaround various compiler problems. It consists of type problems, easy to make memory issues mostly around uninitialized memory and stack-local values, low quality library code, problems with virtual classes, template code problems and some compiler specific problems. For a more complete view on the edge cases of the language, consider taking a look at the <a href="https://github.com/fouronnes/cppiceberg" target="_blank">C++ iceberg</a> and <a href="https://github.com/JadLevesque/PPMP-Iceberg" target="_blank">preprocessor iceberg</a>.</p></div><div id=cpp_review><p> Update 20241217: Since the writing of this article (20240618), I did significantly extend my CI-tested sample code on C++14, C++17, C++20 and C++23 and do not plan to continue to list footguns. My main complains about C++ are</p><ol><li>Concepts are not testable and there are no understandable backtraces for why concepts are not satisfied, which often makes them worse than templates.</li><li>Simple things like renaming <code>std::vector&lt;bool&gt;</code> are not getting fixed.</li><li>Many language features are unnecessary complex (function overloading, multiple constructors) instead of being usable via tagged union (<code>std::variant</code>).</li><li>Individual declarative/functional parts can not be used by kernels via build system to speed up compilation.</li><li>Compile time function execution is less powerful, but still offers no logical completeness or correctness advantage.</li><li>Object oriented programming and virtual tables are not optional. There is no reason why string functions would require <code>std::string</code> or <code>std::string_view</code> instead of working on user-provided information, for example provided via <code>struct</code> with a fat pointer (pointer and length).</li></ol><p>The current trajectory of C++ indicates to me that none of this will be fixed, even though modules would soon allow C++ version 2. Personally I would prefer semantics more comparable to Zig, but so far Zig has no static analysis to reduce transition efforts from C++.</p></div><div id=footguns><ul><li>Do not use <code>hashmap[key]</code>, use <code>auto search_hashmap = hashmap.find();</code> and write via iterator or use emplace, because there is no check for the elements existence or (typically raw C) values of members can remain undefined after object creation due to implicit default constructor. <figure><pre><code class="cpp"><span class="keyword">#include</span> <span class="string">&lt;map&gt;</span>
+            <div><div id=intro><p> Here is a list of footguns taken from my notes I found worthwhile to write up to remind myself not to do the same mistake again or how to workaround various compiler problems. It consists of type problems, easy to make memory issues mostly around uninitialized memory and stack-local values, low quality library code, problems with virtual classes, template code problems and some compiler specific problems. For a more complete view on the edge cases of the language, consider taking a look at the <a href="https://github.com/fouronnes/cppiceberg" target="_blank">C++ iceberg</a> and <a href="https://github.com/JadLevesque/PPMP-Iceberg" target="_blank">preprocessor iceberg</a>.</p></div><div id=cpp_review><p> Update 2024-12-17: Since the writing of this article (2024-04-15), I did significantly extend my CI-tested sample code on C++14, C++17, C++20 and C++23 and do not plan to continue to list footguns. My main complains about C++ are</p><ol><li>Concepts are not testable and there are no understandable backtraces for why concepts are not satisfied, which often makes them worse than templates.</li><li>Simple things like renaming <code>std::vector&lt;bool&gt;</code> are not getting fixed.</li><li>Many language features are unnecessary complex (function overloading, multiple constructors) instead of being usable via tagged union (<code>std::variant</code>).</li><li>Individual declarative/functional parts can not be used by kernels via build system to speed up compilation.</li><li>Compile time function execution is less powerful, but still offers no logical completeness or correctness advantage.</li><li>Object oriented programming and virtual tables are not optional. There is no reason why string functions would require <code>std::string</code> or <code>std::string_view</code> instead of working on user-provided information, for example provided via <code>struct</code> with a fat pointer (pointer and length).</li></ol><p>The current trajectory of C++ indicates to me that none of this will be fixed, even though modules would soon allow C++ version 2. Personally I would prefer semantics more comparable to Zig, but so far Zig has no static analysis to reduce transition efforts from C++.</p></div><div id=footguns><ul><li>Do not use <code>hashmap[key]</code>, use <code>auto search_hashmap = hashmap.find();</code> and write via iterator or use emplace, because there is no check for the elements existence or (typically raw C) values of members can remain undefined after object creation due to implicit default constructor. <figure><pre><code class="cpp"><span class="keyword">#include</span> <span class="string">&lt;map&gt;</span>
 <span class="keyword">#include</span> <span class="string">&lt;string&gt;</span>
 <span class="keyword">class</span> <span class="type">T1</span> {
 <span class="keyword">public</span>:

articles/shennanigans_in_cpp/index.html

@@ -16,7 +16,7 @@ <h1><span class="reset_a"><a href="/">Jans Website</a></span></h1>
             <h2>Python shennanigans.</h2>
           </div>
           <div class='static_double_column3'>
-            <div><div id=intro><p> The following shennanigans were collected during my work on creating a system integration library and framework for hardware and software tests including developer tasks like worktree management, building, target deployment and configuration. Therefore it should be representative for things one might want to do in absence of better tooling. The used Python version was 3.8.2, but most problems still persist.</p></div><div id=tldr><p> My <a href="#tldr"><strong>tldr;</strong></a> retrospection upfront, which you may be able to reproduce once you try to code long-running services, which recover from all failures, cleanly reset state or generally try to debug spurious problems. Please don’t.</p><p>Python on itself is great for prototyping up to a few hundred lines of code, like to quickly receive or send some json over tcp/html. <strong>However</strong>, it is unfeasible to scale, for example to use as library code. Changes in a leaf function can add exceptions to higher level code paths and handling those via exceptions for user friendly error messages, for example to collect context (information along multiple functions, for example from different combination of traversal) becomes unreasonably verbose and error prone. The alternative is to use C-like error handling, which requires to figure out all possible exceptions of Python libstd methods, which language servers do not support (as of 20240404).</p></div><div id=list_of_shennanigans><p> Aside of these more fundamental limitations, here the <a href="#list_of_shennanigans">list of shennanigans</a> I have run into:</p><ul><li><code>xml.dom.minidom</code> <a href="https://bugs.python.org/issue5752" target="_blank">breaks space and newlines</a>. Use <code>ElementTree</code>.</li><li><code>.strip()</code> is necessary after file read, because Python automatically adds <code>\n</code> and there is no way to read without newlines into a list.</li><li>Testing for subdictionaries with <code>dict</code> is unreadable, so such a method is missing <figure><pre><code class="python"><span class="keyword">def</span> <span class="function">is_subdict</span>(<span class="variable">small</span>: <span class="type">dict</span>, <span class="variable">big</span>: <span class="type">dict</span>) <span class="operator">-&gt;</span> <span class="type">bool</span>:
+            <div><div id=intro><p> The following shennanigans were collected during my work on creating a system integration library and framework for hardware and software tests including developer tasks like worktree management, building, target deployment and configuration. Therefore it should be representative for things one might want to do in absence of better tooling. The used Python version was 3.8.2, but most problems still persist.</p></div><div id=tldr><p> My <a href="#tldr"><strong>tldr;</strong></a> retrospection upfront, which you may be able to reproduce once you try to code long-running services, which recover from all failures, cleanly reset state or generally try to debug spurious problems. Please don’t.</p><p>Python on itself is great for prototyping up to a few hundred lines of code, like to quickly receive or send some json over tcp/html. <strong>However</strong>, it is unfeasible to scale, for example to use as library code. Changes in a leaf function can add exceptions to higher level code paths and handling those via exceptions for user friendly error messages, for example to collect context (information along multiple functions, for example from different combination of traversal) becomes unreasonably verbose and error prone. The alternative is to use C-like error handling, which requires to figure out all possible exceptions of Python libstd methods, which language servers do not support (as of 2024-04-04).</p></div><div id=list_of_shennanigans><p> Aside of these more fundamental limitations, here the <a href="#list_of_shennanigans">list of shennanigans</a> I have run into:</p><ul><li><code>xml.dom.minidom</code> <a href="https://bugs.python.org/issue5752" target="_blank">breaks space and newlines</a>. Use <code>ElementTree</code>.</li><li><code>.strip()</code> is necessary after file read, because Python automatically adds <code>\n</code> and there is no way to read without newlines into a list.</li><li>Testing for subdictionaries with <code>dict</code> is unreadable, so such a method is missing <figure><pre><code class="python"><span class="keyword">def</span> <span class="function">is_subdict</span>(<span class="variable">small</span>: <span class="type">dict</span>, <span class="variable">big</span>: <span class="type">dict</span>) <span class="operator">-&gt;</span> <span class="type">bool</span>:
     <span class="string">&quot;&quot;&quot;
     Test, if &apos;small&apos; is subdict of &apos;big&apos;
     Example: big = {&apos;pl&apos; : &apos;key1&apos;: {&apos;key2&apos;: &apos;value2&apos;}}

articles/shennanigans_in_python/index.html

@@ -16,7 +16,7 @@ <h1><span class="reset_a"><a href="/">Jans Website</a></span></h1>
             <h2>Zig shennanigans.</h2>
           </div>
           <div class='static_double_column3'>
-            <div><div id=intro><p> As of <del>20240404 (zig version 0.12.0-dev.3562+96bc8f17c)</del> 20240701 (zig version 0.14.0-dev.4234+1e3fb4825),</p><ul><li>Zig provides one of the best possible semantics to optimize memory details, while offering widely portable source code with reasonable safety in a relative concise and readable way.</li><li>Aside of signaling for toolings, I found personally no major annoying parts. For example, picking up nested slices and some build system parts might be inconvenient, but those are one time things and no footguns.</li></ul><p>The rest of the language feels very smooth to me in contrast to the potential very flexible and cryptic syntax of C (see <a href="https://github.com/JadLevesque/PPMP-Iceberg" target="_blank">preprocessor iceberg</a>).</p><ul><li>Bottlenecks of array assignments not obvious via <code>@memcpy</code>: <figure><pre><code class="zig"><span class="keyword">test</span> <span class="string">&quot;perf array assignment&quot;</span> <span class="punctuation bracket">{</span>
+            <div><div id=intro><p> As of <del>2024-04-04 (zig version 0.12.0-dev.3562+96bc8f17c)</del> 2024-07-01 (zig version 0.14.0-dev.4234+1e3fb4825),</p><ul><li>Zig provides one of the best possible semantics to optimize memory details, while offering widely portable source code with reasonable safety in a relative concise and readable way.</li><li>Aside of signaling for toolings, I found personally no major annoying parts. For example, picking up nested slices and some build system parts might be inconvenient, but those are one time things and no footguns.</li></ul><p>The rest of the language feels very smooth to me in contrast to the potential very flexible and cryptic syntax of C (see <a href="https://github.com/JadLevesque/PPMP-Iceberg" target="_blank">preprocessor iceberg</a>).</p><ul><li>Bottlenecks of array assignments not obvious via <code>@memcpy</code>: <figure><pre><code class="zig"><span class="keyword">test</span> <span class="string">&quot;perf array assignment&quot;</span> <span class="punctuation bracket">{</span>
     <span class="type qualifier">const</span> <span class="variable">x</span><span class="punctuation delimiter">:</span> <span class="type builtin">u8</span> = <span class="number">100</span><span class="punctuation delimiter">;</span>
     <span class="type qualifier">const</span> <span class="variable">a</span><span class="punctuation delimiter">:</span> <span class="punctuation bracket">[</span><span class="number">1_000_000</span><span class="punctuation bracket">]</span><span class="type builtin">u8</span> = <span class="punctuation delimiter">.</span><span class="punctuation bracket">{</span><span class="variable">x</span><span class="punctuation bracket">}</span> <span class="operator">**</span> <span class="number">1_000_000</span><span class="punctuation delimiter">;</span>
     <span class="type qualifier">var</span> <span class="variable">b</span><span class="punctuation delimiter">:</span> <span class="punctuation bracket">[</span><span class="number">1_000_000</span><span class="punctuation bracket">]</span><span class="type builtin">u8</span> = <span class="constant builtin">undefined</span><span class="punctuation delimiter">;</span>
@@ -27,7 +27,7 @@ <h2>Zig shennanigans.</h2>
     <span class="comment">// pile of code</span>
 <span class="punctuation bracket">}</span>
 </code></pre>
-<figcaption>perf_array_assignment.zig</figcaption></figure></li><li>Signaling: Test runner allows no signaling to <code>qemu -g 4242</code> (debugger mode). Qemu uses gdb server signaling, which means sending SIGKILL is necessary to kill the debugging server process.</li><li>Memory, aliasing and pointer semantics: Zig inherits from LLVM potential miscompilations due to longstanding provenance and aliasing bugs. (Updated 20240701)<ul><li><a href="https://github.com/ziglang/zig/issues/20198" target="_blank">Zig upstream issue</a></li><li><a href="https://github.com/llvm/llvm-project/issues/33896" target="_blank">LLVM upstream issue</a></li><li><a href="https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html" target="_blank">Related Rust RFC</a></li><li><a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105294#c2" target="_blank">Related gcc issue</a></li></ul></li><li>Weak memory semantics: Zig inherits from LLVM the same class of problems from the C11 memory model. As of 20240701, and take below statements with a big grain of salt, since I did not check thoroughly common vendors and I do mostly rely on talks from ACM SIGPLAN FOWM’24 and “Multicore Semantics: Making Sense of Relaxed Memory”. (Updated 20240701)<ul><li>There is nothing conclusive on how the “out of thin air problem” should be fixed, which is problematic for reasoning with weak memory.</li><li>Many hardware architectures have no sufficiently ISA-complete (and formally verified) synchronization models.</li><li>There is no official test corpus to stress test architectures by vendors or third parties.</li><li>There is no official test corpus with code and optimization models to test formal model influence of example code.</li><li>There is no debugging tooling to identify and trace or track down synchronization bugs from weak memory (in production) or vendor recommended strategies to stress test on their platforms (derived from the formal models of the architecture).</li></ul></li></ul></div></div>
+<figcaption>perf_array_assignment.zig</figcaption></figure></li><li>Signaling: Test runner allows no signaling to <code>qemu -g 4242</code> (debugger mode). Qemu uses gdb server signaling, which means sending SIGKILL is necessary to kill the debugging server process.</li><li>Memory, aliasing and pointer semantics: Zig inherits from LLVM potential miscompilations due to longstanding provenance and aliasing bugs. (Updated 2024-07-01)<ul><li><a href="https://github.com/ziglang/zig/issues/20198" target="_blank">Zig upstream issue</a></li><li><a href="https://github.com/llvm/llvm-project/issues/33896" target="_blank">LLVM upstream issue</a></li><li><a href="https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html" target="_blank">Related Rust RFC</a></li><li><a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105294#c2" target="_blank">Related gcc issue</a></li></ul></li><li>Weak memory semantics: Zig inherits from LLVM the same class of problems from the C11 memory model. As of 2024-07-01, and take below statements with a big grain of salt, since I did not check thoroughly common vendors and I do mostly rely on talks from ACM SIGPLAN FOWM’24 and “Multicore Semantics: Making Sense of Relaxed Memory”. (Updated 2024-07-01)<ul><li>There is nothing conclusive on how the “out of thin air problem” should be fixed, which is problematic for reasoning with weak memory.</li><li>Many hardware architectures have no sufficiently ISA-complete (and formally verified) synchronization models.</li><li>There is no official test corpus to stress test architectures by vendors or third parties.</li><li>There is no official test corpus with code and optimization models to test formal model influence of example code.</li><li>There is no debugging tooling to identify and trace or track down synchronization bugs from weak memory (in production) or vendor recommended strategies to stress test on their platforms (derived from the formal models of the architecture).</li></ul></li></ul></div></div>
           </div>
       </div>
     </div>