On 20/11/12 21:34, Marc Lehmann wrote: > On Tue, Nov 20, 2012 at 02:54:50AM +0000, Sam Bobroff <[email protected]> > 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. ________________________________ 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 [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
