[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9196: integer and memory overflow issues (e.g., cut-and-paste crashe
bug#9196: integer and memory overflow issues (e.g., cut-and-paste crashes Emacs)
Mon, 08 Aug 2011 20:01:48 +0200
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
Paul Eggert skrev 2011-08-06 03:24:
On 08/05/2011 02:26 AM, Jan Djärv wrote:
+ static char const xdefaults = ".Xdefaults-";
I think there might be problems with dumping and static variables.
There is a reason for initializing static variables in init-functions
rather in an initializer. I don't remember the details.
In the old days, Emacs sometimes did '#define static /* empty */' as
part of its undumping scheme, which meant that static variables inside
functions didn't preserve their values from call to call. Emacs no
longer does that, so we're OK here. (And even if Emacs still did
that, this particular code would be safe, as this particular variable
would be reinitialized to the correct value on every call.)
That is not what I meant. Tale a look at xterm.c, syms_of_xterm. Static
variables are initialized there. The manual says:
" You must not use C initializers for static or global variables unless
the variables are never written once Emacs is dumped. These variables
with initializers are allocated in an area of memory that becomes
read-only (on certain operating systems) as a result of dumping Emacs.
So I guess this usage is ok.
+ char *home = gethomedir ();
+ char const *host = get_system_name ();
+ ptrdiff_t pathsize = strlen (home) + sizeof xdefaults + strlen (host);
+ path = (char *) xrealloc (home, pathsize);
+ strcat (strcat (path, xdefaults), host);
p = path;
db = XrmGetFileDatabase (p);
- xfree (home);
Since home isn't free:d, you have introduced a memory leak.
No, we should be OK here -- the realloc frees 'home'.
Right, missed that.