News for hackers. Stuff that matters.
Re:Deconstructing "K&R C" by CJefferson on Tuesday January 10, 2012 @05:12PM (#3449334)
Why do you think the compiler with optimizations will remove the assertion?

The compiler will realise that:

    assert(assert(line != NULL && longest != NULL && "memory error");
Is equivalent to:

    assert(line != NULL && longest != NULL);
But there doesn't seem anything wrong with that.
Re:Deconstructing "K&R C" by tptacek on Tuesday January 10, 2012 @05:26PM (#3449409)
Production code is supposed to define away the assertions. It is an actual error to manage important program state with asserts.

(That doesn't make these particular asserts an error).

Re:Deconstructing "K&R C" by zedshaw on Wednesday January 11, 2012 @12:28AM (#3450572)
In the earlier chapters they setup a Makefile with full debugging on so these don't get removed. It's mostly just for this one exercise, and in the rest of the book they use a set of debug macros I wrote:

http://c.learncodethehardway.org/book/learn-c-the-hard-waych...

Re:Deconstructing "K&R C" by scott_s on Tuesday January 10, 2012 @06:31PM (#3449650)
In support of tptacek's comment, an abbreviate version of what's in assert.h on my OSX system:

  #ifdef NDEBUG
  #define assert(e)   ((void)0)
  #else

  #define assert(e)  \
    ((void) ((e) ? 0 : __assert (#e, __FILE__, __LINE__)))
  #define __assert(e, file, line) \
    ((void)printf ("%s:%u: failed assertion `%s'\n", file, line, e), abort())
So, if NDEBUG ("no debug") is defined, which it is if optimizations are turned on, asserts become a no-op.