The right answer for a API to draw a line like you describe is to provide every possible way to draw a line since you never know which one the user wants to use. Granularity is one of the general five properties of every good API, of course it is not always good to provide all possible ways since it hurts compactness. The best I have ever heared about API design was a talk from Casey Muratori: http://mollyrocket.com/casey/stream_0028.html

It's not that you want to provide "every possible way to draw a line".. ideally your API provides the primitives necessary for a client to draw lines in all the ways that are useful.

The primitives that you provide relate to the overall goal of your API. Do you want people to use it for mathematical graphing? Will they start with an equation? Or is this for a website, where all you really want is <hr/>.

This way of script like interactive programming in C with dynamic libraries is quite known in game programming. The game code in Quake 2, Quake 3, Doom 3, Half Life and even the rendering module in Quake 2 [0] was written that way. In addition to the obvious advantage of interactive programming, dynamic libraries also served as a great way to abstract over submodules like the render and sound engine and made it possible to have a in runtime switchable opengl- and software-renderer.

[0] http://fabiensanglard.net/quake2/quake2Polymorphism.php

I wrote a JSON-Parser in C with minimal validation in ~250 LOC that does not allocate memory, but leaves the type check and conversion to the user. https://github.com/vurtun/json

It would be nice if the README mentioned it was originally based on my https://github.com/quartzjer/js0n :)

Added your project as a reference. Sorry for the missing reference I originally never planned to make the project known publicly and therefore never added the references.

This is absolutely beautiful. I didn't know you could get an address of a label in C or to do a goto to an address from variable instead of a literal label. Is this new in C, or was it always there?

It's a GCC extension. https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Is there an equivalent for Clang/LLVM?

Yes.

http://blog.llvm.org/2010/01/address-of-label-and-indirect-b...

A venerable interpreter implementation trick.

Unfortunately it won't port to IAR, which is a shame. I don't understand why pointers to labels never made it to the C spec; it's one of the (equivaling) features that actually makes assembler look elegant.

That test.c file looks familiar!

Yeah I was looking for unit test macros and found your project. I added your project as a reference in the README for clarification of the origin.

That's a very nice code.