Hacker News Reader

Comment by heinrichhartman | Hacker News Reader

Am I the only one who finds this

    int yes=1;
    setsockopt(listener, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof (yes)) ;

much cleaner than this

    setsockopt(listener, SOL_SOCKET, SO_REUSEADDR, &(int) {1}, sizeof(int));

?

View on HN

But it's C99, so you can do:

    setsockopt(listener, SOL_SOCKET, SO_REUSERADDR, &(int) {true}, sizeof(int));

I think this makes the intent clearer.

Beyond the readability aspect, I really dislike that the programmer is required to make sure that the inline datatype matches the type passed to sizeof. If the API ever changes, e.g. to using a long, it has to be changed in two places, and there will be no compiler error if it isn't. Using a separate variable takes care of that automatically.

I agree anything is better than a magic number, but really only if the variable is properly descriptive.

What are we saying 'yes' to?

Definitely agree that calling it `reuse_local` makes more sense, but OP was just quoting the blogpost.

And the blog post was just quoting Beej.

Whatever you pass the yes to.

> *What are we saying 'yes' to?

The flag SO_REUSEADDR (SO = Socket Option); really, I'd say we're setting the flag / setting the flag to true, but true is a bit of a reserved word, which I'm guessing is why they went with "yes".

No, you are not the only one.

The author of that code is trying to make it explicit -- "yes, I want to allow reuse of local addressses". Some will prefer this, some won't.

I personally like the use of the variable, though I think it's not worth getting all bent out of shape about it one way or another. But I guess we all have our pet peeves, and I know I'm guilty of getting all bent out of shape about things that ultimately don't matter much.

Code is read many times more than it is written. If someone scrutinizes code for clear intent, I don’t think that should be considered a “pet peeve” or some quirk to be explained away.

I feel that code that needs to be read a lot is badly named, commented or dodgy.

I wasn't suggesting that any scrutinizing of the code for clear intent should be considered a "pet peeve". I was saying I see both sides in this particular case, and that in my opinion devlopers (myself included) often make a way bigger deal out of things than they really are -- when the larger part of their offense toward a particular choice is often more about personal taste than it is anything else (thus the reference to pet peeves).

Again, I like the use of the variable, because in my opinion it makes the code a bit clearer, but I also don't think it is the end of the world if someone chooses the option without it.

No, you're not, the second part is like random json data inside C source.

Reply on news.ycombinator.com