From: idunham@lavabit.com
To: musl@lists.openwall.com
Subject: Re: High-priority library replacements?
Date: Mon, 29 Apr 2013 18:53:24 -0700 [thread overview]
Message-ID: <20130430015324.GA2470@Caracal> (raw)
In-Reply-To: <20130429205337.GA20323@brightrain.aerifal.cx>
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
next prev parent reply other threads:[~2013-04-30 1:53 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-29 5:51 Brad Conroy
2013-04-29 16:38 ` John Spencer
2013-04-29 20:14 ` Rob Landley
2013-04-29 20:53 ` Rich Felker
2013-04-30 1:53 ` idunham [this message]
2013-04-30 2:21 ` Rich Felker
-- strict thread matches above, loose matches on Subject: below --
2013-04-25 4:15 Rich Felker
2013-04-25 5:05 ` Daniel Cegiełka
2013-04-25 5:21 ` Rich Felker
2013-04-25 5:55 ` Kurt H Maier
2013-04-25 7:34 ` Jens Staal
2013-04-25 12:18 ` Rich Felker
2013-04-25 13:54 ` Kurt H Maier
2013-04-25 6:43 ` Gregor Pintar
2013-04-26 0:55 ` idunham
2013-04-26 1:51 ` Rich Felker
2013-04-26 8:11 ` Gregor Pintar
2013-04-26 15:47 ` Rich Felker
2013-04-26 17:24 ` Gregor Pintar
2013-04-28 21:43 ` Rob Landley
2013-04-29 10:16 ` Szabolcs Nagy
2013-04-29 12:09 ` Rich Felker
2013-04-29 17:35 ` Gregor Pintar
2013-04-29 21:55 ` Szabolcs Nagy
2013-04-30 2:10 ` Rich Felker
2013-04-30 6:32 ` Gregor Pintar
2013-04-30 8:35 ` Szabolcs Nagy
2013-04-30 9:58 ` Gregor Pintar
2013-04-30 11:30 ` Szabolcs Nagy
2013-04-30 14:11 ` Gregor Pintar
2013-05-01 7:26 ` Gregor Pintar
2013-05-08 21:37 ` Daniel Cegiełka
2013-05-08 23:00 ` idunham
2013-05-09 7:36 ` Daniel Cegiełka
2013-05-09 9:03 ` Daniel Cegiełka
2013-05-09 11:10 ` LM
2013-05-09 14:08 ` Rich Felker
2013-05-09 14:40 ` Daniel Cegiełka
2013-05-09 14:45 ` Rich Felker
2013-05-12 22:42 ` Brad Conroy
2013-05-15 20:17 ` Rich Felker
2013-05-16 16:12 ` Justin Cormack
2013-05-17 1:56 ` Rich Felker
2013-05-17 7:28 ` Justin Cormack
2013-05-09 16:40 ` LM
2013-04-30 18:47 ` Nicolas Braud-Santoni
2013-04-30 19:18 ` Gregor Pintar
2013-05-26 20:09 ` Daniel Cegiełka
2013-05-27 15:53 ` Gregor Pintar
2013-05-28 9:27 ` Daniel Cegiełka
2013-05-28 17:30 ` Gregor Pintar
2013-05-28 13:11 ` LM
2013-05-28 21:38 ` Rob Landley
2013-05-31 11:13 ` LM
2013-05-31 11:36 ` LM
2013-04-25 7:21 ` Hal Clark
2013-04-25 10:58 ` Igmar Palsenberg
2013-04-25 12:28 ` Rich Felker
2013-04-25 11:44 ` LM
2013-04-25 12:51 ` Rich Felker
2013-04-25 15:30 ` Jens Staal
2013-04-25 16:51 ` Zvi Gilboa
2013-04-25 16:57 ` Justin Cormack
2013-04-25 17:53 ` Zvi Gilboa
2013-04-27 5:45 ` Rob Landley
2013-04-27 8:13 ` Luca Barbato
2013-04-27 13:05 ` Zvi Gilboa
2013-04-26 6:11 ` Igmar Palsenberg
2013-04-26 4:19 ` Isaac Dunham
2013-04-26 11:41 ` LM
2013-04-26 12:57 ` Muhammad Sumyandityo Noor
2013-04-26 15:53 ` Rich Felker
2013-04-28 6:53 ` Muhammad Sumyandityo Noor
2013-04-28 17:46 ` Rich Felker
2013-04-26 16:52 ` LM
2013-04-26 4:32 ` nwmcsween
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130430015324.GA2470@Caracal \
--to=idunham@lavabit.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).