[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

best way to deal with macOS deprecation of sprintf?

From: Paul Eggert
Subject: best way to deal with macOS deprecation of sprintf?
Date: Thu, 3 Nov 2022 12:23:09 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3

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:

  # pragma GCC diagnostic push
  # pragma GCC diagnostic ignored "-Wdeprecated-declarations"
  gl_vsprintf (char *restrict str, char const *restrict fmt, va_list ap)
    return vsprintf (str, fmt, ap);
  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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]