On Sat, Feb 1, 2014 at 9:58 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> There is a massive misunderstanding about the options provided in the votes.
>>
>> If the option #2 and #3 are accepted, only, I repeat, only the
>> declarations of the variables used by zpp have to be changed, nothing
>> else, no #ifdef, etc.
>
> I understand this. What is worrying me is that if you fail to do that
> for some function, you end up using wrong variable type, and it would
> lead to bugs that, from experience, are *very* hard to catch. If you
> break the code explicitly, it plants a huge red flag saying "Here! You
> need to fix this!". But if you just silently accept wrong types (and zpp
> has no way of doing typechecks) then your best red flag would come in
> the form of a user complaining "my PHP server crashes under the high
> load with PHP 5.6".
> I.e. if you do zpp("s", &char_ptr, &len) and zpp now expects len to be
> size_t but you keep it declared as int, no tool will alert you and
> you're putting 64-bit value into 32-bit stack slot.
>
>> It can be automated for zpp, it is almost the case already and Anatol
>> is working on this part to fully automate zpp changes (with option #2
>> and #3).
>
> The bad part is not zpp. zpp is the easy part.
Very easy even, the replace.php will take care of this part.
> The bad part is all vars
> outside zpp and keeping them all in sync.
>
>> I will prepare a sample ext compiling using 5.3, 5.4, 5.5 and with the
>> int64 branch, it will be a better example than what we can see in
>> mongodb, which does not use option #2 and #3. It is basically bad as
>> many of us only focus on this constellation and totally ignore these
>> options which were added as a possible very good compromise.
>
> I'm not ignoring that option. On the contrary, it is exactly that option
> that you describe that I am worried about. And I am worried about it
> exactly because since you don't have (meaning, forced by the compiler or
> by zpp failure) to make the changes in all functions, it's all too easy
> to miss one, and missing one is all to hard to figure out.
That's where the compiler warnings/errors come to the game. Except for
the situations where one does explicit bad casting, which should be
avoided in the 1st place, if possible.
That being said, I have been advocated warning free php-src for years
now. I think if we ever start php6 then we should really change our
policy and get clean codes. Any warning can produce undefined
behaviors or changing behaviors. Using gcc and VC as base should put
us on the safe side. Both gcc and vc latest versions have new options
to actually get rid of many of the issues you are describing easily.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org