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

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 bytes 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.

bye,
//mirabilos
-- 
?It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.?
	-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

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>