3 ms·
It used to be that if someone released a tool that's 700 lines of C, they probably had an actual need and a problem they solved by writing that code because deb
by pavlov 1y ago
It used to be that if someone released a tool that's 700 lines of C, they probably had an actual need and a problem they solved by writing that code because debugging even that amount of C tends to be non-trivial.
Today all bets are off. Does the tool do anything anybody needed? Does it work? Who knows. It might just be 700 lines of convincing-looking C churned out by a model.
- checker659 1y agoIt could be a vehicle to learn about traceroute / ICMP.
- anonymous908213 1y agoFor whom? What is the creator going to learn from pasting code they've never read? What are readers going to learn from reading code the "author" themselves didn't read, let alone write? If you want to learn about something, reading an LLM-generated repo seems to be about the worst possible way to do it. That's not even to say LLMs are useless for learning; you could ask directly about concepts without having it write all the code for you, but this is the lowest effort application of the tool and is more of a vehicle for anti-learning than anything.
- checker659 1y agoI meant that IFF the author wrote it themself. IFF.
- pjmlp 1y agoWell I was surprised that it actually makes use of "-Wall -Wextra" as good practice. However both PVS-Studio and clang-tidy have a few complaints about the code, since it is a single file, it is rather easy to try out on Compiler Explorer. https://godbolt.org/z/n4M1vGccq https://godbolt.org/z/n4M1vGccq As for your remark, most folks seem to have not followed that C authors also created lint in 1979, Dennis Ritchie proposed fat pointers to WG14, Plan9 was going to use Alef, which failed but its ideas were re-used for Limbo on Inferno, and they were also involved with Go. Finally Rust's borrow checker ideas steam from AT&T research with Cyclone, as way to create a safe C. As such the real question is why still use C in new projects, when even the language authors have moved beyond it, or at least reduce their use of it on userspace applications.
- johnisgood 1y agoWe live in a world where now using "-Wall -Wextra" is a positive outlier. :D God damn. I have ALWAYS used these options, along with "-pedantic", "-std=c99" and so forth.
- matltc 1y agoI picked up C for fun last year and this is exactly the flags I have always used by default. Can't remember where I picked that up, but glad to hear I'm doing it right
- deleted 1y ago[deleted]
- johnisgood 1y agoYes you are. I always use "-std=c99 -Wall -Wextra -Wpedantic -Werror". You could replace "-Wpedantic" with "-pedantic" though (it is more supported). You may omit "-Werror". Sometimes I also use "-D_XOPEN_SOURCE=700" and "-D_FORTIFY_SOURCE=2" along with "-fstack-protector-strong". For debug builds you want "-O0 -g" at the very least. I also have a make target that uses "scan-build", "cppcheck", and "clang-tidy".
- 9029 1y agoWhile we are at it, here are some more useful warning flags I have used: https://github.com/cpp-best-practices/cppbestpractices/blob/master/02-Use_the_Tools_Available.md#compilers https://github.com/cpp-best-practices/cppbestpractices/blob/.... Some C++-only though, some are a bit opinionated (like -Wsign-conversion) and some useful C-only flags might be missing. Few C-specific references I found just now, but haven't tried myself yet: https://github.com/systemd/systemd/blob/0885e4a6e7ca93d3aef8186640bee911e81e3f4f/meson.build#L382 https://github.com/systemd/systemd/blob/0885e4a6e7ca93d3aef8... https://github.com/airbus-seclab/c-compiler-security https://github.com/airbus-seclab/c-compiler-security Also a good idea to regularly run the program with sanitizers, using them in tests is a good way to do that I think. Why not during development as well if the performance is acceptable for that specific program.