Disable sprintf deprecation warning

Dear Experts,

Xcode 14 is giving me a new deprecation warning about sprintf.

I understand why this is here (*) but I need to suppress it in some cases. I don't want to disable it everywhere (or lose other deprecation warnings).

Specifically, I #include some Boost headers which use it in inline functions. I know that I can use #pragma to disable it, but I don't want to modify the Boost headers. Adding #pragma everywhere that I #include a Boost header is also unappealing.

What other options do I have?

(*) I'm not enthusiastic about the suggesting in the warning to use snprintf instead; snprintf leaves the destination unterminated on overflow, which can be just as bad as the sprintf behaviour.

If you really want to suppress the warning, you can disable -Wdeprecated-declarations (perhaps via -Wno-deptecated-declarations) everywhere you might see a use of sprintf. If you want to be surgical about disabling the warning, you can #pragma clang diagnostic around each use.

The best option, of course, is not to suppress but to transition away from an interface that’s so easy to misuse. You can migrate the uses of sprintf to something else, such as snprintf.

snprintf does guarantee NUL-termination, so I think your lack of enthusiasm for it as a replacement is misplaced.

I agree, this really doesn't seem to a great situation. Using malloc, free, sprintf, etc are unsafe. But they are still part of POSIX, ISO C, ISO C++

It can be a good idea mark some of these with some kind of attribute, some kind of warning.

std::strstream is deprecated in C++98

std::is_literal_type is deprecated in C++17 and removed in C++20

gets is deprecated in C99 and removed C11

I checked, sprintf is not deprecated in any standard. We want to use the -Wdeprecated-declarations warning, it does help with (mainly future) portability. sprintf being unsafe has nothing to do with this. The whole C programming language is "an interface that’s so easy to misuse", but that is besides the point. Is Apple going to remove sprintf in a future release, and deny compiling C99 code?

If not, why add __attribute__((__deprecated__)) to sprintf?

snprintf does guarantee NUL-termination,

Oh, does it? That’s very interesting. You are correct - it is strncpy() that does not null-terminate if the source length is greater than N.

I guess I have not tried to memorise the subtle variations of behaviour of all of these functions, and just pessimistically assume the worst….

Disable sprintf deprecation warning
 
 
Q