hi,
On Mon, May 24, 2010 at 8:58 PM, Ilia Alshanetsky wrote:
> I think Kalle's patch is a really good solution for the trunk. +1
Same here, with a couple of changes like killing the warning (and the
related flag) as well as removing the duplicated code. I will do that
before applying it.
Cheers
I think Kalle's patch is a really good solution for the trunk. +1
On Mon, May 24, 2010 at 8:51 AM, Kalle Sommer Nielsen wrote:
> Hey Ralph
>
> 2010/5/21 Ralph Schindler :
> >
> > Hey all,
> >
> > The first patch is against trunk. I think we should at least get this
> done
> > even if the group
Hey Ralph
2010/5/21 Ralph Schindler :
>
> Hey all,
>
> The first patch is against trunk. I think we should at least get this done
> even if the group decides that down the line we want the why portion
> explained as well (I actually don't care about the why part). That feature
> would require tha
hi,
I will apply the patch to trunk later today as it seems that we have
no objection for the patch itself. The proposal to add more
information on failure can be implemented later, if someone fills
motivated enough to do it.
Cheers,
--
Pierre
On Sat, May 22, 2010 at 5:28 PM, Pierre Joye wrot
On Mon, May 24, 2010 at 2:12 PM, Brian Moon wrote:
> Because that is, IMO, a bad precedent to start for PHP internal functions.
> Too many functions already produce warnings (fopen) and return a status that
> can be checked. The solution right now is @ and that has so much baggage
> with it that y
Because that is, IMO, a bad precedent to start for PHP internal
functions. Too many functions already produce warnings (fopen) and
return a status that can be checked. The solution right now is @ and
that has so much baggage with it that you can now disable that feature
completely making distri
hi,
On Sat, May 22, 2010 at 4:42 PM, Ilia Alshanetsky wrote:
> Instead of removing a warning, why not add an additional parameter to the
> function that would instruct it to silence warning messages on parse
> failure?
What are the actual usefulness of these warnings? I see absolutely no
need to
Instead of removing a warning, why not add an additional parameter to the
function that would instruct it to silence warning messages on parse
failure?
On Fri, May 21, 2010 at 11:55 AM, Brian Moon wrote:
> +1
>
>
> Brian.
>
> http://brian.moonspot.net/
>
>
> On 5/21/10 10:38 AM, Ralph S
+1
Brian.
http://brian.moonspot.net/
On 5/21/10 10:38 AM, Ralph Schindler wrote:
Hey all,
Attached is a patch to remove the warning from parse_url() in situations
where parse_url() cannot actually parse the url. The bug report also
claims there should be a new feature for understand
Really attached this time.
Attached is a patch to remove the warning from parse_url() in situations
diff --git a/ext/standard/tests/url/parse_url_basic_001.phpt
b/ext/standard/tests/url/parse_url_basic_001.phpt
index 3d50689..7b9d513 100644
--- a/ext/standard/tests/url/parse_url_basic_001.phpt
10 matches
Mail list logo
