How does an ELF pad its `short`s? - c

Question

I know that function arguments are padded to target word size, but with what?
Specifically in the context of the x86 Linux GNU toolchain, what do these functions return?
int iMysteryMeat(short x)
{
return *((int *)&x);
}
unsigned uMysteryMeat(unsigned short x)
{
return *((unsigned *)&x);
}
The question is whether, when hand-coding a function in assembly, it is necessary to sterilze "small" arguments by masking or sign-extending them before using them in "large" contexts (andl, imull).
I'd also be interested whether there are any more general or cross-platform standards for this case.

Answer 1

This depends on the ABI. The ABI needs to specify the choice that small arguments are extended by the caller, or by the callee (and how). Unfortunately, this part of the ABI is often underspecified, leading to different choices by different compilers. So to prevent incompatibility between code compiled with different legacy compilers, most modern compilers (I know in particular about gcc on i386) err on the side of caution and do both.
int a(short x) {
return x;
}
int b(int x);
int c(short x) {
b(x);
}
gcc -m32 -O3 -S tmp.c -o tmp.s
_a:
pushl %ebp
movl %esp, %ebp
movswl 8(%ebp),%eax
leave
ret
_c:
pushl %ebp
movl %esp, %ebp
movswl 8(%ebp),%eax
movl %eax, 8(%ebp)
leave
jmp _b
Note that a does not assume any extension rule about its argument, but extends it itself. Similarly, c makes sure to extend its argument before passing it to b (via a tail call).

Answer 2

int iMysteryMeat(short x)
{
return *((int *)&x);
}
This is undefined behavior in C, this violates aliasing rules and may also violate alignment requirements. In short don't do this.

Answer 3

Although Keith's answer is in line with the spirit of my question, per Alex's request I thought I'd try this out for myself.
Interestingly, in this case the more literal answer to my example is "garbage".
#include <stdio.h>
int iMysteryMeat(short x)
{
return *((int *)&x);
}
unsigned uMysteryMeat(unsigned short x)
{
return *((unsigned *)&x);
}
int main()
{
printf("iMeat: 0x%08x\n", iMysteryMeat(-23));
printf("uMeat: 0x%08x\n", uMysteryMeat(-23));
return 0;
}
gcc -m32 -S meat.c
iMysteryMeat:
pushl %ebp
movl %esp, %ebp
subl $4, %esp
movl 8(%ebp), %eax
movw %ax, -4(%ebp)
leal -4(%ebp), %eax
movl (%eax), %eax
leave
ret
uMysteryMeat:
pushl %ebp
movl %esp, %ebp
subl $4, %esp
movl 8(%ebp), %eax
movw %ax, -4(%ebp)
leal -4(%ebp), %eax
movl (%eax), %eax
leave
ret
./a.out
iMeat: 0x0804ffe9
uMeat: 0x0043ffe9
As you can see, not only is the usual sign-extension protocol overrided (i.e. compare with Keith's a()), it actually moves x into uninitialized stack space with movw, rendering the top half of the return value garbage no matter what main() gives it.
So, again, as ouah said, never ever do this in C, and in assembly (or in general, really), always sterilize your inputs.