[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130627042314.GW29800@brightrain.aerifal.cx>
Date: Thu, 27 Jun 2013 00:23:14 -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: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
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.
