Re: High-priority library replacements?

[Rich Felker <dalias@aerifal.cx>]

On Mon, Apr 29, 2013 at 06:53:24PM -0700, idunham@lavabit.com wrote:
> > If something is invalid C, you simply don't do it. You especially
> > don't do it in a library you intend for others to be able to use in
> > applications whose requirements and deployments you have no control
> > over. Even if "it works for me" makes YOU happy when running the code
> > on your own system, it's not okay when party B uses your code in their
> > application without being aware that it's based on broken assumptions,
> > and then party C gets to keep both pieces when it breaks.
> 
> As far as I can tell, most of the stb_* stuff is just stuff that was
> written for demos and put on a web server in case someone wanted it.
> 
> And for demos, size is the big restriction; it's not expected to handle
> every use case, or be used in a context where security is an issue--
> in fact, continuing to function properly is not a high priority.
> 
> The flip side of this is that code written for demos is most likely
> unsuitable for use in regular software.

Incidentally, my original vision for the "new platform" thread was for
the UI/graphics interface to be much more akin to what you see in
demos, old games, ancient systems, etc. than modern OO GUI libs, but
actually done right, and with modern features like screen size and
resolution adaptability, proper multilingual text rendering and
editing, vector graphics, etc.

If such a project is ever to progress, I think a good starting point
may be to research the good and the bad of historical practices.
Applying the principles of "library-safe code" (as yet not rigorously
defined), avoiding global state, realtime considerations, etc. could
serve to quickly filter out the faults of old school designs.

Rich