this post was submitted on 17 Oct 2024
1383 points (98.9% liked)

RetroGaming

23860 readers
443 users here now

Vintage gaming community.

Rules:

  1. Be kind.
  2. No spam or soliciting for money.
  3. No racism or other bigotry allowed.
  4. Obviously nothing illegal.

If you see these please report them.

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] Valmond@lemmy.world 21 points 8 months ago (6 children)

Yep but not if you write sloppy C code. Gotta keep those nuts and bolts tight!

[–] Wilzax@lemmy.world 32 points 8 months ago (5 children)

If you're writing sloppy C code your assembly code probably won't work either

[–] 0x0@lemmy.dbzer0.com 12 points 8 months ago (4 children)

Except everyone writing C is writing sloppy C. It's like driving a car, there's always a non-zero chance of an accident.

Even worse, in C the compiler is just waiting for you to trip up so it can do something weird. Think the risk of UB is overblown? I found this article from Raymond Chen enlightening: https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633

[–] calcopiritus@lemmy.world 2 points 8 months ago

I recently came across a rust book on how pointers aren't just ints, because of UB.

fn main() {
    a = &1
    b = &2
    a++
    if a == b {
        *a = 3
        print(b)
    }
}

This may either: not print anything, print 3 or print 2.

Depending on the compiler, since b isn't changed at all, it might optimize the print for print(2) instead of print(b). Even though everyone can agree that it should either not print anything or 3, but never 2.

load more comments (3 replies)
load more comments (3 replies)
load more comments (3 replies)