"Sigbjorn Finne" <[EMAIL PROTECTED]> writes:
> "Julian Seward (Intl Vendor)" <[EMAIL PROTECTED]> writes:
> >
> > Hmm, we're looking at this. However, I don't really know what
> > C is or is not supposed to do here. Given
> >
> > char fooble ( ... )
> > {
> > return 'z';
> > }
> >
> > on an x86, 'z' will be returned at the lowest 8 bits in %eax.
> > What I don't know is, is the C compiler obliged to clear the
> > upper 24 bits of %eax, or does that onus fall on the callee?
>
> Yes, the callee is required to narrow <expr> in 'return <expr>;' to
> fit that of the specified return type -- see 9.8 of Harbison and
> Steele. So, a C compiler that cause f() to return 0x7fffffff for
> the following,
>
> unsigned char g()
> {
> return 0x7fffffff;
> }
>
> unsigned int f()
> {
> return g();
> }
>
> is in the wrong. [Notice that narrowing for signed integral types
> is undefined in ISO C, but most current-day compilers implement
> such narrowing ops the same way, i.e., by masking off excess bits.]
It's certainly true that an ISO C compiler on a typical machine must
return 255 from f() (on an atypical machine, it's possible to have
unsigned char be a 32-bit type). However, this is essentially
unrelated to the question of whether the x86 ABI allows g() to return
a value in %eax that has the upper 3 bytes non-zero.
When I compile the following file:
-------------------- abitest.c --------------------
unsigned int g_val;
unsigned char g()
{
return g_val;
}
unsigned int f()
{
return g();
}
---------------------------------------------------
with the command
gcc -Wall -O2 -fomit-frame-pointer -S abitest.c
I get the output:
-------------------- abitest.S --------------------
.file "abitest.c"
.version "01.01"
gcc2_compiled.:
.text
.align 16
.globl g
.type g,@function
g:
movzbl g_val,%eax
ret
.Lfe1:
.size g,.Lfe1-g
.align 16
.globl f
.type f,@function
f:
call g
andl $255,%eax
ret
.Lfe2:
.size f,.Lfe2-f
.comm g_val,4,4
.ident "GCC: (GNU) 2.7.2.3"
---------------------------------------------------
You can see that the code for f is:
call g
andl $255,%eax
ret
So gcc believes that a function which returns a value of type unsigned
char is not responsible for clearing the high 3 bytes of %eax.
Carl Witty
_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
