From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3470 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Use of size_t and ssize_t in mseek Date: Thu, 27 Jun 2013 00:23:14 -0400 Message-ID: <20130627042314.GW29800@brightrain.aerifal.cx> References: <51CBB6E1.6080302@nicta.com.au> <20130627041028.GV29800@brightrain.aerifal.cx> <51CBBC8F.5050301@nicta.com.au> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1372307007 27668 80.91.229.3 (27 Jun 2013 04:23:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Jun 2013 04:23:27 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3474-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 27 06:23:29 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 1Us3k0-0001H6-PP for gllmg-musl@plane.gmane.org; Thu, 27 Jun 2013 06:23:28 +0200 Original-Received: (qmail 3853 invoked by uid 550); 27 Jun 2013 04:23:28 -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 3845 invoked from network); 27 Jun 2013 04:23:27 -0000 Content-Disposition: inline In-Reply-To: <51CBBC8F.5050301@nicta.com.au> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3470 Archived-At: On Thu, Jun 27, 2013 at 02:16:15PM +1000, Matthew Fernandez wrote: > Perfectly reasonable to make it UB (and I had assumed it was so > already). Well the UB is just passing a wrong size. But the only way you can guarantee that such a huge size is "wrong" is by cutting off all ways of making such a large object. > It just seemed to me that it would be more user-friendly to > bounds check the size parameter in fmemopen. Is there a reason not to do > this? Mainly just consistency. There are a lot of places where sizes greater than PTRDIFF_MAX would be problematic due to overflowing differences and other issues, it's difficult (and ugly) to try to catch them all, and even if you do catch them, in some cases, there's no obvious "correct" course of action to take. fmemopen could check and return some reasonable error, but I still want to find and fix any remaining places where objects larger than PTRDIFF_MAX could come into existence since they affect other code too, and once those are fixed, the check in fmemopen would be obsolete. As far as I can tell, mmap and maybe shmat are the only functions that might be able to make such large objects. Do you know any others? Rich