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

[Ben Hutchings]

On Mon, 2021-12-27 at 01:50 +0000, Thorsten Glaser wrote:
> Ben Hutchings (@benh) dixit:
> 
> > Further, it's not legal for a C object to be larger than
> > PTRDIFF_MAX (half of SIZE_MAX) as pointer arithmetic within it
> > could
> > overflow.  So return failure immediately if size is greater than
> > that.
> 
> Not exactly. The problem is >PTRDIFF_MAX *elements* but an element
> isn’t necessarily byte-sized, so you _can_ have an unsigned short
> object that’s larger than half SIZE_MAX byhtes but ≤PTRDIFF_MAX
> elements so pointer arithmetics will still work.
> 
> Unsure if it’s a good idea in general to restrict allocation like
> this. It probably is for klibc, admittedly. But this got me
> wondering.
> 
> Please do correct me, should I be wrong above.

Looking at C99 (I don't have a newer version to hand), there doesn't
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.  I must have
misremembered the rule.

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.

Ben.


-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zytor.com/archives/klibc/attachments/20211227/3cf47ed4/attachment.sig>