181–190 of 320 posts
Earlier quoted context omitted.
Not after exit(0) returns, no. Instead, you're going to want it after some programmer removes exit(0) six months from now.
I'm going to write a pre-processor which adds the appropriate `break` statements automatically. No more fall-through bug. (And if you really want to fall through, I could add a `fallthrough` keyword.)
Earlier quoted context omitted.
In those times I wish I could use the emacs lisp way: (let (dir "/foo") (create-directory dir) (with-current-directory dir (delete-all-files-recursively))) Factor recognized the value of dynamically scoped variables: http://concatenative.org/wiki/view/Factor/FAQ/What's%20Facto... A lot of code became much simpler because of that decision.
What's wrong with the C version? char *dir = "/foo"; mkdir(dir, 0700); if (chdir(dir) == 0) delete_all_files();
char *olddir = getcwd();
chdir(newdir);
try {
do_stuff();
} finally {
chdir(olddir);
}Earlier quoted context omitted.
> Note however, that strictly speaking stderr does not have to be 2. It Nope. On POSIX systems stderr is defined as 2: http://pubs.opengroup.org/onlinepubs/9699919799/functions/st... > The following symbolic values in define the file descriptors > that shall be associated with the C-language stdin, stdout, and stderr > when the application is started: > > STDIN_FILENO > Standard input value, stdin. Its value is 0. >…
Not quite. That is according to POSIX, but not the C standard. stderr is defined by the C standard. POSIX is a standard followed by many of the systems that run C. Strictly speaking, stderr does not have to be 2. It wouldn't comply with POSIX in that case, but it would still be C.
And this is why I think Go-lang and its multi-return is the way of the future. In Go you are required to handle errors. If you want them to go away you have to explicitly use an _ and thats really easy to find in the code and shame the person who did it. Nothing fails silently. Nothing fails via primary return. It is such greatness it is hard to express.
If you don't understand how to use sharp tools, you may hurt yourself and others. Documentation for fork() clearly explains why and when fork() returns -1. Those that find the man page lacking or elusive may get more out of an earnest study of W. Richard Stevens' book, Advanced Programming in the UNIX Environment. In any case, every system programmer should own a copy and understand its contents.
"Unix: just enough potholes and bear traps to keep an entire valley going." If you don't understand how to use sharp tools, you may hurt yourself and others. Documentation for fork() clearly explains why and when fork() returns -1. Those that find the man page lacking or elusive may get more out of an earnest study of W. Richard Stevens' book, Advanced Programming in the UNIX Environment. In any case, every system pr…
I'd argue every programmer. It's such a fundamental part of computers & operating systems that key concepts will come up again and again. Just the other day I wanted to learn about Docker/CoreOS/etcd only to realize that I have an embarrassingly lacking understanding of how UNIX works. I immediately went to the library to pick up this book and begin fixing a flaw of mine (even as a web developer).
Earlier quoted context omitted.
In those times I wish I could use the emacs lisp way: (let (dir "/foo") (create-directory dir) (with-current-directory dir (delete-all-files-recursively))) Factor recognized the value of dynamically scoped variables: http://concatenative.org/wiki/view/Factor/FAQ/What's%20Facto... A lot of code became much simpler because of that decision.
$ mkdir /tmp/foo && cd /tmp/foo && touch bar.txt
This style is pretty prevalent when writing test cases in shell (or just shell scripts in general), e.g. when using something like sharness[1].
"Unix: just enough potholes and bear traps to keep an entire valley going." If you don't understand how to use sharp tools, you may hurt yourself and others. Documentation for fork() clearly explains why and when fork() returns -1. Those that find the man page lacking or elusive may get more out of an earnest study of W. Richard Stevens' book, Advanced Programming in the UNIX Environment. In any case, every system pr…
It's still bad API design when naively handling an error case kills everything. Is there an inherent reason that the error value for a pid has to be the same as the "all pids" value? Unless there's a very compelling reason, it seems like very poor design, well documented or not.
I see a lot of comments blaming the programmer. This is completely the wrong attitude. Why are you treating the programmer like a machine? They're not a machine -- they're human. Regardless if they fully understand the API or not things should have have sane defaults for HUMAN FACTORS reasons. Bugs will always exist. The fact that the Linux kernel has many bugs is just one example of a code base that has over a decad…
In general I agree with your "don't blame the programmer" point, but I would seriously hesitate to criticize fork(). Yes, in 2014, that behavior seems uncommon and it seems like very poor design to lump such destructive behavior into an otherwise meaningless "-1"... but remember that fork was not written in 2014. It was written forty-five years ago . I'm not saying it was a great API design decision back then, but I'…
I don't use fork() that often, but my own paranoia is why I always test for if len(some_list) But it's just my way of covering my ass in case the laws of physics change during execution, or just in case weird bugs exist like those found in this article.
If you're not sure whether len() can return -1, and in turn what that value means, then you can't know that your code is any more correct.
In fact, this is going to be worse than a equals comparison because instead of having code that clearly doesn't handle a corner case you have code that lies about what values it can correctly handle. That makes it much harder to debug.