The precursor to this patch "[PATCH] WIN64: httpd API changes" was posted 10/7 so I thought we had had suitable time for discussion. I have addressed the one issue that was raised.
That explains why I didn't see it -- I was in Switzerland.
There have also been several other threads on the httpd & apr lists and the feedback I had received indicated the it was appropriate to sanitize the 64 bit compile even if it incurred httpd API changes. However if there are specific security issues that this has brought up I am more than anxious to address them. Are you opposed to changing the API to fix 64 bit warnings or are there specific issues that I can address and continue to move forward rather that back out the entire patch?
I am opposed to changing the API just to mask warnings within the implementations. In any case, these changes cannot possibly be correct -- the API has to be changed from the bottom-up, not top-down. It is far safer to cast module-provided data from int up to 64 bits than it is to cast it down from 64 bit to int.
Fix mismatches of the standard library functions first, then fix APR, then carefully change our implementation so that it works efficiently on the right data types as provided by APR, and finally fix the API so that modules can work. If that isn't possible, then just live with those warnings on win64.
In any case, changes like
+ /* Cast to eliminate 64 bit warning */ + rv = apr_file_gets(buf, (int)bufsiz, cfp);
are absolutely forbidden.
....Roy
