- 2009.10.28 16:02 "Re: [Tiff] extending tags in "a"ppend mode?", by Frank Warmerdam
- 2009.11.03 12:16 "Re: [Tiff] Tiffcrop test suite and logluv issues", by Toby Thain
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