AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2000.04.19 20:48 "LibTIFF portability, makefiles, install...", by Antonio E. Scuri
2000.04.19 21:05 "Re: LibTIFF portability, makefiles, install...", by Chris Hanson
2000.04.19 22:15 "Re: LibTIFF portability, makefiles, install...", by Antonio E. Scuri

2000.04.19 22:15 "Re: LibTIFF portability, makefiles, install...", by Antonio E. Scuri

<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>