On Thu, Nov 3, 2022 at 3:23 PM Paul Eggert <egg...@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
