Earlier quoted context omitted.
One of the best books: Computer Systems: A Programmer's Perspective (3rd Edition)
I second this. Seriously the best textbook on systems programming I've worked through especially when accompanied with the famous CMU labs[0]. Anyone who works thoroughly through this book can become a master systems programmer. [0]: http://csapp.cs.cmu.edu/3e/labs.html
Brushing up on operating systems and C programming
31–40 of 89 posts
Re: Brushing up on operating systems and C programming
#32Marshall Kirk McKusick's FreeBSD Intensive Code Walkthrough: https://www.mckusick.com/courses/advdescrip.html
Also, The Design and Implementation of the FreeBSD Operating System (2nd Edition): https://www.amazon.com/Design-Implementation-FreeBSD-Operati...
Thirdly: grab a copy of FreeBSD (or OpenBSD) and (a) set it up in VirtualBox and SSH it into locally (b) use an old ThinkPad. Then grab the source code of the base system. Build and install it. And start reading code of things like usr.bin/grep/grep.c
Re: Brushing up on operating systems and C programming
#33Can anyone recommend an intermediate to advanced C book? I feel like most C material I've been exposed to in the past lacks what a modern C project should have when it comes to best practices, code organization, build tools (should I use make for this, cmake, where does autotools fit? what about clang vs gcc?), linters (valgrind?), testing, etc. I recognize that much of this falls outside of C, but all of these tools…
I would recommend https://www.amazon.com/C-Programming-Modern-Approach-2nd/dp/... . There's specifically a section on organizing large projects IIRC.
Re: Brushing up on operating systems and C programming
#34Haven't personally done it for a few years, but I went through step by step on my blog (particularly in 2014):
https://austingwalters.com/knowledge/
I also have a nice repo of a bunch of IPC examples:
Re: Brushing up on operating systems and C programming
#35Can anyone recommend an intermediate to advanced C book? I feel like most C material I've been exposed to in the past lacks what a modern C project should have when it comes to best practices, code organization, build tools (should I use make for this, cmake, where does autotools fit? what about clang vs gcc?), linters (valgrind?), testing, etc. I recognize that much of this falls outside of C, but all of these tools…
* Clang vs gcc: doesn't really matter. Clang has slightly better compile times. GCC has really advanced but in some cases still has inferior warning/error messages. Best practice is not to really use GNU c features unless you want to. If you do want to, decide if you want to just use the subset supported by clang or the full shabang from gcc. Beyond that: if you want to support both, test on both before release and do release builds using whichever produces faster or smaller (choose whichever metric you prefer) binaries.
* Build systems: plain old make is sufficient in most cases. I would recommend autoconf over cmake just because it's significantly simpler, although cmake has better cross-platform support (it can generate visual studio build files, for instance). I wouldn't use something outside of make, cmake, or autoconf, even if it seems like it's better in every way than those, because it probably isn't, and even if it is, you lose out on the battle-tested, available-everywhere, and widely-used nature of the above build systems. I shouldn't have to install a build system to build your program, and if I do, I should be able to use that build system to build a significant of other programs too.
* Linting: not really necessary IME. Aim for no compiler warnings, though.
* Yes, use valgrind. Anything it complains about, fix. Uninitialized values and out-of-bounds memory accesses are significantly more important and worrisome than memory leaks (because they represent potential attack vectors), but still, it won't complain about something unless it's actually something that should be complained about.
* Testing: like the other commenter said, just a little bit of macro magic and you're golden.
* Code organization: headers in include/, source files in src/. You can separate src/ into subdirectories if your project grows to sufficient complexity that the source files become difficult to wrangle. Separating the headers into separate directories is probably not necessary, however.
* Not directly c-related, but pick a SANE code style and stick to it.
* Debugging: make a separate target that compiles in debug symbols and disables optimizations, and use gdb (or lldb) on it. You don't need much to get started: 99% of the time, all I do is "break main", "run" ("r" for short), "backtrace" ("bt" for short), "frame " (to switch between stack frames), and "print " ("p " for short); it's taken me quite far.
Re: Brushing up on operating systems and C programming
#36I recommend (by most expensive, to free): Marshall Kirk McKusick's FreeBSD Intensive Code Walkthrough: https://www.mckusick.com/courses/advdescrip.html Also, The Design and Implementation of the FreeBSD Operating System (2nd Edition) : https://www.amazon.com/Design-Implementation-FreeBSD-Operati... Thirdly: grab a copy of FreeBSD (or OpenBSD) and (a) set it up in VirtualBox and SSH it into locally (b) use an old Thin…
I'm thankful to have the opportunity to learn from someone with such deep knowledge of Unix, who was involved with BSD from the early days in the 80s to modern FreeBSD.
Re: Brushing up on operating systems and C programming
#37Can anyone recommend an intermediate to advanced C book? I feel like most C material I've been exposed to in the past lacks what a modern C project should have when it comes to best practices, code organization, build tools (should I use make for this, cmake, where does autotools fit? what about clang vs gcc?), linters (valgrind?), testing, etc. I recognize that much of this falls outside of C, but all of these tools…
To answer your questions: * Clang vs gcc: doesn't really matter. Clang has slightly better compile times. GCC has really advanced but in some cases still has inferior warning/error messages. Best practice is not to really use GNU c features unless you want to. If you do want to, decide if you want to just use the subset supported by clang or the full shabang from gcc. Beyond that: if you want to support both, test on…
Clang seems to have better sanitizer support, which can be lighter weight initial passes before running valgrind.
Re: Brushing up on operating systems and C programming
#38Earlier quoted context omitted.
I second this. Seriously the best textbook on systems programming I've worked through especially when accompanied with the famous CMU labs[0]. Anyone who works thoroughly through this book can become a master systems programmer. [0]: http://csapp.cs.cmu.edu/3e/labs.html
I am currently going through this book. Any advice on how to extract the most value out of it?
[0]: http://www.man7.org/tlpi/ [1]: https://www.cs.cmu.edu/~213/assignments.html
Re: Brushing up on operating systems and C programming
#39Can anyone recommend an intermediate to advanced C book? I feel like most C material I've been exposed to in the past lacks what a modern C project should have when it comes to best practices, code organization, build tools (should I use make for this, cmake, where does autotools fit? what about clang vs gcc?), linters (valgrind?), testing, etc. I recognize that much of this falls outside of C, but all of these tools…
One of the best books: Computer Systems: A Programmer's Perspective (3rd Edition)