<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>masklinn</author><text>&amp;gt; One thing jumped out for me. No integer overflow.&lt;p&gt;FWIW that&amp;#x27;s not quite true, Rust will panic on overflow in debug but can (and currently does on all platforms I think) allow them in release. They&amp;#x27;re not UB though, they&amp;#x27;re defined as 2&amp;#x27;s complement.&lt;p&gt;&amp;gt;  In my embedded work we use that all the time. We represent angles as a int16_t or uint16_t where you can add and subtract angles and never have to worry about a discontinuity at 2pi because 2pi=65536.&lt;p&gt;&amp;gt; Is this a hack that should not be allowed? I don&amp;#x27;t think so.&lt;p&gt;Rust provides APIs to make these behaviours explicit decisions rather than implicit hacks: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;doc.rust-lang.org&amp;#x2F;core&amp;#x2F;num&amp;#x2F;struct.Wrapping.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;doc.rust-lang.org&amp;#x2F;core&amp;#x2F;num&amp;#x2F;struct.Wrapping.html&lt;/a&gt;, &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;doc.rust-lang.org&amp;#x2F;std&amp;#x2F;?search=wrapping_&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;doc.rust-lang.org&amp;#x2F;std&amp;#x2F;?search=wrapping_&lt;/a&gt;, &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;doc.rust-lang.org&amp;#x2F;std&amp;#x2F;?search=saturating_&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;doc.rust-lang.org&amp;#x2F;std&amp;#x2F;?search=saturating_&lt;/a&gt; (and &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;doc.rust-lang.org&amp;#x2F;std&amp;#x2F;?search=checked_&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;doc.rust-lang.org&amp;#x2F;std&amp;#x2F;?search=checked_&lt;/a&gt;).&lt;p&gt;&amp;gt; People can implement bounds checking when they need to.&lt;p&gt;Being unsafe by default always ends up in tears. Checking Mitre, just this year there have already been 11 public CVE for integer overflows.</text><parent_chain><item><author>phkahler</author><text>One thing jumped out for me. No integer overflow. In my embedded work we use that all the time. We represent angles as a int16_t or uint16_t where you can add and subtract angles and never have to worry about a discontinuity at 2pi because 2pi=65536.&lt;p&gt;Is this a hack that should not be allowed? I don&amp;#x27;t think so. Every processor made (that I&amp;#x27;m aware of) in the last 30+ years has used 2&amp;#x27;s complement arithmetic. I don&amp;#x27;t think overflow is a bad thing, I think C made a mistake in calling it &amp;quot;undefined&amp;quot;. They had to because when the language came along there were other options fresh in peoples minds.&lt;p&gt;I&amp;#x27;ve also worked on systems in asm that had saturating arithmetic, and that has it&amp;#x27;s own nice use cases. My preference is still to have the rollover. People can implement bounds checking when they need to.</text></item></parent_chain></comment><story><title>Rust things I miss in C</title><url>https://people.gnome.org/~federico/blog/rust-things-i-miss-in-c.html</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>simias</author><text>Using 2&amp;#x27;s complement is not the entire story, some CPUs can trap on overflows (MIPS for instance). X86 doesn&amp;#x27;t but it does set the carry&amp;#x2F;overflow flags in case of unsigned&amp;#x2F;signed overlow to make it easy to test for it if necessary. Leaving the freedom to the implementation to catch signed overflows like it can catch divisions by zero might actually be a feature. Admittedly it&amp;#x27;s not very consistent to make unsigned overflow defined.&lt;p&gt;I like rust&amp;#x27;s approach that you &lt;i&gt;can&lt;/i&gt; explicitly decide to use overflowing arithmetic if you want, otherwise it triggers a runtime error in debug mode. That alongside with the checked_ variants make it very easy to deal with potentially overflowing code whereas in C it&amp;#x27;s a minefield, it&amp;#x27;s not difficult to trigger an UB while trying to defend against an other UB. Ask a beginner to write a &amp;quot;checked_add&amp;quot; function in C (no Stack Overflow allowed) and see how many bugs and UB you can spot.&lt;p&gt;On the other hand advocating for implicit wrapping overflow all the time sounds risky to me. In my experience there&amp;#x27;s only a very tiny subset of operations where an overflow is desired and wouldn&amp;#x27;t lead to a bug.</text><parent_chain><item><author>phkahler</author><text>One thing jumped out for me. No integer overflow. In my embedded work we use that all the time. We represent angles as a int16_t or uint16_t where you can add and subtract angles and never have to worry about a discontinuity at 2pi because 2pi=65536.&lt;p&gt;Is this a hack that should not be allowed? I don&amp;#x27;t think so. Every processor made (that I&amp;#x27;m aware of) in the last 30+ years has used 2&amp;#x27;s complement arithmetic. I don&amp;#x27;t think overflow is a bad thing, I think C made a mistake in calling it &amp;quot;undefined&amp;quot;. They had to because when the language came along there were other options fresh in peoples minds.&lt;p&gt;I&amp;#x27;ve also worked on systems in asm that had saturating arithmetic, and that has it&amp;#x27;s own nice use cases. My preference is still to have the rollover. People can implement bounds checking when they need to.</text></item></parent_chain></comment><story><title>Rust things I miss in C</title><url>https://people.gnome.org/~federico/blog/rust-things-i-miss-in-c.html</url></story>