From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3486 Path: news.gmane.org!not-for-mail From: Matthew Fernandez Newsgroups: gmane.linux.lib.musl.general Subject: Re: Use of size_t and ssize_t in mseek Date: Sat, 29 Jun 2013 23:38:09 +1000 Message-ID: <51CEE341.9000409@nicta.com.au> References: <20130627041028.GV29800@brightrain.aerifal.cx> <51CBBC8F.5050301@nicta.com.au> <20130627042314.GW29800@brightrain.aerifal.cx> <51CBC034.7030001@nicta.com.au> <20130627153429.GZ29800@brightrain.aerifal.cx> <51CCDDA5.5050503@nicta.com.au> <20130628012209.GD29800@brightrain.aerifal.cx> <51CCE81F.4000403@nicta.com.au> <20130628014815.GE29800@brightrain.aerifal.cx> <51CCED3F.3080303@nicta.com.au> <20130629041316.GG29800@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1372513114 12861 80.91.229.3 (29 Jun 2013 13:38:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Jun 2013 13:38:34 +0000 (UTC) Cc: Rich Felker To: Original-X-From: musl-return-3490-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 29 15:38:34 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UsvMI-0006JP-KD for gllmg-musl@plane.gmane.org; Sat, 29 Jun 2013 15:38:34 +0200 Original-Received: (qmail 30213 invoked by uid 550); 29 Jun 2013 13:38:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 30193 invoked from network); 29 Jun 2013 13:38:32 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 In-Reply-To: <20130629041316.GG29800@brightrain.aerifal.cx> X-TM-AS-Product-Ver: SMEX-10.2.0.2087-7.000.1014-19982.006 X-TM-AS-Result: No--11.300900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Xref: news.gmane.org gmane.linux.lib.musl.general:3486 Archived-At: 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 pro= fessional privilege and/or copyright. National ICT Australia Limited accept= s no liability for any damage caused by this email or its attachments.