[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130430015324.GA2470@Caracal>
Date: Mon, 29 Apr 2013 18:53:24 -0700
From: idunham@...abit.com
To: musl@...ts.openwall.com
Subject: Re: High-priority library replacements?
On Mon, Apr 29, 2013 at 04:53:37PM -0400, Rich Felker wrote:
> On Mon, Apr 29, 2013 at 03:14:42PM -0500, Rob Landley wrote:
> > On 04/29/2013 11:38:41 AM, John Spencer wrote:
> > >On 04/29/2013 07:51 AM, Brad Conroy wrote:
> > >>I have been keeping track of unbloated alternative resources
> > >>with permissive licenses here:
> > >>http://www.murga-linux.com/puppy/viewtopic.php?t=72359
> > >>
> > >>Here is a summary in no particular order:
> > >>Imaging ... stb_image (nothings.org) or nanojpeg+lodepng+webp
> > >>stb_image supports png and gif (+many others) and thus has lzo
> > >>and zlib
> > >>Lua ... stua (nothings.org)
> > >>Ogg ... stb_vorbis
The stb_* stuff appears to be intended solely for demos.
Replacing lua is pointless; lua is already nice and small.
I'd go for pnglite above lodepng--lodepng wants to be C++ and is much
longer; pnglite is actually packaged in most distros (IIRC, something
KDE-related uses it).
> > >
> > >i would be careful with stb_ things since the author makes
> > >statements such as:
> > >"Warning: gcc strict-aliasing optimization breaks this, which is
> > >too bad, because
<snip>
>
> The one being stupid is the person who's writing code that's invalid C
> and always has been invalid C. The fact that C has a tradition of
> being treated as a crap language where you can pass off whatever
> invalid hacks you want as code and ship it and get someone to pay you
> money for that junk is not an excuse to continue doing so. Rather it's
> the reason C got a bad reputation (for code that wasn't even C but
> nonsense posing as C!) and now we're stuck dealing with core system
> components written in Python and Perl, web apps written in PHP and
> JavaScript, and GUI behemoths written in Java and C++.
>
> 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.
--
Isaac Dunham
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
