[PATCH] ppc64: fix semtimedop compat syscall

Stephen Rothwell sfr at canb.auug.org.au
Wed Mar 23 09:58:22 EST 2005

On Wed, 23 Mar 2005 09:40:45 +1100 Paul Mackerras <paulus at samba.org> wrote:
> Stephen Rothwell writes:
> > On Wed, 23 Mar 2005 07:19:31 +1100 Paul Mackerras <paulus at samba.org> wrote:
> > 
> > > Arnd Bergmann writes:
> > > 
> > > > One problem is that sign extension can not be expressed in architecture
> > > > independent C code.
> > > 
> > > On which architectures does (long)(int) x not give the desired result?
> > 
> > Presumably for a u32 function argument x which has been zero extended?
> Huh??  For a 64-bit architecture with 32-bit ints, (long)(int) x will
> sign-extend the bottom 32 bits of x to 64 bits.  The top 32 bits don't
> matter, and in particular it doesn't matter if x has previously been
> zero-extended to 64 bits, or if x is a u32.

I was just being pedantic as this is the case we care about.  It is quite
possible that the compiler upon seeing "int x" as an function argument
will assume that any value passed to the argument has been sign extended
to the equivalent of long by any caller of the function (since ints as
function arguments may actually be 64 bit registers).  So the (long)(int)
cast may be a noop for this particular complier and if we have zero
extended the value in assembler instead, the result will be incorrect.

I am not saying that any compiler does do this, but it would still be
internally consistent, no?

(sfr hopes he is not making a fool of himself ... :-))
Stephen Rothwell                    sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20050323/92207740/attachment.pgp 

More information about the Linuxppc64-dev mailing list