Re: best way to deal with macOS deprecation of sprintf?

[Jeffrey Walton]

On Thu, Nov 3, 2022 at 3:23 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> 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?

A few small comments, nothing really material.

Apple deprecated sprintf starting at MacOS 10.12.[1] Apple considers
vsprintf insecure, too.[2] Apple considers snprintf a secure
replacement.[2]

Apple's Secure Coding Guide says you can use snprintf or asprintf, if
you wish.[3] (And vsnprintf or vasprintf for vsprintf).

snprintf is kind of a lame for a replacement since it backfills the
buffer with all 0's. But at least their suggested replacement is not
part of Cocoa or other Apple framework.

Jeff

[1] https://developer.apple.com/documentation/kernel/1441083-sprintf
[2] 
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/sprintf.3.html
[3] 
https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Introduction.html