Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63619
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain m.gmane.org designates 80.91.229.3 as permitted sender)
To: internals@lists.php.net
Date: Thu, 25 Oct 2012 04:19:58 -0600
Lines: 82
Message-ID: <k6b3of$rt5$1@ger.gmane.org>
References: <CAB75mSX-cMqZPTfv2vc8fakD_pr31qPR+kO5_O=zYiVoy4xH2w@mail.gmail.com> <CAL+t6cF=e_55=v9bZVy7Tv=V3M4CUQLueu=b5Efa+MD0ewG_qA@mail.gmail.com> <CAB75mSVg10VURjFmOhNQk87CqVP9FOQmcSzzgfMUTEb6S7WvxQ@mail.gmail.com> <CAL+t6cEDORaPR5pauqDLL7vUxmL7=MiKQyD4YaLvsLXOg_kSRg@mail.gmail.com> <CAKOpQSwsNWkrN13LTJgWDqK+JVNZHCo==PJ7GFYAR5djE+TUMw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0
In-Reply-To: <CAKOpQSwsNWkrN13LTJgWDqK+JVNZHCo==PJ7GFYAR5djE+TUMw@mail.gmail.com>
Subject: Re: [PHP-DEV] Changing the default value of "true" for CURLOPT_SSL_VERIFYHOST
From: fullmoon@newsguy.com (crankypuss)

On 10/25/2012 12:36 AM, Kris Craig wrote:
> On Wed, Oct 24, 2012 at 11:21 PM, Sherif Ramadan <theanomaly.is@gmail.com>wrote:
>
>> On Thu, Oct 25, 2012 at 1:46 AM, JJ <jawed@php.net> wrote:
>>> On Wed, Oct 24, 2012 at 10:34 PM, Sherif Ramadan
>>> <theanomaly.is@gmail.com> wrote:
>>>> I understand there are people out there that don't read the
>>>> documentation and aren't aware of the difference between
>>>> curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); and curl_setopt($ch,
>>>> CURLOPT_SSL_VERIFYHOST, true); but still... I don't think this is a
>>>> good idea either.
>>>
>>> I highly doubt code that sets CURLOPT_SSL_VERIFYHOST => true meant to
>>> imply CURLOPT_SSL_VERIFYHOST => 1...which essentially bypasses host
>>> verification.
>>
>> That's not our place to start guessing what the user did or did not
>> intend. The fact remains that a cast of a boolean true to int is in
>> fact 1. The fact also remains that CURLOPT_SSL_VERIFYHOST expects an
>> int as per the documented behavior. The fact additionally remains that
>> no user would expect var_dump((int) true) to return int(2).
>>
>>>
>>> According to libcurl, CURLOPT_SSL_VERIFYHOST => 1 is "not ordinarily a
>>> useful setting".
>>>
>>
>> Again, you're confusing users who don't read documentation and/or
>> don't understand it with users who may have fully read documentation
>> and understood it perfectly well and ever intention of setting
>> CURLOPT_SSL_VERIFYHOST to 1.
>>
>> I understand your intentions here are good, but we should not be
>> magically trying to guess what the user wants. We should document the
>> behavior clearly and this solution makes documentation completely
>> unclear. Nowhere in the PHP manual do we say "we might break the
>> promise of a boolean cast to int and make it int(2) instead of
>> int(1)".
>>
>>> - JJ
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> Correct me if I'm wrong, but 2 is already the default value, right?  I've
> also seen plenty of cases where TRUE is mistakenly used instead of 2.  I
> would also agree that this behavior is somewhat counter-intuitive.
>   However, I think we'd be opening a can of worms if we started making
> arbitrary tweaks to change the documented behavior of third-party
> libraries.  I think you do make a very good case for changing this
> behavior, but that case would (in my opinion, at least) need to be made to
> the folks over at libcurl, not here.
>
> That said, I can't think of any rational use-case for passing TRUE instead
> of 1.  Every time I've seen this, the intended behavior was 2.
>
> What if, instead of changing the behavior, we have it throw a notice or
> warning if a boolean value is passed here?  Because this is such a common
> error, I think it could be really beneficial in helping developers catch
> this early.  Thoughts?
>
> --Kris
>

So you propose to implement strict type checking of parameters because a 
few bozos don't read the documentation?  That doesn't make much sense to me.

What makes more sense is that the extension perform its own type 
checking where that is appropriate.  I have plenty of subroutine code 
that checks what it was passed, it isn't difficult to do the job right 
instead of twiddling the language every time somebody complains.

And by the way, is there any effort in-progress to make the basic 
subroutine calls more uniform, or are is_array() and isset() and friends 
going to forever remain underscore versus non-underscore?

Perhaps I have no clue, but it sounded as though the language was to be 
changed to "fix" an error in an extension, 'scuse me if I'm talking out 
of my nether orifice.