why( warning: left-hand operand of comma expression has no effect)

Sam Bobroff sbobroff at shoretel.com
Tue Nov 20 03:54:50 CET 2012

On 20/11/12 12:32, Marc Lehmann wrote:
> On Tue, Nov 20, 2012 at 01:16:04AM +0000, Sam Bobroff <sbobroff at shoretel.com> wrote:
>> Maybe those hack strings should removed from the assert calls and be
>> moved into comments in the code?
> Calling this a "hack" just shows your immaturity in the C language - not
> everything that is new to you is badly done.
Sorry if you felt that I'd disrespected your code, that wasn't my
intention (and FWIW, I'm not new to C or assert()).
> This use of assert is part of the C language that is well supported and in
> very common use for a long time now, and does what it is suppsoed to do
> very well and reliably. It's the only way to reliably achieve the effect
> libev needs.
Well... it's not an obvious, straight forward usage: it seems to me that
if the "normal usage" of assert was to print a string message along with
the test, assert() would take two arguments or even a format string.
> Putting error messages into a comment would completely defeat the purpose
> of having runtime error messages in the first place, namely telling whats
> wrong at *runtime*, when the comment is long gone.
I don't agree with you here: I think assert is for reporting "bugs in
the code" rather than some problem a user could understand, which is why
it always prints out the file and line number at which it occurred: this
information is mostly only useful to a programmer who has access to the
source code. If they have access to the source and follow the assert
message to where it occurred, they would immediately see a code comment.
That was what I was suggesting.

What I do disagree with, a little, is that assert() is the right way to
generate run-time error messages. Assert is specific, in that it crashes
your code with a core dump and prints out the file and line number: it
"seems" to me to be for that kind of serious problem. If, as a
programmer, you have more information than that and could generate a
better, user friendly, message then I think you should do so via
fprintf() or similar, and follow up with an exit() or abort() only if
> If you are worried about runtime error messages, you can compile with
> -DNDEBUG to get rid of them (and any warnings that might have been
> enabled).
I'm not worried, since I'm not the original poster ;-) I was just trying
to explain your initial answer a bit, as I thought the situation was
more complicated (and therefore interesting).

Again, sorry if I've offended you! I think libev is a great project :-)



This e-mail and any attachments are confidential. If it is not intended for you, please notify the sender, and please erase and ignore the contents.

More information about the libev mailing list