If "we" want to support additional semantics for sn?printf where the standard says "undefined", we should take care to specify what is going to be promised.
I don't know whether "we" is Debian, or "we" is (e)glibc upstream. I also don't know exactly what is being proposed. Something like When the format string begins with exactly "%s" and the corresponding argument is equal by pointer comparison to the output argument, the behavior is as if that corresponding argument was actually a copy of pointed-to string. [debian / e?glibc extension] ? It's also worth noting that * The current behavior of sprintf depends not only on -D_FORTIFY_SOURCE but also on -O * freebsd snprintf has this appending behavior, but no version of linux I tried did---only the unsafe sprintf. This latter item is an important point: if we are going to make append-style sprintf, we'd better make snprintf do it too, so that when the inevitable "sprintf -> snprintf for security" changes come along in whatever package, we odn't see the same breakage. All that said, I am personally in favor of *not* defining this sn?printf extension and fixing packages where we encounter use of this idiom. Jeff
signature.asc
Description: Digital signature