RetroGaming

19662 readers

438 users here now

Vintage gaming community.

Rules:

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

If you see these please report them.

founded 2 years ago

MODERATORS

Xylinna@lemmy.world

Tenthrow@lemmy.world

gts@lemmy.world

1367

How hard could it be? (lemmy.world)

submitted 1 month ago by The_Picard_Maneuver@lemmy.world to c/retrogaming@lemmy.world

176 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] Valmond@lemmy.world 21 points 1 month ago (1 children)

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

[–] Wilzax@lemmy.world 30 points 1 month ago (1 children)

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

[–] 0x0@lemmy.dbzer0.com 12 points 1 month ago (3 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 1 month 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.

[–] UpperBroccoli@lemmy.blahaj.zone 1 points 1 month ago

I hope you are not argueing that using assembly is an improvement over using C in that regard....

[–] Buddahriffic@lemmy.world 1 points 1 month ago (1 children)

A compiler making assumptions like that about undefined behaviour sounds just like a bug. Maybe the bug is in the spec rather than the compiler, but I can't think of any time it would be better to optimize that code out entirely because UB is detected rather than just throwing an error or warning and otherwise ignoring the edge cases where the behaviour might break. It sounds like the worst possible option exactly for the reasons listed in that blog.

[–] calcopiritus@lemmy.world 2 points 1 month ago

The thing about UB is that many optimizations are possible precisely because the spec specified it as UB. And the spec did so in order to make these optimizations possible.

Codebases are not 6 lines long, they are hundreds of thousands. Without optimizations like those, many CPU cycles would be lost to unnecessary code being executed.

If you write C/C++, it is because you either hate yourself or the application's performance is important, and these optimizations are needed.

The reason rust is so impressive nowadays is that you can write high performing code without risking accidentally doing UB. And if you are going to write code that might result in UB, you have to explicitly state so with unsafe. But for C/C++, there's no saving. If you want your compiler to optimize code in those languages, you are going to have loaded guns pointing at your feet all the time.