[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
