From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3474 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 11:34:29 -0400 Message-ID: <20130627153429.GZ29800@brightrain.aerifal.cx> 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> 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 1372347291 8837 80.91.229.3 (27 Jun 2013 15:34:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 27 Jun 2013 15:34:51 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3478-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jun 27 17:34:49 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 1UsEDa-0004TU-GQ for gllmg-musl@plane.gmane.org; Thu, 27 Jun 2013 17:34:42 +0200 Original-Received: (qmail 8125 invoked by uid 550); 27 Jun 2013 15:34:41 -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 8117 invoked from network); 27 Jun 2013 15:34:41 -0000 Content-Disposition: inline In-Reply-To: <51CBC034.7030001@nicta.com.au> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3474 Archived-At: On Thu, Jun 27, 2013 at 02:31:48PM +1000, Matthew Fernandez wrote: > On 27/06/13 14:23, Rich Felker wrote: > >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. > > In some sense this is true, but this would not have affected my > scenario. I do not know the size of the object to which I have a pointer > to and the object was not derived from Musl C functionality. As a bit of > context, this is an embedded environment where we don't have much > address space introspection. I suppose you could argue that I should > have re-implemented fmemopen in a way that didn't assume a bounded buffer. Thanks for providing the added context. It helps to understand the situation a lot better. Am I correct in assuming that you're using musl not on Linux, but ported to an underlying embedded environment, possibly without a kernel? The reason I ask is that I don't see how Linux would give you such an object without you requesting it via a syscall of some sort. Anyway, if I'm understanding your usage case correctly, I think we should eventually provide documentation (perhaps in the porting section of the future manual) about using musl like this. And either we should document that it's undefined behavior to pass sizes larger than PTRDIFF_MAX/SSIZE_MAX to functions in musl, or we should make an effort to find all the functions affected by this issue and make them either reject such large sizes, or work safely with them. As a user of musl, what's your take on this? > Yes, I agree with this reasoning. It seems fmemopen should really take a > ssize_t, but this would require deviating from the standard which is > undesirable. There are a lot of functions (read, write, ...) that "should" take ssize_t, in some sense of "should", but that wouldn't really fix the problem either, since large values would just get converted to negative values when passed to the functions. Rich