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
Attachment:
signature.asc
Description: Digital signature