Re: [PATCH 1/7]: Fix sparc64 setjmp implementation.

[David Miller <davem@davemloft.net>]

From: Javier Martín <lordhabbit@gmail.com>
Date: Wed, 04 Mar 2009 16:58:22 +0100

> As an example of what this entails, the failure to think with the future
> in mind has extraordinarily hampered the 32->64 bit transition: many
> Windows apps (among them the Vorbis codecs!) had be nearly rewritten
> because they used "unsigned long" interchangeably with pointer types. I
> still wonder if it would have been so difficult to use "void*", and the
> proper types for pointer arithmetic.

Actually the problem is that they used "int" interchangably with
pointer types.

"unsigned long" is always safe because it is going to be
the largest natural word size on the machine, at least
as large as a pointer will be.

We've been using "unsigned long" for storing virtual addresses in the
Linux kernel for 10+ years and it works just fine.  :-)

Really, nobody is going to touch the grub_jmp_buf[] implementation
other than sparc expert.  So saying this case will cause problems for
grub non-sparc folks is something of a scarecrow.