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.