Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
On Thu, Mar 24, 2016 at 11:40 AM, Jan Ehrhardt wrote: > William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 09:16:17 > -0500): > >> > http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html > > > >It's been a *long* time, and I know it hadn't been that well maintained > >for non-Linux (non-BSD) target architectures. > > On the contrary: Windows support for PHP has made a big jump. The release > master of PHP7 is even a Microsoft employee. > Excellent! >> Even in the 32-bits PHP 7 there are some: > >> > >> > http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html > > > >With a bit of luck - many of these are resolved by simply jumping up to > >Visual Studio 2015 (and removing any number of win32-specific bandaids > >that covered some warts in the earlier stdc lib)? > > Read carefully: these are the results when compiling with VC14 == VS2015. > This is the way the official PHP7 binaries are built. > And in fairness, not every "conversion from 'size_t' to 'unsigned int'" error is actually a lurking bug. If you know the memory allocation can't exceed some fixed size (e.g. passed as an httpd header value that already enjoys truncation or rejection much earlier in the process), then that flag would generally mean nothing. It's a long process to get such things 100% correct, we have a few defects lingering in httpd 2.4 release branch today - some due to binary ABI restrictions. My entire point is that VC14 makes such a thing possible, where it really wasn't possible while Microsoft was ignoring POSIX in many places.
Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 09:16:17 -0500): >> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html > >It's been a *long* time, and I know it hadn't been that well maintained >for non-Linux (non-BSD) target architectures. On the contrary: Windows support for PHP has made a big jump. The release master of PHP7 is even a Microsoft employee. >> Even in the 32-bits PHP 7 there are some: >> >> http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html > >With a bit of luck - many of these are resolved by simply jumping up to >Visual Studio 2015 (and removing any number of win32-specific bandaids >that covered some warts in the earlier stdc lib)? Read carefully: these are the results when compiling with VC14 == VS2015. This is the way the official PHP7 binaries are built. Jan
Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
On Thu, Mar 24, 2016 at 3:40 PM, William A Rowe Jr wrote: > On Thu, Mar 24, 2016 at 9:31 AM, Yann Ylavic wrote: >> >> Not to talk about they very personal conception of sizeof(long) on >> 64bit systems... > > You might be too young to remember when pointers had little to > no relation to integer registers on many cpu architectures :) I'm afraid not :( I wasn't talking about pointers here, though, but I agree that numeric types have never been something consistent accross platforms either. Simply now that char/short/int/long types could have had (finally!) there own size, and a common and consistent agreement on, for all/most modern systems... it failed. They surely had good reasons to do so, though it might just have moved/postponed the issues (to portable coders, at least). But after all, let's all use the APR! :)
Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
On Thu, Mar 24, 2016 at 9:31 AM, Yann Ylavic wrote: > >> nghttp2_session.c(160) : warning C4996: 'vsnprintf': This function or > >> variable may be unsafe. Consider using vsnprintf_s instead. To disable > >> deprecation, use _CRT_SECURE_NO_WARNINGS. > > [sarcasm] > Microsoft being unable to provide a safe vsnprintf() in the first > place and now warning every user is kind of ironic. > Microsoft claims that all the non-MS foo_s variants that have buffer targets as defined by POSIX are insecure, and offer foo_s variants. We have apr's safe strncpy etc, so it's not like we didn't agree - at least for some cases. They are free to make any claim they like, but they offered an out... from these warnings ... -D_CRT_SECURE_NO_DEPRECATE > Not to talk about they very personal conception of sizeof(long) on > 64bit systems... > You might be too young to remember when pointers had little to no relation to integer registers on many cpu architectures :) [/sarcasm] > > Not a very constructive comment, I agree :) > :)
Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
>> nghttp2_session.c(160) : warning C4996: 'vsnprintf': This function or >> variable may be unsafe. Consider using vsnprintf_s instead. To disable >> deprecation, use _CRT_SECURE_NO_WARNINGS. [sarcasm] Microsoft being unable to provide a safe vsnprintf() in the first place and now warning every user is kind of ironic. Not to talk about they very personal conception of sizeof(long) on 64bit systems... [/sarcasm] Not a very constructive comment, I agree :)
Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
On Thu, Mar 24, 2016 at 8:49 AM, Jan Ehrhardt wrote: > William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 07:58:45 > -0500): > >Precisely, Jan. We don't know where these truncation errors lead - do > they > >portentially open security holes? They cetainly interefere with serving > >huge resources such as .iso images. > > > >When I first tripped over this, I breifly pondered putting together a > >patch. PHP, httpd (through apr) dealt with all this long ago. > > Apparently, you never compiled PHP 5.5/5.6/7.0 on Windows 64-bits. There > are loads of 'possible loss of data' warnings. See for yourself: > > http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html It's been a *long* time, and I know it hadn't been that well maintained for non-Linux (non-BSD) target architectures. > Even in the 32-bits PHP 7 there are some: > > http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html With a bit of luck - many of these are resolved by simply jumping up to Visual Studio 2015 (and removing any number of win32-specific bandaids that covered some warts in the earlier stdc lib)? Remaining errors likely still need fixing. That sizeof(int) == sizeof(void *) assumption from 64ILP architectures is *not* part of the spec. We have 64ILP (int == long == void*), 64LP (long == void* != int) as well as 64P (long == int != void*) and each of these are valid architectures. The various types such as ptrdiff_t that POSIX exposes *should* resolve these all when the correct types are chosen, and that is now true with MSVC 14 on Windows as well. It just becomes a matter of using the true and correct type for various operations. Cheers, Bill
Re: mod_http2 on Windows (was: Re: Status for 2.4.20)
William A Rowe Jr in gmane.comp.apache.devel (Thu, 24 Mar 2016 07:58:45 -0500): >Precisely, Jan. We don't know where these truncation errors lead - do they >portentially open security holes? They cetainly interefere with serving >huge resources such as .iso images. > >When I first tripped over this, I breifly pondered putting together a >patch. PHP, httpd (through apr) dealt with all this long ago. Apparently, you never compiled PHP 5.5/5.6/7.0 on Windows 64-bits. There are loads of 'possible loss of data' warnings. See for yourself: http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x64-r454ae8a.html Even in the 32-bits PHP 7 there are some: http://windows.php.net/downloads/snaps/master/r454ae8a/logs/make-ts-windows-vc14-x86-r454ae8a.html Jan
