I’m fairly certain that last one is UB in C. The result of an assignment operator is not an lvalue, and even if it were it’s UB (at least in C99) to modify the stored value of an object more than once between two adjacent sequence points. It might work in C++, though.
It’s amazing how much work goes into cleaning up code before you feel comfortable posting it to a mailing list that you would never even bother doing for internal-only stuff.
<span style="color:#323232;">for (int y = MIN_INT; y <= MAX_INT; y++) {
</span><span style="color:#323232;"> if (y == x + 1) {
</span><span style="color:#323232;"> x = y;
</span><span style="color:#323232;"> }
</span><span style="color:#323232;">}
</span>
(Not sure there’s a way to prevent Lemmy from escaping my left angle bracket. I definitely didn’t type ampersand-el-tee. You’ll just have to squint and pretend. I’m using the default lemmy-ui frontend.)
The backticks worked in the preview, and showed up correctly to start, but there must be a bug in the lemmy ui, since now it’s double-escaped. No idea /shrug
It will not “overflow”. Signed integer overflow is undefined behavior. The compiler could remove the whole loop or do anything else imaginable (or not).
Languages with dynamic typing and implicit large-integer types, such as Python and Ruby, generally just convert to that large-integer type.
I figured Java would probably define the behavior in the JVM, but based on a quick web search it sounds like it probably doesn’t by default, but does provide library methods to add or subtract safely.
Rust guarantees a panic by default, but provides library methods for wrapping, saturating, and unchecked (i.e. unsafely opting back in to undefined behavior).
Still false, thanks to compiler optimizations. Remember that integer overflow is UB. (unless you’re using unsigned int or a programming language which strictly defines integer overflow, possibly as an error)
So… too many cooks creating overly complicated meals that occasionally are admirably but more often then not are not worth the money. Also really hard to get into and make more efficient.
Bloated complex frontend with so gosh darn many tools, some specifically created for one certain meals but sometimes get used for other meals, more or less effective. Sometimes it’s already at the table, sometimes gets delivered with your meal.
Fancy looking APIs but you somehow have to know how to correctly talk to them and if you phrase something wrong, well good luck.
VS:
Simple, efficient, maybe not as sophisticated but if you get too many customers: just order a second one.
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.