[syslinux] [GIT PULL] elflink warning fixes and auto extension support

[H. Peter Anvin]

On 04/17/2012 03:40 AM, Matt Fleming wrote:
> Hi,
> 
> I just pushed out changes that fix pretty much all the compiler build
> warnings on the elflink branch. Also, I've added "auto extension"
> support so that if the user doesn't type the file name extension it will
> automatically be looked up, e.g. now typing "ls" will execute "ls.c32".
> 

I looked over these patches... most of them look great, but I want to
flag two:

>       ldlinux: Use signed char consistently

This introduces a bug: get_key() is supposed to return positive values
for valid keystrokes.  For this transformation to be valid, the line:

                    return buffer[0];   /* timeout in sequence */

needs to be changed to

		    return (unsigned char)buffer[0];

>       graphics: Fix GXPix* assignment

This patch involves casting a bunch of types to sizes other than they
are about to be used as.  For real-mode pointers, please use the SEG()
and OFFS() macros instead; they contain the necessary casts (double
casts in some cases) and provides a place where we can hang debugging
checks if we should need to.

However, it also does this:

-	outb(val, (uint16_t)addr);
+	outb(val, (uint32_t)addr);

This is because the type of "addr" is completely bogus; the type of an
I/O port is uint16_t (we could introduce an ioport_t typedef for clarity
perhaps); making it a pointer is just wrong.

Furthermore, if one looks at it a little closer, it becomes clear that
"addr" is simply used for two constants, 0x3c4 for the first instance
and 0x3c5 for the other instance.  It probably would be useful to have a
<hw/vga.h> header somewhere defining these as symbolic constants, but
the pointer here is just wrong[1].

Part of this file was converted from assembly by a student, and there
are distinct assemblyisms in the code.

I can fix these two up, but I wanted to give you the feedback.

	-hpa



[1] Some C compilers have notions of address spaces where you can create
a pointer to a specific address space; however, gcc on x86 does not.
gcc on some other architectures does, just to be confusing.