<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 29, 2016 at 6:18 AM, Alexander Cherepanov <span dir="ltr"><<a href="mailto:ch3root@openwall.com" target="_blank">ch3root@openwall.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>On 2016-05-20 19:58, David Majnemer via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
I've come across this issue before and came to the following conclusion:<br>
- We are not obligated to support objects that large, C11 <a href="http://5.2.4.1/1" rel="noreferrer" target="_blank">5.2.4.1/1</a> only<br>
requires that we support objects of size 65535!<br>
</blockquote>
<br></span>
Right, the standard doesn't require it. But I guess you don't imply that it's fine for clang to silently miscompile any program that works with objects larger than 65535 bytes.</blockquote><div><br></div><div>I think that we should error when we can statically determine that an object is larger than PTRDIFF_MAX.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Their guidance for maximum<br>
object size is stated to be half of SIZE_MAX in C11 K.3.4/4 which is<br>
typically equivalent to PTRDIFF_MAX.<br>
</blockquote>
<br></span>
Whose guidance? Annex K is kinda alien to the rest of the standard and its future is not clear. See, e.g., <a href="http://open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm" rel="noreferrer" target="_blank">http://open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm</a> .</blockquote><div><br></div><div>That document objects to much of Annex K but doesn't say anything about K.3.4/4.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- The expectation that PTRDIFF_MAX is more or less a proxy for the largest<br>
object size is not uncommon. For example, C++'s std::count doesn't return<br>
a size_t but a iterator_traits<>::difference_type which is going to be a<br>
ptrdiff_t for things like std::vector.<br>
</blockquote>
<br></span>
Bug in C++? Because max_size() of std::vector<char> has the type `size_type` and returns SIZE_MAX in practice (even on x86-64).<br></blockquote><div><br></div><div>Some folks in the C++ community believe that using unsigned types in those places was the wrong decision.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Let's see other examples (on x86-32):<br>
<br>
- glibc's malloc is happy to allocate more than PTRDIFF_MAX bytes (and this is important in practice so (at least some) glibc devs are reluctant to "fix" it);<br></blockquote><div><br></div><div>glibc is not the only game in town.</div><div>Android prevents it: <a href="https://android-review.googlesource.com/#/c/170800/" target="_blank">https://android-review.googlesource.com/#/c/170800/</a></div><div>jemalloc prevents it: <a href="https://github.com/jemalloc/jemalloc/commit/0c516a00c4cb28cff55ce0995f756b5aae074c9e" target="_blank">https://github.com/jemalloc/jemalloc/commit/0c516a00c4cb28cff55ce0995f756b5aae074c9e</a></div><div><br></div><div>There are other implementations of malloc which also act similarly.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
- clang has a compile-time limit for sizes of objects and types which is SIZE_MAX. For example, it compiles "char a[-1ul]; int main() {}" but complains about "char a[-1ul + 1ull]; int main() {}";<br>
<br>
- `new` for more than PTRDIFF_MAX works fine when compiled by clang++ (but throws std::bad_array_new_length when compiled by g++).<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
On Fri, May 20, 2016 at 1:31 AM, John Regehr via llvm-dev <<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
It could be that 32-bit systems are disappearing so rapidly that nobody<br>
cares too much about this issue,<br>
</blockquote></blockquote>
<br></span>
Please note that there is a whole new 32-bit architecture -- x32.<div><div><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
but this blog post is still worth reading:<br>
<br>
<a href="http://trust-in-soft.com/objects-larger-than-ptrdiff_max-bytes/" rel="noreferrer" target="_blank">http://trust-in-soft.com/objects-larger-than-ptrdiff_max-bytes/</a><br>
</blockquote></blockquote>
<br></div></div><span><font color="#888888">
-- <br>
Alexander Cherepanov<br>
</font></span></blockquote></div><br></div></div>