From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3252 Path: news.gmane.org!not-for-mail From: idunham@lavabit.com Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Mon, 29 Apr 2013 18:53:24 -0700 Message-ID: <20130430015324.GA2470@Caracal> References: <1367214709.30217.YahooMailClassic@web160406.mail.bf1.yahoo.com> <517EA211.1060703@barfooze.de> <1367266482.18069.188@driftwood> <20130429205337.GA20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367286819 29463 80.91.229.3 (30 Apr 2013 01:53:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Apr 2013 01:53:39 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3256-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 30 03:53:40 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UWzlE-00029g-40 for gllmg-musl@plane.gmane.org; Tue, 30 Apr 2013 03:53:40 +0200 Original-Received: (qmail 20027 invoked by uid 550); 30 Apr 2013 01:53:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20019 invoked from network); 30 Apr 2013 01:53:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=D6CGDLdBdmzJHmpqs9AGhln0hVE58N2Lt6YeZf7ERIKcA0pLKFVc2PJTn2kqIy4V5TUaCGcN/1lOWCU60cz+4qriSzYl2d2OSjRkbhC66/9AJsgiURtNAM9F4jmgcBJyDGf6LkxhGpYYSuurwXhj5jiVkm4aCEp/2tp1lx2rYwg=; h=Date:From:To:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent; Content-Disposition: inline In-Reply-To: <20130429205337.GA20323@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3252 Archived-At: 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 > > 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