[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130628012209.GD29800@brightrain.aerifal.cx>
Date: Thu, 27 Jun 2013 21:22:09 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Use of size_t and ssize_t in mseek
On Fri, Jun 28, 2013 at 10:49:41AM +1000, Matthew Fernandez wrote:
> >As a user of musl, what's your take on this?
>
> A check in fmemopen (and other affected functions) would be my preferred
> solution, as an unwitting user like myself who doesn't check all the
> assumptions would still be caught out by just documenting it as
> undefined. I would be happy with just an assert-fail here if that's easiest..
The easiest might just be making fmemopen so it doesn't care if the
size is insanely large. As far as I can tell, the only place it's an
issue is in mseek, and we could use off_t instead of ssize_t. On
32-bit systems, off_t is 64-bit, so all sizes fit. On 64-bit systems,
there's no way (physically!) to have an object as large as 1UL<<63.
Alternatively, I could adjust the arithmetic to just avoid working
with signed values, and perhaps make it more obvious what it's doing
in the process.
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.
