Subject: bug#9874: Fixes for several integer overflow and width issues

From: David De La Harpe Golden <[email-masked]>
Date: Wed, 26 Oct 2011 18:02:22 +0100

On 26/10/11 15:26, Juanma Barranquero wrote:
>> Thank you very much, but we're too far in the release process for such
>> large patches, so it will have to wait for 24.2.
>
> These bugs seem serious enough:
>
>      - On my Fedora 14 x86-64 host, (signal-process 4294967295 1)
>        crashes my entire login session, Emacs included, and leaves my
>        workstation in a corrupted state in which the screen
>        continually flashes a nonsense pattern and I cannot log in.
>        This bug occurs because Emacs incorrectly assumes that fixnums
>        fit into pid_t values, which is not true on typical 64-bit hosts.
>

Hmm. The really serious/horrible part there (screen manglement and being 
unable to login again) sounds like some X and/or [gkx]dm bug well 
outside emacs' responsibility.  Given the current state of the emacs 
code, it should "just" kill (hup) all the processes you can kill*.  It 
shouldn't be any worse than if you just opened up an xterm and typed 
"kill -HUP -1".

Yes, that probably includes suddenly ending your entire desktop session, 
but unless you're running as a privileged user that should "just" leave 
you staring in annoyance at the [gkx]dm login dialog, there shouldn't be 
any lingering corruption, just like there shouldn't be any lingering 
corruption with a "kill -HUP -1".

Emacs bug that 4294967295 silently/surprisingly becomes -1 in 
signal-process? Well, probably. Emacs bug that your computer's state 
somehow gets corrupted to the point you can't log in again?  No.

*  pid_t 32-bit, 4294967295 => 32-bit -1, and kill(-1,...) signals 
everything you're allowed signal.