mark as it is ,learned a lot
Brushing up on operating systems and C programming
81–89 of 89 posts
Re: Brushing up on operating systems and C programming
#82Earlier quoted context omitted.
What prompted you to review? Does this somehow indicate that you weren't using the course material in your job(s)?
I graduated from college more than 2 years ago so I forgot almost all of them CS topics that I've learned and wanted to review the fundamentals (OS, databases, computer architecture, etc). And no, I don't use of these concepts very much at work, only surface level knowledge. I've also been trying to learn more about malware analysis and reverse engineering, and it seems like having a solid foundation in CS concepts i…
Would you mind sharing what kind of software you write?
This is interesting to me, since I'm self-taught and seem to have done well in my career so far (4 years in), but now I'm going through core CS books and courses, worried that I'll hit a ceiling and wanting to fill the gaps in my knowledge. I work in devops and infrastructure.
Re: Brushing up on operating systems and C programming
#83Earlier quoted context omitted.
I would tbh recommend make (bsd make is a wider-supported subset of gnu make) over a shell script, because it can automatically detect which source files need to be rebuilt and which can be kept from previous builds, greatly reducing compile times. Also, it supports parallel builds, although this one is relatively easy with a shellscript.
If the sole purpose is to track which files changed, then redo is arguably a simpler solution to this problem - you don't need to learn a new language either (and its funky rules like the tab/space difference), just shell scripts with a couple new commands. http://news.dieweltistgarnichtso.net/bin/redo-sh.html
I've never seen this before... I shall have to try it out on a C project I'm starting. Thanks!
Re: Brushing up on operating systems and C programming
#84Earlier quoted context omitted.
> Clang vs gcc: doesn't really matter. Clang seems to have better sanitizer support, which can be lighter weight initial passes before running valgrind.
What exactly is better wrt. to sanitizers with Clang?
I would also like to know. I have been using the latest versions of both clang and gcc and have not noticed any differences.
Re: Brushing up on operating systems and C programming
#85Earlier quoted context omitted.
What I liked about this book is that it's very upfront about how messed up C is. I read about half of it and it made me never want to write any C ever again. An especially memorable part for me was how it took 3 pages of language lawyering to explain why this doesn't compile: foo(const char **p) { } main(int argc, char **argv) { foo(argv); }
I don't see this as a good example of "how messed up C is". It doesn't compile because you're violating const correctness, and any other language with similarly sound correctness requirements would flag it in a similar way. If anything, this is one of those rare cases where C chooses correctness over convenience. It takes quite a bit to explain because the "common sense" is that if one level of pointer indirection al…
A better example of messed up in that example is how it's not a compile-time error (but is very nasty undefined behavior) for the function without an explicit return type (so defaulting to int) to end without returning anything.
Re: Brushing up on operating systems and C programming
#86Earlier quoted context omitted.
I do exactly the same thing whenever I write C/C++. Genuinely large projects aside, I see no compelling reason to waste your time with build systems. This approach is simple, easy to maintain and lets you get on with writing actual code.
Out of curiosity, why not use make for something so simple instead of a Shell script?
Because I don't see any value from using it. It's not easier to read or write, it doesn't force you to keep it sane and simple like a bash/cmd script generally would, and it's just another dependency I don't really need. If I take a minimalistic approach to build systems, I prefer to go all the way.
Also, although this is merely a personal quirk that shouldn't persuade anyone else, I've seen enough horrific, unreadable make files to instinctively dislike them by now.
Re: Brushing up on operating systems and C programming
#87http://pages.cs.wisc.edu/~remzi/OSTEP/ is really good and approachable. It was even recommended in one of the Gatech OS courses.
University of Waterloo also recommends Three Easy Pieces as a supplementary text for their OS course.
Re: Brushing up on operating systems and C programming
#88Earlier quoted context omitted.
> Most people new to a topic want an instructional manual or guide, not a technical reference. Man pages and tables of syscalls are decidedly the latter, and therefore primarily intended for people who are already familiar with the topics they cover But this thread is about brushing up on OS and C programming. So not novices, but people who are already familiar with the topic.
Even then... Where are you going to start in reading references? A random syscall or function a day? I think it is far more useful to e.g. read the late W. Richard Stevens' Advanced Programming in the Unix environment. It puts everything in context, provides historical background where necessary, and gives examples. Reference pages are not really for brushing up, but more for the 'what was the address family field of…
> Even then... Where are you going to start in reading references? A random syscall or function a day?
Sure. Or browse through a bunch of them?
> think it is far more useful to e.g. read the late W. Richard Stevens' Advanced Programming in the Unix environment.
That is closer to a reference than a novice tutorial.
> It puts everything in context, provides historical background where necessary, and gives examples.
Sure. So do good references. Even man pages do.
> Reference pages are not really for brushing up, but more for the 'what was the address family field of sockaddr called again'-type of questions? Or put differently: they are external memory.
It depends on your level, experience and your competence in the material I guess. I'm not saying it's the only thing you need, but in many situations, it's the only thing you need to brush up.
Re: Brushing up on operating systems and C programming
#89Earlier quoted context omitted.
I don't see this as a good example of "how messed up C is". It doesn't compile because you're violating const correctness, and any other language with similarly sound correctness requirements would flag it in a similar way. If anything, this is one of those rare cases where C chooses correctness over convenience. It takes quite a bit to explain because the "common sense" is that if one level of pointer indirection al…
A better example of messed up in that example is how it's not a compile-time error (but is very nasty undefined behavior) for the function without an explicit return type (so defaulting to int) to end without returning anything.
Compilers can - and, indeed, do - diagnose UB as compile time errors, or at least warnings (which you can then turn into errors if you want) all the time.
Now, it is not undefined behavior for the function to not return anything despite having a return type. It is UB for the caller to try to use the returned value, but in this case it's not actually used.
The implicit int feature is really very much deprecated (in fact, it was already removed in C99, almost 20 years ago!). If, for some mysterious reason, you're trying to compile code like that, it's probably very old code dating to before C was an ANSI standard, and void return type was a thing. In such code, it would be pretty common for functions to not return anything, because semantically they don't - it was just a quirk of the language that there was no notion to express a non-value-returning function back then, and so returning an (undefined) int became idiomatic. In C89, this entire behavior was retained largely because backwards compatibility was necessary. C99 finally fixed it.