On 4/24/2012 9:36 AM, Philip Lantz wrote:

> Eric Sosman wrote:

>>

>> On 4/22/2012 5:36 PM, Joe keane wrote:

>>> case A

>>>

>>> int ffs16a(int x)

>>> {

>>> int res;

>>>

>>> if ((x& 0xFF) == 0)

>>> res = kk_ffstab[x& 0xFF];

>>> else

>>> res = kk_ffstab[x>> 8& 0xFF] + 8;

>>> return res;

>>> }

>>>

>>> case B

>>>

>>> int ffs16b(int x)

>>> {

>>> int resl;

>>> int resh;

>>> int res;

>>>

>>> fla = (x& 0xFF) != 0;

>>> resl = kk_ffstab[x& 0xFF];

>>> resh = kk_ffstab[x>> 8& 0xFF] + 8;

>>> res = (fla - 1)& resl | (0 - fla)& resh;

>>> return res;

>>> }

>>

>> As a practical matter, no, even though a strict reading

>> of the C Standard would permit it. Nonetheless, unlikely not

>> to malfunction on all but a minority of non-conforming C99 or

>> C11 (not necessarily C90) implementations, usually.

>

>

> Eric,

>

> I hope you will enlighten us as to what strict reading could allow this

> to work as written, and in what way the version of C standard applied

> affects it.

>

> I'm guessing it has something to do with negative zeroes. If not, I'm

> completely lost.

>

> The first function will not work on any implementation, of course,

> without the obvious correction to the test.
That's what I was alluding to: The two code fragments cannot

possibly be equivalent unless kk_ffstab[] holds 256 identical

values.

Then there's the potential non-portability that `fla-1' or

`0-fla' might be represented by some other bit pattern than all-1,

like 111...110 for ones' complement or 100...001 for signed

magnitude. Nowadays these are mostly theoretical concerns: strict

portability demands that such representations be considered, but

ignoring them diminishes portability only a trifle.

But mostly I was annoyed at the O.P. for (1) asking no question,

(2) failing to describe his purpose, (3) being too clever by half,

and (4) failing at (3).

--

Eric Sosman

(E-Mail Removed)d