undefined | Better HN

0 pointsfexl12y ago0 comments

Right now, in my code, assert(0==1) produces this output to stderr:

  run: run.c:422: main: Assertion `0==1' failed.
  Aborted

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.

0 comments

3 comments · 1 top-level

dllthomas12y ago· 2 in thread

I had no objection to the approach, just the lack of a note about assumptions it relied upon.

fexlOP12y ago

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);

dllthomas12y ago

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.

j / k navigate · click thread line to collapse