C study buddy?

Joe Nelson joe at begriffs.com
Tue Nov 20 05:56:26 UTC 2018

Robbie Herb wrote:
> Oh my, this is one of the most interesting ideas I've ever heard. ...
> I definitely want to see where it goes.

Here's what I've learned so far:

* The idea of "benign" macro redefinition and un-definition.
* <assert.h> is designed to work when included multiple times in a
  single file.  Doing so with our without NDEBUG defined changes the
  behavior of the assert() macro.
* My first thought of using an if statement in the macro is no good
  because it needs to evaluate to a void expression so that it asserts can
  be made anywhere in the code.
* Macros in standard library header files are not allowed to call
  functions from other headers. The headers themselves may not include
  each other.
* There's a trick to adding the line number in a string built entirely
  within the macro.
* <ctype.h> makes macro overrides of its functions. This way the
  programmer can get the speed of a macro but have access to a function
  if needed for function pointers.
* If foo is a function and covered up with a macro of the same name,
  you can still get at the function by enclosing it in parens (foo)(x).
* ctype's implementation must make non-portable assumptions in its
  lookup tables for a particular platform, but the #error directive
  allows you to break the compilation if expectations are violated.
* Cool trick of offsetting the lookup table pointer by one on an
  underlying array so that -1 (EOF) can be looked up too.
* Looping over a raw string literal is fine, it just gets stored
  in the data segment of the program. Pretty convenient.

I would love someone to work on this with me. The exercises would be
more fun that way. It's a pretty great book, I think even you C pros
like Sam and Ioannis might get something out of it.

Also, anyone know how to improve the Makefile while still keeping within
the fully portable subset of make commands? It seems redundant in
places. https://github.com/begriffs/libc/blob/master/Makefile Also the
libc.a file will get rebuilt if any object file changes (which is good),
which will cause *all* the test binaries to become out of date (which
may be bad). My BSD make doesn't support the "library.a(object.o)"
construction with the parens to indicate a target's reliance on just one
part of a library archive.

More information about the Friends mailing list