bug#58966: [Trunk] Xcode 14.1+ (and macOS 13.0+) deprecate sprintf()

[Richard Stallman <rms@gnu.org>]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > While we're on the topic: sprintf and snprintf both have serious design 
  > flaws, in that they cannot generate output longer than INT_MAX bytes, 
  > and this contradicts the GNU design philosophy to avoid arbitrary 
  > limits.

I principle, yes.  But most of the calls to sprintf I saw seem to
generate output that is very limited in size, so there is no danger
of buffer overflow in practice.

  >  > We could switch to snprintf, and define snprintf to call sprintf
  >  > in systems where snprintf isn't available.

  > That wouldn't that easy to do,

What is hard about it?

  > > It is possible to verify
  > > that sprintf did not overwrite the buffer.

  > Sorry, I don't know what this comment is trying to say.

Sorry if that was too terse.

If we define snpritf to call sprintf on some platforms, as I suggested
as a fallback, that definition can check the return value of sprintf
to make sure that sprintf did not overflow the output buffer that
snprintf was given.  It can call fatal if that overflow occurs.

  > In my experience, with a debugging runtime sprintf is better than 
  > snprintf, as sprintf reliably reports bugs

What is a "debugging runtime"?

sprintf can't try to detect overflow of the output buffer, because
nothing tells sprintf how big the buffer is.



-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)