>100k loc C project
>only error message you get is Segmentation fault: core dumped
how do you even proceed to debug this shit?
meanwhile in Rust error messages show you everything you need to fix the problem
 DMT Has Friends For Me Shirt $21.68 |
 |
DMT Has Friends For Me Shirt $21.68 |
That's the neat part, you don't debug.
gdb lldb
Unironically these. Rust code isn't immune to logic errors or UB either so you have to know what could be happening.
Well actually, Rust is safe from UB as long as you don't use unsafe blocks.
no
>as long as you don't use unsafe blocks
so, not a single nontrivial rust project in existence
Ok sure. LLVM's broken shit still randomly fricks up rust code though and you're going to have to use unsafe eventually anyhow. I'm not saying rust isn't a step up by the way, merely pointing out weird "heisenbugs" will happen and you have to just know how to solve them.
The fact that they don't understand this immediately tells you that they're nocoders and should be disregarded. They will argue with you until they're blue in the face that optimizing compilers are good boys and perfect in every way, and you can always trust the hardware. They will do so because this is what they've been told. Their lack of experience shields them from the brutal reality of software engineering.
Me? I've seen things you people wouldn't believe. CPUs hopping memory fences. Compilers throwing out critical code for no discernable reason. NaN > 0.0f == true. I trust nothing and no one anymore. Complexity is just more space for shit to break, and believe me, shit WILL break. We're just pawns fighting an unwinnable war.
Compile it with debugging.
just print shit???
This, unironically. I've fixed atrocious bugs in company's .js engine just by console.log() stuff. I'm too lazy to configure nvim-dap.
The neat thing about a segfault is that it's 95% of the time synonymous to "yo dumbfrick, you tried to access memory that doesn't exist", i.e. either a nullptr dereference or array indexing out of bounds. Just attach a debugger, run the program, and enjoy your program halting at the exact line that caused the segfault.
If only, a good portion of segfaults go away with the debugger attatched.
Not since 1989, you dumb frick
I am pretty sure I have done some coding more recently than 1989
It doesn't matter what decade you're in. Undefined behavior is still undefined.
And it doesn't stop being undefined when a debugger is attached.
-g3 -fsanitize=address
come on dude
>Code becomes so slow the problem doesn't happen.
I know you'll cope, but it's true.
>these are the mentally ill losers telling you your language is bad and they'll invent a new one that's better
lol
lmao
Compiler options? Never heard of em!
-W -Wall -pedantic -Werror etc
gcc14 even has something similar to a borrow checker (a symbolic interpreter).-fsomething
And Rust is just another level from C, way. better, decades (of research) more advanced. The most advanced imperative language ever, which borrows from CLU, Ada and other academic imperative languages, even from Haskell
https://lngnmn2.github.io/articles/like-haskell-but-imperative/
Idiots, idiots everywhere.
>no evidence
sure, guy
>-W -Wall -pedantic -Werror etc
Cniles don't even know these exist
With a debugger, you absolute moron. The same way you do in Rust.
gdb main
start
run until it breaks
bt
info locals / select frame / display expr etc.
there you go if you want magic use rr make sure you use a modern ryzen or a intel cpu.
tldr use gdb/lldb
congrats on compiling!
Now you are going to pipe to bash and print "nyello minasama" and close the connection every 10k lines until you find where the problem is
>i have done that and its a runtime segfault
LOLOL, reread the code, this will take you a week at the least
imagine not knowing what a debugger is
skill issue
skill issue