Received: by cthulhu.engr.sgi.com (940816.SGI.8.6.9/911001.SGI)
	for tiff-list id QAA29879; Mon, 19 Sep 1994 16:43:27 -0700
Return-Path: <owner-tiff>
Received: from sgi.sgi.com by cthulhu.engr.sgi.com via ESMTP (940816.SGI.8.6.9/911001.SGI)
	for <tiff-relay@cthulhu.engr.sgi.com> id QAA29871; Mon, 19 Sep 1994 16:43:21 -0700
Received: from research.att.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI)
	for <tiff@sgi.com> id QAA19275; Mon, 19 Sep 1994 16:43:18 -0700
Message-Id: <199409192343.QAA19275@sgi.sgi.com>
Received: by research.att.com; Mon Sep 19 19:31 EDT 1994
Received: from papyrus.UUCP by allegra.tempo.att.com; id AA24768; Mon, 19 Sep 94 19:31:22 EDT
Date: Mon, 19 Sep 94 19:31:24 EDT
From: jqa@allegra.att.com (Jim Arnold)
To: tiff@sgi.sgi.com
Subject: Re: TIFF Bit Ordering Versus Fill Order
Sender: owner-tiff@sgi.sgi.com
Precedence: bulk

Using bit field order is a fragile and inconclusive way to
determine bit order.  The order in which the compiler allocates
bit fields has NOTHING to do with the bit order of the values
in the fields themselves.  I've seen compilers that allocate
bit fields in the opposite order for machines with the same
byte/bit order.

Sam, you're better off ignoring all this blather about bit order.
Leave the library alone.  You've already implemented the only
sensible policy.  Trying to do more will make things worse for
the people who do understand the issues, and it will not
enlighten those who do not.

I understand the urge to please one's customers.  You'll please
this customer by doing the right thing: nothing.

Jim Arnold

