From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3478 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: Fri, 28 Jun 2013 11:34:23 +1000 Message-ID: <51CCE81F.4000403@nicta.com.au> References: <51CBB6E1.6080302@nicta.com.au> <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> 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 1372383290 785 80.91.229.3 (28 Jun 2013 01:34:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Jun 2013 01:34:50 +0000 (UTC) Cc: Rich Felker To: Original-X-From: musl-return-3482-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 28 03:34:51 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 1UsNaM-0002S1-75 for gllmg-musl@plane.gmane.org; Fri, 28 Jun 2013 03:34:50 +0200 Original-Received: (qmail 15919 invoked by uid 550); 28 Jun 2013 01:34:48 -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 15911 invoked from network); 28 Jun 2013 01:34:48 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 In-Reply-To: <20130628012209.GD29800@brightrain.aerifal.cx> X-TM-AS-Product-Ver: SMEX-10.2.0.2087-7.000.1014-19980.002 X-TM-AS-Result: No--21.437200-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:3478 Archived-At: 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 easi= est.. > > 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=EFvely 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 pro= fessional privilege and/or copyright. National ICT Australia Limited accept= s no liability for any damage caused by this email or its attachments.