I meant, a pointer can wrap to 0, and if your data has no terminating
\0, the pointer won't stop you either. You have a theoretical infinite
loop.

Yes, I know this is what you meant. I was referring to the bounds
within which you must keep to have defined behaviour.

When I originally asked you to say what the contract was between the
caller and the callee, this was one of the things that you could ave
specified: the code works only on such-and-such type machines. In
effect you did specify that when you said the contract is defined by
what the code does. I.e. you wrote trim for machines where it works

Aside from the ptrdiff_t issue, how can it fail?

It could do all manner of things. For example, it might trim a string
that belongs to another process or thread. It might write it's trimming
null into a memory-mapped register that does almost anything you can
think of.

and, presumably, you don't care about ones where it won't.

Segfaulting is a caller's error, not a defect in trim(). What other
failure scenario is there?

All of the above are caller errors but they make it hard to defend the
idea that the function is bullet-proof or has no undefined behaviour.

Why not save yourself some trouble and define whatever happens when the
pointer "wraps" as a caller error and then you can be done with this?