Received: from [207.176.88.85] by phillip.cerious.com (NTMail 3.03.0017/7.aaxh) with ESMTP id pcrews for <pcrews@cerious.com>; Wed, 19 Apr 2000 18:45:41 -0400
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id SAA11451;
	Wed, 19 Apr 2000 18:17:59 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Wed, 19 Apr 2000 18:15:59 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id SAA11355
	for tiff-outgoing; Wed, 19 Apr 2000 18:15:59 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from tecgraf.puc-rio.br (ibere.tecgraf.puc-rio.br [139.82.85.1])
	by gate7.olympiakos.com (8.9.3/8.9.3) with ESMTP id SAA11352
	for <tiff@olympiakos.com>; Wed, 19 Apr 2000 18:15:54 -0400
Received: from tarsila (tarsila [139.82.85.131])
	by tecgraf.puc-rio.br (8.9.2/8.9.3) with ESMTP id TAA13022
	for <tiff@olympiakos.com>; Wed, 19 Apr 2000 19:15:37 -0300 (EST)
Message-Id: <4.2.1.20000419190136.00a41820@139.82.85.1>
X-Sender: scuri@139.82.85.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 
Date: Wed, 19 Apr 2000 19:15:34 -0300
To: tiff@olympiakos.com
From: "Antonio E. Scuri" <scuri@tecgraf.puc-rio.br>
Subject: Re: LibTIFF portability, makefiles, install...
In-Reply-To: <AIG.AWP>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-tiff@olympiakos.com

<x-flowed>At 16:05 19/04/00 -0500, you wrote:
>ANSI C is almost, but not quite sufficient for building portable
>libraries.

   I guess I can say that 90% of the cases it is.


>ANSI C does not have any data types with exact size, only with minimum
>size.  (I.e. "short" can hold at least 16 bits worth of data but does
>not actually have to be 16 bits.)  It also does not define any standard
>method of specifying structure layout in memory.  (Endianness is not an
>issue for the language, because it's possible to determine this at run
>time.  Though it'd be nice to have it built in.)
>
>I believe the latest draft for the next revision of Standard C has some
>guaranteed-size data types, but I'm not sure where to find it or what
>compilers support these types or even whether my belief is well-placed.

   In most of the OSs/Compilers the data types do have the same size. 
(please do not consider DOS)

>(There's also the small issue that ANSI C has a very Unix-centric view
>of certain things like the filesystem.  For instance, on MacOS pathnames
>don't necessarily uniquely identify files.  And copying a file involves
>more than duplicating its data; you need to duplicate its resources and
>its Finder information too -- this is the case for NTFS on Windows NT as
>well.  I think the former is more of an issue for libtiff, though.)

   Double correct. I am considering the case of a image file access 
library, but many (not all) other cases apply.

   But even if you ignore ANSI C, the code of the library can be more 
elegant without having to create many ifdefs and defines.

scuri

</x-flowed>
