Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51CEE341.9000409@nicta.com.au>
Date: Sat, 29 Jun 2013 23:38:09 +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 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?

________________________________

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.