bug#9196: integer and memory overflow issues (e.g., cut-and-paste crashes Emacs)

[Jan Djärv]

Hello.

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.