You are correct. If I build with -DNDEBUG=1, then the assert is completely ignored: no error message, and no abort. That is not what I want. Therefore I will not build with -DNDEBUG=1.
I will certainly not introduce "logging to a file" as a concept inside buf.c. There is no need for the pure data manipulation code in buf.c to know anything about files or stdio, or a specific name of a log file.
If the assert from assert.h does not do what I want, then I'll make a version that does. However, that is a moot point, since right now it does what I want.
No it's a good point actually, and it pays to know your context. Frankly, looking at the 118 lines in assert.h, it does considerably more than I really need.
Instead of this:
assert(buf->pos < buf->str->len);
I could just do this instead:
if (buf->pos >= buf->str->len) die("bad pos");
If the die message is unique, I don't really need to include __FILE__, __LINE__, and the expression itself in it.
I could even do this, though it's probably overkill for something that should never happen anyway:
if (buf->pos >= buf->str->len)
die("bad pos %d %d", buf->pos, buf->str->len);
Absolutely, though I tend to throw __FILE__ and __LINE__ in everything, so I can step through the sources of messages by just pulling messages into my vim quickfix buffer. Again, totally depends on context, though.
Comments
Right now, in my code, assert(0==1) produces this output to stderr:
That is what I want.You are correct. If I build with -DNDEBUG=1, then the assert is completely ignored: no error message, and no abort. That is not what I want. Therefore I will not build with -DNDEBUG=1.
I will certainly not introduce "logging to a file" as a concept inside buf.c. There is no need for the pure data manipulation code in buf.c to know anything about files or stdio, or a specific name of a log file.
If the assert from assert.h does not do what I want, then I'll make a version that does. However, that is a moot point, since right now it does what I want.
I had no objection to the approach, just the lack of a note about assumptions it relied upon.
No it's a good point actually, and it pays to know your context. Frankly, looking at the 118 lines in assert.h, it does considerably more than I really need.
Instead of this:
I could just do this instead: If the die message is unique, I don't really need to include __FILE__, __LINE__, and the expression itself in it.I could even do this, though it's probably overkill for something that should never happen anyway:
Absolutely, though I tend to throw __FILE__ and __LINE__ in everything, so I can step through the sources of messages by just pulling messages into my vim quickfix buffer. Again, totally depends on context, though.