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

["Jan Djärv" <jan.h.d@swipnet.se>]

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.