[Top][All Lists]

[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

From: Jan Djärv
Subject: bug#9196: integer and memory overflow issues (e.g., cut-and-paste crashes Emacs)
Date: Fri, 29 Jul 2011 12:01:15 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0


Since strlen is defined to return size_t and you store the result in a ptrdiff_t, does not that mean you have introduced a possible signed/unsigned conversion error?

 In gtkutil.c:

+      ptrdiff_t lim = min (TYPE_MAXIMUM (Window),
+                          min (PTRDIFF_MAX, SIZE_MAX) / sizeof (GtkWidget *));

Isn't this a compile time constant?  Should it not be a #define or something?
IMHO, the check in gtkutil.c will only call memory_full when there is 2^31 (about 2 billion) scroll bars in Emacs. Isn't it overengineering to check for that case?

In xgselect.c:

+       int gfds_size_max =
+         min (INT_MAX, min (PTRDIFF_MAX, SIZE_MAX) / sizeof *gfds);

Here a compile time constant is recalculated inside a loop.
The xgselect.c is also overengineering IMHO. The number checked represents the number of file descriptor sources Glib is checking. I can understand checking sizes for strings that come from external sources, but only code adds file descriptor sources. If some bug causes the addition of 2 billion sources, a crash would be fine by me. Actually better than memory_full, because the core is much more useful.

I haven't looked at the other files. I hope to find time to look at xselect.c at least.

        Jan D.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]