On Tue, Nov 20, 2012 at 02:54:50AM +0000, Sam Bobroff <sbobr...@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.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
