Just to get a better grasp of the objective, and make sure that we all
are understanding and assuming the same things, I'll write what I have
interpreted. Please correct whatever is wrong, confirm or comment
1) The same definition of curl_off_t must be used when building the
library and when an app uses libcurl's external API. This implies that
libcurl's external API must define curl_off_t in the same way as it is
defined when the library is built.
2) Once that the library is built curl_off_t definition is set, the
external API for *_LARGE options and curl_seek_callback 'interfaces'
are fixed for that specific binary version of the library.
3) We could say that the curl_off_t definition is a build-time
property of the library. And that under most circumstances it will be
a 32 or 64 bits signed integral data type.
4) The OS might provide LFS, large file support (>2Gb), or not.
5) The compiler might offer LFS or not. And there might be no way to change it.
6) The compiler might be capable of supporting 32 or 64 bit file
offsets depending on a compiler option or the definition of a
preprocessor symbol. So...
7) We have another build-time property for the library. Compiler
option or preprocessor symbol controlling compiler LFS. This property
must be set when using the library in the same way as it was set when
the library was built.
8) Reached this point it is obvious that there are two properties or
settings that must be somehow preserved for the external library usage
as soon as the library is built.
9) Combination of this two properties results in four possible cases:
9a) 32 bit curl_off_t and 32 bit file offsets: No problem here, they match.
9b) 64 bit curl_off_t and 64 bit file offsets: No problem here, they match.
9c) 32 bit curl_off_t and 64 bit file offsets: In this case the
effect would be the same as if the compiler did not support LFS. The
problem is that if an app using the library only checks the
compiler-LFS-build-time-property it might wrongly assume that libcurl
is also capable of LFS. So, better safe than sorry, the library build
process should not 'generate' this case.
9d) 64 bit curl_off_t and 32 bit file offsets: The library build
process should not generate this case either. The library user seeing
a 64 bit curl_off_t could think that the library supports large files,
but it would misbehave at least when a large offset file operation is
10) In other words, the build-time configured curl_off_t data type
depends on and must have the same number of bits as the build-time
configured compiler file offsets whatever it is.
11) Assuming that there are no errors in all the above reasoning we
now get to the part of 'which was first the egg or the hen'. If we
have a system capable of running the 'buildconf' generated 'configure'
script we should 'use' the hen, otherwise we'll need an egg for each
system. And there's also the case of the cross-compiling eggs with
Enough points for now.
Received on 2008-05-27