Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas018.isp.belgacom.be (localhost [127.0.0.1])
        by inav026.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id k33DLVec023606
        for <joris.at.lebbeke@skynet.be>; Mon, 3 Apr 2006 15:21:31 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx012.isp.belgacom.be (inmx012.isp.belgacom.be [195.238.5.90])
        by inas018.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id k33DLI2j018678
        for <joris.at.lebbeke@skynet.be>; Mon, 3 Apr 2006 15:21:22 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx012.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id k33DL97g017898
        for <joris.at.lebbeke@skynet.be>; Mon, 3 Apr 2006 15:21:09 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id k33DDCON023994;
	Mon, 3 Apr 2006 09:13:15 -0400
Received: from mail.sidefx.com (tor149-99-58-193.dedicated.sprintdsl.ca
	[149.99.58.193])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id k33DD9qs023991
	for <tiff@lists.maptools.org>; Mon, 3 Apr 2006 09:13:09 -0400
Received: from [192.168.235.145] (crete.local.sidefx.com [192.168.235.145])
	by mail.sidefx.com (Postfix) with ESMTP id 1D33F5C058;
	Mon,  3 Apr 2006 09:13:09 -0400 (EDT)
Message-ID: <44311FB1.7060402@sidefx.com>
Date: Mon, 03 Apr 2006 09:14:25 -0400
From: Edward Lam <edward@sidefx.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
Subject: Re: [Tiff] WORDS_BIGENDIAN makes libtiff platform dependent
References: <20060401185622.61849.qmail@web37309.mail.mud.yahoo.com>
	<Pine.SOC.4.60.0604011656370.26551@blade.simplesystems.org>
	<1145.70.50.115.122.1143998044.squirrel@webmail.sidefx.com>
	<Pine.SOC.4.60.0604021224050.26551@blade.simplesystems.org>
	<44311E62.2000009@sidefx.com>
In-Reply-To: <44311E62.2000009@sidefx.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tiff@lists.maptools.org
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.000014db
X-MSP-STORE: Mon, 03 Apr 2006 15:21:34 +0200
Status:   

Sorry, I should have taken a close look first. Looking in tif_open.c, we have:

	{ union { int32 i; char c[4]; } u; u.i = 1; bigendian = u.c[0] == 0; }

Thus, libtiff was automatically detecting the endianness as Joris mentioned.

So the real question is: Why did we change it? Andrey/Frank?

-Edward

Edward Lam wrote:
> Hi,
> 
> Bob Friesenhahn wrote:
>> Earlier versions were using a define named 'HOST_BIGENDIAN' in 
>> libtiff/tiffconf.h:
>>
>>  * HOST_BIGENDIAN       native cpu byte order: 1 if big-endian (Motorola)
>>  *                      or 0 if little-endian (Intel); this may be used
>>  *                      in codecs to optimize code
>>
>> so it does not seem like there was a big change to me.  Maybe this had 
>> already been figured out before in your build environment and you just 
>> did not realize it?
>  >
>  > Libtiff really does need to know the endian order, the size of 'short,
>  > 'int', 'long', bit order, etc., in order to work correctly for a given
>  > target.
> 
> Curious. I just checked my copy of libtiff 3.7.0. In tif_config.h, I 
> have this:
> 
> HOST_BIGENDIAN defined to 0. I also have WORDS_BIGENDIAN mentioned
> 
> /* Native cpu byte order: 1 if big-endian (Motorola) or 0 if little-endian
>    (Intel) */
> #define HOST_BIGENDIAN 0
> 
> /* Define to 1 if your processor stores words with the most significant 
> byte
>    first (like Motorola and SPARC, unlike Intel and VAX). */
> /* #undef WORDS_BIGENDIAN */
> 
> Note that when building, I do *not* have WORDS_BIGENDIAN defined as a 
> compiler command line option.
> 
> Now here's the kicker:
> 
> % grep HOST_BIGENDIAN *.[ch]
> tif_config.h:#define HOST_BIGENDIAN 0
> % grep WORDS_BIGENDIAN *.[ch]
> tif_config.h:/* #undef WORDS_BIGENDIAN */
> 
> Although they're mentioned, they don't seem to be used at all! Taken 
> with your statement that libtiff requires knowing the host endian order, 
> how does libtiff 3.7.0 work at all? (or maybe if doesn't since I'm only 
> ever on Intel CPUs :)
> 
> Regards,
> -Edward
> 

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
