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

Colin McCabe cmccabe at alumni.cmu.edu
Sun Nov 25 03:50:53 CET 2012

On Tue, Nov 20, 2012 at 2:17 PM, Sam Bobroff <sbobroff at shoretel.com> wrote:
> On 20/11/12 21:34, Marc Lehmann wrote:
>> On Tue, Nov 20, 2012 at 02:54:50AM +0000, Sam Bobroff <sbobroff at shoretel.com> wrote:
>>> Sorry if you felt that I'd disrespected your code, that wasn't my
>> A hack is something that happens to work, but is not well done.
>>>> 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
>> Very little in C is obvious and straight forward. It shouldn't be
>> surprising that certain, even standard, idioms are not straightforward.
>>> 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.
>> Judging things by what they seem, but aren't, doesn't lead anywhere. By your
>> logic, if "normal usage" of file systems would include directories, then C
>> would surely have a mkdir function. But it doesn't have one.
>> And btw., normal usage of assert is *always* to print a string message if
>> the test fails. It's defined to do just that. If this isn't normal suage,
>> what is?
>>>> 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"
>> So you think assert is not for reporting runtime errors? Well, thats the only
>> thing assert can do, because it evaluates the test at runtime only.
>> It cannot report bugs in the code in any other way than by runtime error
>> messages.
>>> 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.
>> A lot of asserts in libev, if they trigger, are mainly useful for me,
>> and I don't generally have access to the sourcecode. It is much more
>> informative to have human readable messages, and usually leads to much
>> better feedback and understanding.
>> Other asserts in libev indicate bugs in the caller code, and for these,
>> human readable error messages are a must, at least by my standards.
>> Your idea seems to be that all sourcecode is written by a single
>> person. This is hardly the case in the real world. Human-readable error
>> messages are a vast improvement over forcing people to read source code
>> they might not even have access to (e.g. when libev wasn't compiled by
>> them).
>>> 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.
>> And if not, the error message is useless. Great improvement indeed.
>>> What I do disagree with, a little, is that assert() is the right way to
>>> generate run-time error messages.
>> Since that is the only thing it can do (creating run-time error messages),
>> that means you think assert is not the right way to do anything, i.e. it
>> is a useless function.
>> This is clearly a minority opinion that needs strong evidence.
>>> Assert is specific, in that it crashes your code with a core dump and
>>> prints out the file and line number:
>> C doesn't know anything about core dumps, and assert does not generally
>> cause a core dump.
>>> 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
>>> appropriate.
>> fprintf has an obvious disadvantage: it cause quote noticable code bloat
>> for a relatively rarely used feature and it pulls in the whole of stdio,
>> which is an enourmous cost on amyn smaller systems.
>> The only disadvantage of assert is that you don't like it without being able
>> to explain why.
>> assert wins trivially.
> As you seem to already know everything, this conversation really can't
> go anywhere.
> Goodbye, and again best of luck with libev.
> Sam.

Hi Sam,

You have to look at it from Marc's point of view.  From his point of
view, having the assert compiled in to the program all of the time is
a big advantage.  There are a lot of questions on this list that
clearly relate to misuse of the libev APIs.  If the library fails
silently with no error message, how can anyone start debugging those?
Asking people to recompile the library to get debugging is not
reasonable in my opinion.  Most people just take the version of libev
that their Linux distribution (or ports program, or whatever)
provides-- few of them know how to recompile or care to do so.

I do think it would make sense to replace that:
assert("foo was 0", foo) ;
assert("foo was 0" && foo);

The latter doesn't produce any gcc warnings for me, whereas the former
does.  But at the end of the day, that's up to the maintainer... he's
the one who has to sift through the compilation warnings.


> ________________________________
> 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.
> _______________________________________________
> libev mailing list
> libev at lists.schmorp.de
> http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev

More information about the libev mailing list