Date: Thu, 27 Jun 2013 11:34:29 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Use of size_t and ssize_t in mseek 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
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.