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.