Date: Sat, 29 Jun 2013 10:17:36 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Use of size_t and ssize_t in mseek 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
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.