Re: [PATCH v1 0/3] Add ENDOF(), and use it to fix off-by-one bugs

[Alejandro Colomar]

Hi Kees,

On Thu, Sep 25, 2025 at 08:37:49PM -0700, Kees Cook wrote:
> On Thu, Sep 25, 2025 at 07:36:13PM -0700, Linus Torvalds wrote:
> > The thing is, the "start+len" model is actually *safer* than the
> > "start+len-1" model.
> 
> Sure. But start + len is a vector: "start" is a pointer, and "len" is a
> size. No problems at all.
> 
> > Obviously you cannot dereference a zero-sized object, but zero-sized
> > objects aren't "wrong" per se.
> 
> Right, totally agreed. I'm a big fan of zero-sized objects which are
> useful in all kinds of situations (e.g. empty flexible arrays). And
> as you're saying, a zero-sized object shares the same representation:
> start + len where len is 0.
> 
> What I dislike is having this vector collapsed into a pointer because
> it loses its explicit start/len information, and becomes ambiguous. And
> worse we have nothing that says "this pointer isn't safe to dereference".

The word END should be understood as "this isn't safe to dereference".

I'm not inventing anything new; it's something standard in a way, as
C++'s std::end is precisely that (and no, I don't like C++, but this
name is quite consistent everywhere, including the kernel itself).

> All the bounds safety work we've been doing lately is mostly centered
> around finding ways to retain the "len" part of dynamically sized object
> pointers so we can reconstruct the vector unambiguously.

END is useful in cases where you don't care about the begining.  It's
useful as a way to know where an array ends, regardless of how much
we've advanced in its contents.


Have a lovely day!
Alex

P.S.:  Please let me know if this patch set is suitable for applying, or
if I need to provide a better cover letter, or if I need to do anything
else.

> 
> Anyway, yay for vectors. :)
> 
> -Kees
> 
> -- 
> Kees Cook

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

Attachment: signature.asc
Description: PGP signature