bug#43439: [PATCH] doprnt improvements

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 43439@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 16 Sep 2020 15:09:50 -0700
> 
> On 9/16/20 7:58 AM, Eli Zaretskii wrote:
> 
> > Emacs traditionally supports strings with
> > embedded null characters, and this feature is in line with that.  It
> > is true that it is currently unused, but why is it a good idea to
> > remove it?
> 
> It's a good idea not only because the feature is currently unused and its 
> support complicates and adds bugs to the code, but also because it would be a 
> bad idea to ever use the feature.
> 
> The Emacs feature is for Lisp strings. Emacs does not (and for API reasons, it 
> cannot practically) rely on embedded NULs in C strings. Among other things, if 
> we tried to use C-style printf formats with embedded NULs, GCC's warnings about 
> formats not matching their arguments would stop working. These GCC warnings are 
> quite useful for preventing bugs in Emacs's C code and have helped to catch many 
> such bugs, and we should not give them up.

How about a compromise: we modify doprint to exit when either it finds
NUL or reaches the character specified by FORMAT_END?  This will allow
us to keep some of the feature, and I think the amount of changes will
be smaller.  It should also not be much slower than what you propose.

> More generally, the vestigial support for NULs and %S in doprnt's C formats 
> dates back to long ago, before GCC warned about these features.

I understand your desire to have GCC warnings about this, but GCC is a
tool, it shouldn't dictate what features we keep and which ones we
drop.  We should do it the other way around.  doprnt callers don't
change much, so the GCC diagnostic features are not very important in
this case.

Thanks.