Thou shalt have no other gods before the ANSI C standard 1592

Brian Inglis

I took a brief look at it, and my initial reaction is that it looks like it misses opportunities to do a better job. I would have a hard time endorsing this as a very strong candidate for the right library. If this library were accepted, I would continue to advocate throwing it away and building your own, or rolling your own on top of this. It will be unfortunate if this opportunity is missed.

For instance, it continues to separate the pointer to the buffer from the size of the buffer, so the programmer has to make sure to always pbutt those together and update them together. I think that is a mistake, and I think they would be doing better if they used some idea along the lines of what Gwyn and I have proposed earlier on this thread: something like invariant: buf.contents points to an object with buf.size bytes avail struct buf { char *contents; sizet size; }; struct buf mkbuf(sizet s) { struct buf b; b.contents = malloc(s); b.size = b.contents ? s : 0; whatever form of error checking is appropriate goes here return b; } etc. The benefit of an opaque type like this is that there is less opportunity for error, and it is less clumsy to pbutt around buffer references. (There are many possible variations on this idea, of course.) This is just one example of how thoughtful interface design can contribute to reducing the likelihood of programming errors.