On Fri, Oct 22, 2010 at 10:40:01AM +0200, Andy Polyakov wrote: > > You've got to appreciate the irony. Even though "systems" are referred > to as "some," we can as well stop pretending that we are not talking > about Win64. And on Win64 off_t is ... 32 bits. But even in real POSIX > environment off_t is not foolproof choice. Because on a range of 32-bit > platforms its width depends on compile-time definitions such as > _LARGEFILE_SOURCE and company. This means that if libcrypto is compiled > with 64-bit off_t, then applications would have to be as well. Formally > we can't expect they are.
*Vomit sound* I was trying to forget that LARGEFILE_SOURCE garbage. However, it is easily worked around, the same way the insane vendors who choose to implement it do so in their libraries and header files. On such a system (not hard to detect at build time) build the actual BIO internals with -DLARGEFILE_SOURCE and thus 64-bit off_t; then build a set of wrapper functions with 32-bit "off_t" and use header file magic to ensure that applications get the right one. It is horrible, but it is what's forced on application developers by the LARGEFILE_SOURCE idiocy, foisted on users by kernel developers who did not understand how to rename/renumber system calls and their library stubs for backwards compatibility even though there were open-source examples already out there in the world. Thor ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
