Hacker News Reader

Comment by chris_wot | Hacker News Reader

The genie is out of the bottle already, gcc quite sensibly will warn you if it sees an assignment operator in an if statement. I'm sure it's saved countless man hours and pretty awful bugs since it was introduced :-)

View on HN

Specifically, it doesn't warn you if the assignment statement is in parenthesis, so while ((xs = xs->tail)) doesn't warn. I really like how GCC handles that.

I just noticed this comment. OK, you've definitely got a good point. That is elegant.

I hope it doesn't warn for things like

if(0 != (i = getValue()))

I hope it does!

Why would that be a warning? It's quite clear what that code is doing and is a reasonably common C idiom.

Yeah, fair enough. It's not bad - I had to think about my objection to it and it's probably largely unfounded.

the problem being refered to here is :

> if (i = 0)

instead of

> if (i == 0)

It doesn't since the assignment is in brackets. You can also write

    if ((i = getValue()))

Why not be absolutely sure?

  if (0 != (0 != (i = getValue())))

I am aware of the redundancy, this was about the new warnings. If you can't do if(i = getValue()) without warning, I was wondering if assignments as a part of a larger expression would pass.

Reply on news.ycombinator.com