AWARE [SYSTEMS]
AWare Systems, , Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
November 2009

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



Thread

2009.11.02 17:51 "Tiffcrop test suite", by Richard Nolde
2009.11.02 21:59 "Tiffcrop test suite and logluv issues", by Richard Nolde
2009.11.02 23:02 "Re: Tiffcrop test suite and logluv issues", by Toby Thain
2009.11.03 10:14 "Re: Tiffcrop test suite and logluv issues", by Juergen Buchmueller
2009.11.03 12:16 "Re: Tiffcrop test suite and logluv issues", by Toby Thain
2009.11.03 13:23 "What are the LibTIFF v4.0 release plans?", by Steve Eddins
2009.11.03 14:37 "Re: What are the LibTIFF v4.0 release plans?", by Bob Friesenhahn
2009.11.03 15:00 "Re: What are the LibTIFF v4.0 release plans?", by Steve Eddins
2009.11.04 02:30 "Re: What are the LibTIFF v4.0 release plans?", by Jay Berkenbilt
2009.11.03 20:46 "Re: Tiffcrop test suite and logluv issues", by Daniel Mccoy
2009.11.04 08:45 "Re: Tiffcrop test suite and logluv issues", by Juergen Buchmueller
2009.11.04 15:49 "Re: Tiffcrop test suite and logluv issues", by Toby Thain

2009.11.03 12:16 "Re: 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
> Juergen
> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/