2009.10.28 15:18 "[Tiff] extending tags in "a"ppend mode?", by Juergen Buchmueller

2009.11.03 12:16 "Re: [Tiff] Tiffcrop test suite and logluv issues", by Toby Thain

On 3-Nov-09, at 5:14 AM, Juergen Buchmueller wrote:

> On Mon, 02 Nov 2009 14:59:43 -0700
> Richard Nolde <richard.nolde@cybox.com> wrote:
>
> [snap]
>> as I suspect, the following code from tif_luv.c doesn't take into

>> consideration the fact that the original data is bigendian and I am >> compiling on a little endian host (having just gone through this with

>> Toby's patch suggestion.)
> [snip]

>>          for (i = 0; i < npixels && cc > 0; i++) {
>>                  tp[i] = bp[0] << 16 | bp[1] << 8 | bp[2];
>>                  bp += 3;
>>                  cc -= 3;

>> }
>
> As Toby said, this is endian safe. We've used it over and over again
> when coding CPU emulations for MAME :)
>

> But didn't your compiler warn you about the ambiguity of the > Shift-Left / OR expression?

It's not ambiguous to the compiler - only to humans who haven't internalised the precedence chart :)

> AFAIK one should put parens around the

> shifted terms to tell the compiler that the shift has precedence over > the OR. I.e. you don't want bp[0] << (16 | bp[1]), which in theory

> is a
> valid way to reduce the expression.

It is not a valid translation! A C compiler must obey precedence (<< is higher than |). However, again, for clarity I would always use parentheses though they are redundant for correct evaluation.

>
> Alternatively one could write:

>       tp[i] = 65536 * bp[0] + 256 * bp[1] + bp[2];

>

> Compilers today transform the power-of-two multiplications into rather > effective code (read: shift lefts) and it doesn't require parens.

This adds to the cognitive load for humans. A shift shows the intent more clearly.

--Toby

>

> HTH