From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3487 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Use of size_t and ssize_t in mseek Date: Sat, 29 Jun 2013 10:17:36 -0400 Message-ID: <20130629141736.GH29800@brightrain.aerifal.cx> References: <20130627042314.GW29800@brightrain.aerifal.cx> <51CBC034.7030001@nicta.com.au> <20130627153429.GZ29800@brightrain.aerifal.cx> <51CCDDA5.5050503@nicta.com.au> <20130628012209.GD29800@brightrain.aerifal.cx> <51CCE81F.4000403@nicta.com.au> <20130628014815.GE29800@brightrain.aerifal.cx> <51CCED3F.3080303@nicta.com.au> <20130629041316.GG29800@brightrain.aerifal.cx> <51CEE341.9000409@nicta.com.au> 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 1372515470 1996 80.91.229.3 (29 Jun 2013 14:17:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Jun 2013 14:17:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3491-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 29 16:17:52 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 1UsvyI-0003RU-RH for gllmg-musl@plane.gmane.org; Sat, 29 Jun 2013 16:17:50 +0200 Original-Received: (qmail 11977 invoked by uid 550); 29 Jun 2013 14:17:50 -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 11958 invoked from network); 29 Jun 2013 14:17:50 -0000 Content-Disposition: inline In-Reply-To: <51CEE341.9000409@nicta.com.au> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3487 Archived-At: On Sat, Jun 29, 2013 at 11:38:09PM +1000, Matthew Fernandez wrote: > On 29/06/13 14:13, Rich Felker wrote: > >If size_t is 64-bit, there is fundamentally no way a memory buffer (or > >disk file) larger than SSIZE_MAX can be accessed, since off_t cannot > >store the position in the file. I noticed this as soon as I went to > >write: > > > > case SEEK_SET: > > if (off < 0 || off > c->size) goto fail; > > > >I could still salvage the 32-bit case by simply leaving the code alone > >except for changing base to off_t, but I'm starting to remember why I > >thought it was bogus to even consider allowing object sizes greater > >than the signed size max... > > > >Not sure what the best way to proceed is. > > I still don't see the barrier to introducing a check for size greater > than SSIZE_MAX in fmemopen and leaving mseek as is. Am I missing something? Just that this is one of a multitude of places that such a check could be made, and I question the value of doing it in one place but not others. Examples include snprintf, strnlen, memchr, and basically any interface that takes a size_t representing the size of an already existing object. I'm against adding checks to all these places since it adds bloat and potentially hurts performance and for most of them there's nothing they could do except crash if the check failed. So what I'm questioning is the value of adding such a check to the one interface you ran into trouble with, when there are plenty more widely used functions that won't be checked; this inconsistency does not make sense to me. I'd like to hear what others think, though. Rich