[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51CCE81F.4000403@nicta.com.au>
Date: Fri, 28 Jun 2013 11:34:23 +1000
From: Matthew Fernandez <matthew.fernandez@...ta.com.au>
To: <musl@...ts.openwall.com>
CC: Rich Felker <dalias@...ifal.cx>
Subject: Re: Use of size_t and ssize_t in mseek
On 28/06/13 11:22, Rich Felker wrote:
> 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.
I suppose this is an option, but this just isolates the problem to
64-bit systems. On x86_64 I would still be able to naïvely call fmemopen
with SIZE_MAX and end up being unable to fseek. Not being able to
physically have an object of that size seems reasonable justification
for making it undefined behaviour, but not justification for eliding
checks. Regardless of the maximum size of a valid object, nothing stops
me casting UINT_MAX to a size_t. I completely agree that one should not
expect sensible behaviour when claiming to have an object that covers
all of memory, but I don't see the harm in warning the user early by
failing in fmemopen.
> 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.
I would also be happy with this solution. The code in mseek could
definitely be clearer. Not that I don't enjoy switch statements written
as offsets into stack structs and reverse jumps ;)
________________________________
The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.
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.
