Andy, Since I started all of this with my patch, let me respond to what I believe the real problems are:
1. File (socket) handles are ints. Why not create a special type called file_handle_t, that changes sizes with platforms that have different requirements of file handle types (read windows)? 2. Anywhere we are using int for a buffer size, we should be using size_t. It's just that simple. This is plainly a deficiency in openssl source, and in any other cross-platform code base that assumes an int is big enough to hold the size of a memory based buffer. The only exceptions to this rule should be cases where the buffer is limited in size to some >4G value - I realize that most of them are limited so by practicality anyway, but the problem is that anytime we can pass "sizeof(x)" as a parameter, we need to support large buffer sizes, because on 64-bit platforms, sizeof(x) returns size_t - an address-space-sized quantity. This is the reason size_t was invented in the first place. John >>> "Andy Polyakov via RT" <[EMAIL PROTECTED]> 1/5/2003 3:33:27 PM >>> .. or does size_t matter:-) I had a look at BRANCH_WIN64 last night and here're some thoughts. First of all I want to point out that I had rather fast look so that this is probably not a final judgment:-) As discussed earlier Win64 implements P64 programming model and so the discussion started ignited at casting size_t (which is 64-bit) to int vs. real size_t-ification. But for some reason the question if it's a Win64-specific problem or a generic OpenSSL deficiency didn't get proper attention. At least in my opinion. And the simple fact is that it appears to be a *generic* OpenSSL deficiency. Indeed! Most of those casts from size_t were proposed to be made to int, meaning that if there're any bits lost in on P64 platform, same bits will be lost even on LP64 platform! Now having figured this I wonder how come did Win64 deserve so special treatment? I mean being effectively mobbed by branching it to a separate branch basically without any specified release schedule? Do note that I personally have no "special feelings" for Win64 and "emotionally" I'm fine with Win64 being mobbed:-) It's just that I see that by putting Win64 support to prime line development line, we can use Win64 developers [or their tools] to eliminate [yet another] *generic* OpenSSL deficiency. In other words. The way I see it is this. *If* OpenSSL compiles on Win64 with "possible loss of data" warning off (/wd4267 and /wd4244 to be specific, and it does compile!) and passes the test (no hardware, can't tell), it means exactly the same thing as on any other LP64 *supported* platform and therefore might as well be supported. Moreover, it's possible to support it a little better actually, because we have the option to denote the fact that support is in fact limited by "branding" the object modules with #pragma comment(linker,"/largeaddressaware:no") which provides for ILP32 run-time option (as was discussed earlier in another context). But the above does *not* mean that I'm suggesting to skip the size_t-ification of the toolkit! All I'm saying is that it's not a Win64 specific issue and shouldn't be treated as one. As for size_t-ification itself. My feeling after looking at the BRANCH_WIN64 was "do prioritize." There're two ways to tackle the problem. 1. Promote types. 2. Recognize legitimate casts and cast. Take BN code for example. Original code from HEAD and 0.9.7 compiles without a single warning. Code from BRANCH_WIN64 is filled with warnings. Can HEAD break on [L]P64? Yes. What one can do? 1. Promote relevant variables/structure members. 2. Insert couple of assertions which would make BN [gracefully] fail, thus ensuring that casts are legitimate (well, it compiles without a single warning, so that casts are legitimate). I believe there're assertions in place already, one has to verify it. In either case I'd go for 2, because it also effectively protects users from DoS. Indeed, if BN is actually asked to operate on >128Gbit numbers, it's *definitely* a mistake and the library should fail, not start consuming hours of CPU time. Symmetric algorithms on the contrary has to be type promoted, and it has to be done in first hand, they apparently not... What to do? I have promoted message digests and few symmetric algorithms already and the question I'm facing now is which branch to commit to. Of course there is BRANCH_WIN64, but I fear that it ends up one bit too different from HEAD to maintain the situation under control. I mean I fear that synching BRANCH_WIN64 to HEAD might become as time consuming as implementation. Cheers. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
