On 15/06/2021 08.43, Justin He wrote:

Hi Rasmus

quoted

-----Original Message-----
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>

quoted

Why the !buf check? The only way we can have that is the snprintf(NULL,
0, ...) case of asking how much space we'd need to malloc, right? In
which case end would be NULL+0 == NULL, so buf >= end automatically,
regardless of how much have been "printed" before %pD.

My original purpose is to avoid any memory copy/move for kvasprintf->
vsnprintf(NULL, 0,...). But as you said, this can be folded into the case
buf >= end.
Do you think whether following case should be forbidden?:
vsnprintf(NULL, 8,...).

That is an obvious caller bug. The caller tells vsnprintf "here's a
buffer of size 8 at address 0x0". And checking buf for NULL in the guts
of %pD would anyway be completely pointless as it would crash for a fmt of

"x%pD"

or basically anything at all before %pD because those specifiers (or
literal parts) would cause a write to buf - and if that somehow
survived, the buf %pD would be given would now be (void*)1L.

quoted

Now you're passing p to string_truncate or string_nocheck, while p
points somewhere into buf itself. I can't convince myself that would be
safe. At the very least, it deserves a couple of comments.

When code goes here, the buffer space must be as follows:
|.........|.........|
buf       p         end

So string_nocheck is safe because essential it would byte-to-byte copy p to buf.

But I agree comments are needed here.

Yes, because no matter how string_nocheck happens to be implemented
today, some day somebody might throw in a memcpy() or do something else
that means overlapping "buf" and "s" arguments are suddenly broken in
some configurations or arches.

Rasmus