bug#9412: sprintf-related integer and memory overflow issues

[Chong Yidong <cyd@stupidchicken.com>]

Paul Eggert <eggert@cs.ucla.edu> writes:

> In code that is formatting buffers or strings that might be longer
> than 2 GiB, we cannot use sprintf etc.  We need to fix these issues
> somehow.  If there's a better way than esprintf etc. please let me
> know.
>
> Anyway, I don't quite follow why using esprintf etc. makes the calling
> code much less clear.  esprintf is like sprintf, except that on 64-bit
> hosts esprintf doesn't have sprintf's 2 GiB limit.  If the use of
> esprintf is unclear, then surely the use of sprintf is just as
> unclear.

sprintf (and snprintf) is a well-known function; when someone comes
across it in the code, it's not necessary to look it up to know what
it's doing.

But I'm not clear on this issue of sprintf etc being restricted to 2GB.
Could you explain further?  Surely such a limitation is a bug in the C
library, not Emacs?  If so, it should be fixed there, not in Emacs.

> Although that used to be true, I expect that platforms lacking
> snprintf (e.g., Solaris 2.5.1, IRIX 5.3, OSF/1 4.0) are no longer of
> practical importance as Emacs porting targets.
>
> That being said, it's easy to allay this concern, by using esnprintf
> instead of snprintf in all areas of the code that might run on ancient
> platforms.  The following further patch does this.

I think we should add a stub for snprintf in sysdep.c for the
!HAVE_SNPRINTF case (which will need configure to set up HAVE_SNPRINTF).