[klibc] large C objects (was Re: [Git][kernel-team/klibc][master] 45 commits: 2.0.8 released, next version is 2.0.9)

[Thorsten Glaser]

Ben Hutchings dixit:

>But the whole purpose of this series was to replace the undefined
>behaviour of too-large allocations with a safe failure mode, and it
>might be necessary to do pointer arithmetic on an array of any element
>type with byte pointers.  For example, if a program reads in an array
>of ints, and then passes it to a general-purpose checksum function that
>works on bytes.

OK, this makes sense; thanks!

.NET does the same, by the way.

>Looking at C99 (I don't have a newer version to hand), there doesn't

Same one I once bought.

>even seem to be a requirement that arrays are restricted to PTRDIFF_MAX
>elements.  It's simply undefined behaviour if pointer arithmetic
>results in a value outside the range of ptrdiff_t.

Ah, yes. Worse, ptrdiff_t could be long long and size_t unsigned int,
so you’d, strictly speaking, have to check both if you do this. C is
a neverending can of surprises… but when you control the environment
you can, of course, exclude this.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.pdf doesn’t seem
to have changed this but recommends against larger-than-long for both.
There is now this though:

| For those reasons, it is sometimes beneficial to restrict the range of
| object sizes to detect programming errors. For implementations
| targeting machines with large address spaces, it is recommended that
| RSIZE_MAX be defined as the smaller of the size of the largest object
| supported or (SIZE_MAX >> 1), even if this limit is smaller than the
| size of some legitimate, but very large, objects. Implementations
| targeting machines with small address spaces may wish to define
| RSIZE_MAX as SIZE_MAX, which means that there is no object size that
| is considered a runtime-constraint violation.

This indicates that such large objects are, strictly speaking, valid.

OTOH, I don’t see throwing ENOMEM if some amount of memory isn’t
available as contiguous block as problem either so using this as
rationale-of-sorts for this security feature shouldn’t harm even
from a standards PoV.

bye,
//mirabilos
-- 
<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design.  <mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)