best way to deal with macOS deprecation of sprintf?

[Paul Eggert]

As noted in <https://bugs.gnu.org/58966>, macOS 13.0 has deprecated 
sprintf, on the grounds that buffer overflow happens too often with it. 
As a result, compilers will complain about any calls to sprintf, even if 
you don't configure with --enable-gcc-warnings. I assume vsprintf is 
similar.

This macOS change runs afoul of common practice in Gnulib and Gnu 
programs, which is to allocate a buffer of appropriate size and then 
sprintf into it.

Here are some ways we can respond to Apple's deprecation of sprintf.

0. Do nothing. That's what we did when Microsoft deprecated sprintf in 
2005 (in favor of sprintf_s), and the world rolled along much as it did 
before.

1. Stop using sprintf in Gnulib and Gnu apps. I'm not inclined to do 
this, as it's makework and is likely to introduce bugs; plus, it's a tad 
slower.

2a. Add a Gnulib module sprintf-pacify that puts a "#pragma GCC 
diagnostic ignored "-Wdeprecated-declarations"' in Gnulib's stdio.h if 
that pacifies a false alarm about sprintf. Have sprintf-posix depend on 
this new module. Something like this in gnulib/lib/stdio.h, perhaps:

  #if @PACIFY_SPRINTF_DEPRECATION@
  # pragma GCC diagnostic push
  # pragma GCC diagnostic ignored "-Wdeprecated-declarations"
  int
  gl_vsprintf (char *restrict str, char const *restrict fmt, va_list ap)
  {
    return vsprintf (str, fmt, ap);
  }
  int
  gl_sprintf (char *restrict str, char const *restrict fmt, ...)
  {
    va_list ap;
    va_start (ap, format);
    int n = vsprintf (str, format, ap);
    va_end (ap);
    return n;
  }
  # pragma GCC diagnostic pop
  # define sprintf gl_sprintf
  # define vsprintf gl_vsprintf
  #endif

2b. Like (2a), but simply put -Wno-deprecated-declarations in CFLAGS 
instead of into gnulib's lib/stdio.h.

3. Don't bother with a new module; simply add the functionality to the 
existing sprintf-posix module.

I'm somewhat inclined to go with (2a), as GNU Emacs doesn't use 
sprintf-posix and presumably doesn't want its complexity, whereas it 
could use sprintf-pacify instead of the homebrew (2b)-like solution 
recently installed there. A downside of (2b) is that 
-Wno-deprecated-declarations would apply to all code compiled on macOS, 
not just calls to sprintf and vsprintf; however, (2b) is simpler and 
less likely to go wrong.

Comments?