On Fri, Nov 18, 2011 at 10:08 AM, Andy Polyakov <[email protected]> wrote: >>> .\ssl\t1_enc.c(963): warning C4267: 'return' : conversion from >>> 'size_t' to 'int', possible loss of data t1_lib.c >>> .\ssl\t1_lib.c(301): warning C4244: '=' : conversion from '__int64' to >>> 'long', possible loss of data We would like to know whether these are >>> planned to be solved please? >>> Apparently gcc has this warning from 4.3 onwards, so I may have a >>> crack at fixing them. It is likely to be a big job, though. > > size_t-fication has been going on for a while... > >> I'm on Linux with gcc 4.4.5 and there are no warnings. I think the >> warnings are because int/long have different meanings on 64 bit Windows >> systems. > > Correct, it has everything to do with Win64 being P64 (IL32 implied).
Not so sure about that - a MacOS 32-bit build gets a ton of warnings with -Wconverson. >> On modern Linux systems an int is always 4 bytes, and a long is >> always 8 bytes, regardless of the system wordsize. On 64 bit Windows >> systems those same types are both 8 bytes. > > No, "Linux" long is dependent on system wordsize, while on Windows long > is always 4 bytes. Win64-specific warnings are result of mismatch > between size_t and long. I [for one] used to verify that these warnings > are [relatively] safe to ignore upon every major release. > > On additional note, there is another related issue that has been a > matter of controversy: http://marc.info/?t=120582986500001&r=1&w=2. > >> Its been awhile since I >> looked into this topic, but if I'm right, it might be possible to force >> the compiler to use the Linux type mappings via a command line switch or >> by including a header file like stdint.h or inttypes.h. > > The problem originates in *base* types, ones that you can redefine. Even > if it was possible, it would make impossible reliable usage of Win32 > API. "Reliable" means that even though it will work in quite a number of > cases, it will fail spectacularly in others. It's bad advice... > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [email protected] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
