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
On Mon, May 24, 2010 at 2:12 PM, Brian Moon br...@moonspot.net 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
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
Hey Ralph
2010/5/21 Ralph Schindler ra...@smashlabs.com:
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
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 ka...@php.net wrote:
Hey Ralph
2010/5/21 Ralph Schindler ra...@smashlabs.com:
Hey all,
The first patch is against trunk. I think we should at least get this
done
hi,
On Mon, May 24, 2010 at 8:58 PM, Ilia Alshanetsky i...@prohost.org 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
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 br...@moonspot.net wrote:
+1
Brian.
http://brian.moonspot.net/
On 5/21/10 10:38
hi,
On Sat, May 22, 2010 at 4:42 PM, Ilia Alshanetsky i...@prohost.org 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
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 understanding why a parsed
url failed. That code currently does not exist, and the current warning
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
+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
11 matches
Mail list logo
