GNU bug report logs - #9412
sprintf-related integer and memory overflow issues

Previous Next

Full log

View this message in rfc822 format

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 9412 <at> debbugs.gnu.org
Subject: bug#9412: sprintf-related integer and memory overflow issues
Date: Wed, 31 Aug 2011 12:14:13 -0400

Paul Eggert <eggert <at> 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).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.