> -----Original Message----- > From: Matt Wilmas [mailto:php_li...@realplain.com] > Sent: Tuesday, August 25, 2015 2:19 PM > To: Anatol Belski <anatol....@belski.net>; 'Dmitry Stogov' <dmi...@php.net>; > 'Xinchen Hui' <xinche...@zend.com>; 'Nikita Popov' <nikita....@gmail.com>; > 'Pierre Joye' <pierre....@gmail.com>; 'Bob Weinand' > <bobw...@hotmail.com>; 'Jakub Zelenka' <bu...@php.net> > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Overflow checks and integral vars comparison > > But it is *definitely* fine to be optimistic and rely on compiler to do basic, basic > stuff like this. No reason to make things more complicated just to think one is > helping the compiler. > > Proof? Have you seen the whole VM in the last, like, 10 years? Using your logic, > we have major, major, MAJOR problems literally everywhere there! > > Now can anyone point to problems compiling the default, specialized VM? I rest > my case. :-) There's conditional stuff ALL over the place (not macros), and > propagated to inline functions, etc. where the compiler is "counted on" to > remove the constant conditions and all that stuff. > > The current FAST_ZPP parameter parsing, any unnecessary parts are optimized > out (it'd be bad if that wasn't the case). My new proposal (coming soon...) has a > lot of more complicated-looking source code, but almost all deleted by the > compiler. > > Transforming zpp's type spec string at compile time, which MSVC can't do > because it does indeed suck for some reason, involves *dozens* of KB of source, > many inline functions, etc. but nearly 100% of it is deleted, correctly, by GCC and > Clang. > > > Anyway, that's why I say if "some" compiler can't do basic optimizations, it > *sucks*, and has much bigger problems in the rest of the source, so there's no > reason to worry about it... At all. > An #ifdef seems just a bit more readable, less tricky. Clear if a compiler tells it implements some standard like C89, it should be trustful. Or a feature like dead code elimination. Some projects even use not standard compiler features depending on which platform they are in much bigger extent than PHP. My sentence about not being optimistic is about not trusting blindly on that, not ignoring useful things.
> I mean, PHP's strlen() on any platform, why is it possible to have larger strings > (size_t length) than can be returned in zend_long. That's a bug. > > > memory_limit is unsigned 32-bit there, but even if not - it is hardly > > possible to have a string exceeding it there anyway. > > Not possible? Then like I said, why use size_t? It would help some of these > things to get rid of it. > It is a "theoretical" bug. No issue on 32-bit, on 64-bit you would need to have a system with over 10^9 GB of RAM to come to it :) > > Otherwise, there is a plenty of libraries working with size_t and it > > makes full sense to exhaust that on 64-bit. And the most of PHP7 is > > just fine with size_t. > > So? Why does it matter if libraries are using size_t? The same libraries always > have been and passed an int (from string length) before PHP 7. Pass them > zend_long instead now... > One aspect is because of 64-bit, to exhaust the potential of the platform. But it is again more general discussion whether PHP is a general purpose or web dedicated language. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
