>> .\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). > 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]
