Writing C code requires a lot of discipline, or the result will be a buggy piece of shit that crashes because of memory problems or race conditions all the time.I say the main problem is with C devs themselves, who think they're experienced, but actually are completely ignorant.Typical exchange:>me: nice code, but you can't do X>him: why not? it just werks>me: the C standard doesn't specify X, at least not in your case>him: I have done it for decades, it never failed before>me: that's great, but you were just lucky... it's UB and could fail with a new compiler release or if LTO is enabled>him: that's completely theoretical!Even better if you get code from a different company, which only works when you use -O0 or because they put their buggy memory accesses into a separate file to prevent the optimizer from "interfering".
>>101532252Yeah still not using C.
>>101532252are so many C programmers really so ignorant of UB? I thought it was more of a beginner thing.
>>101532279The program just works until you turn on optimizations and it explodes
>>101532279BECAUSE HALF OF THE SPEC IS UNDEFINED BEHAVIOUR
>>101532374>>101532279oh and btw, valid code can break from optimization flags too. happened to me just last week because strcat is gcc magick meat
>>101532279There are surprisingly many oldfag C devs who don't know shit. They just go by intuition, and when something goes wrong, they just add more volatiles or casts.>>101532390Post code.
>>101532252Programming and government are proof that temporary solutions are immortal.
>>101532252>race costopped reading right there, you don't know what you're talking about. no bump for you.
>>101532375C++ has more UB, not counting what's inherited
>>101532279me in the pic
>>101532897Who said anything about C++? C has a ton of UB in its own right.
>>101533324C babydyck is mindbroken>>101532252>muh UBdefine more functions.
>>101532279There is so much UB in C, its basically impossible to avoid it. The real issue is what compilers decided to do with UB. Seriously compiler devs ruined computing, pretty much all C/C++ code is one random optimization away from exploding. Did you know its not possible to implement malloc in C, writing an operating system in C is impossible. As compiler optimization gets more and more powerful, more of this UB is exploited and more existing programs are made wrong.
C forces you to do things correctly, Crowdstrike could have been prevented if people wrote in C more
>>101532252Don't rely on specification, rely on testingThere's undefined behaviors that work everywhere like signed shift and overflowAnd there's defined behavior that can cause your program to stop working due to logic mistakes of your ownComputers make people forget they are real things, reality doesn't care if it seems right, if it feels correct or it makes sense, thing can be a 100% "correct" in theory but not work. Only thing that can make a program stable is code maturity, being tested in many computers and use casesRelying on rules it's like expecting someone won't rob you because it's illegal to do so
>>101535136>Did you know its not possible to implement malloc in CMalloc is 100% possible to implement in C. Are you mixing up several other lower-level system calls like brk(2) and malloc?
>every relevant operating system is written in C>>101535136>writing an operating system in C is impossibleThese rust trannies are really getting to my nerves
>>101537701>>101537318UB makes low level fucking about with memory impossible. Sure you can write it and it will usually work in practice, but its undefined behavior and you are at the mercy of the whims of the compiler.
C users like cunny?
>>101538072>but its undefined behavior and you are at the mercy of the whims of the compilerNo it is not. Also you are a retard.
>>101538072Moron. Memory is a bunch of addresses. Addresses are variables. And when those variables should not be considered for optimization, you use the volatile keyword. It it literally that fucking simple.
I wish I had a regex to highlight all threads about the C Programming Language in all their possible formsIt's half the reason I come to /g/
>>101538255>memory ia a bunch of addresses It's more complicated than that. If that was the case then there wouldn't be strict aliasing rules preventing you from dereferencing the same pointer from differently typed variables. Or the fact that you aren't allowed to do pointer arithmetic or comparison between pointers from different allocations. You definitely cannot prevent optimization for these cases by slapping on some volatiles.
>>101532279Seems so. But I've only ever touched C++ because I'm a real man.
>>101538255lel @ cniles that don't even know their own language
>>101538255Literally the bullshit I pointed out in >>101532434.
>>101535136>Did you know its not possible to implement malloc in C,Source/reasoning?>>101538072What part of it is UB?
