[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130627153429.GZ29800@brightrain.aerifal.cx>
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.
