Subject: Re: quad_t shifts (more a standards issue)
To: None <current-users@netbsd.org>
From: Christos Zoulas <christos@zoulas.com>
List: current-users
Date: 09/10/1999 04:41:43
In article <199909092002.WAA0000007676@zel459.zel.kfa-juelich.de>,
Matthias Drochner <M.Drochner@fz-juelich.de> wrote:
>
>While I had to deal with a libkern issue, I considered to
>syncronize the files in libc and libkern again.
>But I found that there was a change done in libc
>which is either wrong or not complete:
>
>In libc/quad/ashrdi3.c, some casts were applied which change
>the behaviour wrt sign extension of right shifts.
>
>I don't have access to standards documents; the C99 draft
>says that the outcome of right shifts of signed values
>is implementation dependant. Should we interpret this as
>"dependant, but consistent": if "int" types get sign extended,
>"quad" types should too, and sign extension doesn't depend
>on the number of bits we shifted by? Or is this really
>random, ie we shouldn't care?
>
>In particular,
>s = ((u_long)aa.sl[H] >> (LONG_BITS - 1)) >> 1;
>does always give a "0", so we always fill up with zeroes
>since that cast went in; without the cast, quads would
>inherit the behaviour of longs. If we agree to "random"
>bahaviour, that line could be nuked.
>

That was probably my wrong doing. Please note that this is not
defined behavior. But the [a] in the fuction name tells me
that we should brobably shifting in ones.

christos