I was trying to tell you 'it's a bad idea to modify it', not 'it's
impossible'. Your first post sounded like you were intending to distribute
some application!
If you look at the relevant bits of ZE you'll see that a 'modifiable' value
of NULL in the main.c declaration would do the trick.
ehl lhe schreef:
hi steph,
well, i'm trying to use apache's mod vhost_alias, which doesn't allow to use
e.g.
php_admin_value open_basedir /some/path/%2
...which means that %2 is usually replaced with a part of the requested URI,
but that does not work, such variables like %2 are interpreded
I've run into the same thing in the past, ended up moving to virtual machines
in order
to circumvent ... BUT ... I found something which can apparently work in this
particular
case. have a google for 'mod_macro' ... from what I read it will do what you
want and it'll
save you having to hack
Hi,
We are going to include your md5() implementation into php-5.3.0.
I confirm at least 25% md5() speedup on my Core2 3GHz, however license
issues are not clear.
We are going to distribute files under standard PHP license including
your original copyright notes.
The files which are going to
ehl lhe schreef:
I've run into the same thing in the past, ended up moving to virtual machines
in order
to circumvent ... BUT ... I found something which can apparently work in this
particular
case. have a google for 'mod_macro' ... from what I read it will do what you
want and it'll
save you
Hi all,
The fix to bug 37212 (http://bugs.php.net/bug.php?id=37632) introduced
an unusual method accessibility rule. A class can access a protected
method declared outside of its own direct class hierarchy if that
method has a prototype in a common superclass.
?php
class A {
static
Hi,
Don't know which mail client you're using but it hates mine... no , so I'm
resorting to separators.
==
why do you say old version?
==
Because I've been working with 5.3.0-dev since the day the branch split, and
I have a hard time remembering what was or
Hi all,
in my point view, the zend_check_protected should be used like:
http://ecl.mediain.com.br/diff/protected.diff
This patch breaks a test (Zend/tests/bug37632.phpt):
class A1
{
protected function test()
{
echo __METHOD__ . \n;
}
}
class B1 extends A1
Hi,
While doing some threaded work I noticed that tsrm_mutex_lock and
tsrm_mutex_unlock return different values for Windows and Linux (using
pthread).
Attached is the patch to make everything more pthread like, it will
return 0 for success and any other value is an error.
Windows, GNU
Dmitry,
On Tue, 2008-02-05 at 14:34 +0300, Dmitry Stogov wrote:
/*
* * This is an OpenSSL-compatible implementation of the RSA Data Security,
* * Inc. MD5 Message-Digest Algorithm (RFC 1321).
**
[...]
looks like your editor has gone wild on that comment in md5.c ;-)
johannes
--
On Sat, February 2, 2008 2:14 pm, Steph Fox wrote:
2) Maintenance status needs to be part of the equation.
3) Stability needs to be part of the equation.
4) Appropriateness to a given PHP branch needs to be part of the
equation.
5) CS and documentation need to be part of the equation.
On Mon, February 4, 2008 3:42 am, Ben Trafford wrote:
Just poking up my head to concur with Derick. What one
person thinks of as 'fashionistas', another person will think of as
absolutely core and necessary
+1
I don't think this list will ever reach concensus on what should be
in
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other bug
reports about this
On Feb 5, 2008 3:23 PM, Pierre Joye [EMAIL PROTECTED] wrote:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE.
Personally
+1
--
/Dan
Daniel P. Brown
Senior Unix Geek
? while(1) { $me = $mind--;
On Feb 5, 2008 9:23 PM, Pierre Joye [EMAIL PROTECTED] wrote:
+1: remove them (as it is now in HEAD)
-1: Restore them and always return FALSE (not 0)
0: I don't care, do what you wish, I never use them anyway
-1 (restore them) :)
-Hannes
--
PHP Internals - PHP Runtime Development Mailing
I agree +1
Regards
Marco
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Feb 5, 2008 3:26 PM, Daniel Brown [EMAIL PROTECTED] wrote:
On Feb 5, 2008 3:23 PM, Pierre Joye [EMAIL PROTECTED] wrote:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE.
Personally
XX
VOTE
Pierre Joye wrote:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other bug
On Tue, 2008-02-05 at 21:23 +0100, Pierre Joye wrote:
+1: remove them (as it is now in HEAD)
-1: Restore them and always return FALSE (not 0)
0: I don't care, do what you wish, I never use them anyway
+1 - remove them
Users can easily add these themselves, (if (!
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
+1 - remove them
--Marcelo
On Feb 5, 2008 6:47 PM, Johannes Schlüter [EMAIL PROTECTED] wrote:
On Tue, 2008-02-05 at 21:23 +0100, Pierre Joye wrote:
+1: remove them (as it is now in HEAD)
-1: Restore them and always return FALSE (not 0)
0: I don't care, do what you wish, I never use
On Fri, February 1, 2008 7:33 pm, Pierre Joye wrote:
On Feb 2, 2008 1:52 AM, Gregory Beaver [EMAIL PROTECTED] wrote:
Rasmus Lerdorf wrote:
Cristian Rodriguez wrote:
2008/2/1, Marcus Boerger [EMAIL PROTECTED]:
- Fix callable/static mess, the following will now all result
in a E_STRICT
On Feb 5, 2008 11:14 PM, Richard Lynch [EMAIL PROTECTED] wrote:
On Fri, February 1, 2008 7:33 pm, Pierre Joye wrote:
On Feb 2, 2008 1:52 AM, Gregory Beaver [EMAIL PROTECTED] wrote:
Rasmus Lerdorf wrote:
Cristian Rodriguez wrote:
2008/2/1, Marcus Boerger [EMAIL PROTECTED]:
- Fix
On Sun, February 3, 2008 7:51 pm, Stanislav Malyshev wrote:
Like I mentioned before (I think), it should not return an empty
string
of course because programmatically it's not possible to check for
this.
As most of our functions return false in those cases, so should this
function.
AFAIR
On Tue, February 5, 2008 2:38 pm, Jeremy Privett wrote:
-1: Restore them and always return FALSE (not 0)
I freely admit to not remembering a 2-year-old discussion, but it
seems to me for BC reasons you'd want to do this...
I know they've been marked deprecated and all, but, really, what's
the
I know they've been marked deprecated and all, but, really, what's
the cost/penalty to having a couple functions around for legacy apps?
Then we will continue to be at the same old issue of they exist, people will
continue to use them and never move away from them.
Mike
On 05/02/2008, Sam Barrow [EMAIL PROTECTED] wrote:
Hey, I have an idea.
We can appeal to the PHP developers to simply include the scalar type
hint.
They can't argue that this goes against type juggling, as the four
scalar types can juggle, and this allows any of them.
Anyone who is against
On Feb 6, 2008 12:02 AM, Tomi Kaistila [EMAIL PROTECTED] wrote:
No one seems to have answered my point that actually relying on type
juggling for anything other than string concatenation is asking for a
problem.
Probably because there isn't a way to answer that point. Anyone who does would
Good point. Either way the argument against it is even weaker now that
all it has are the scalar and resource types. It is now fully compliant
with PHP's type juggling system. Anyone who disagrees with a scalar
hint should probably also disagree with the array hint.
On Wed, 2008-02-06 at 01:02
On 05/02/2008, Tomi Kaistila [EMAIL PROTECTED] wrote:
No one seems to have answered my point that actually relying on type
juggling for anything other than string concatenation is asking for a
problem.
Probably because there isn't a way to answer that point. Anyone who does would
be
Tomi Kaistila wrote:
No one seems to have answered my point that actually relying on type
juggling for anything other than string concatenation is asking for a
problem.
Probably because there isn't a way to answer that point. Anyone who does would
be laughed out of the barn. Like I told Sam
2008/2/5, Pierre Joye [EMAIL PROTECTED]:
Hi,
It seems that there is voice
+1: remove them (as it is now in HEAD)
Remove them , they are of no use.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Dmitry and all,
First of all, please accept my apologies for failing to find the time to
participate in the licensing issues discussion in December. It is a
topic that I would like to discuss and arrive at a conclusion as I often
happen to write code that I'd like to release to the public
On Feb 5, 2008 5:46 PM, Mike Willbanks [EMAIL PROTECTED] wrote:
I know they've been marked deprecated and all, but, really, what's
the cost/penalty to having a couple functions around for legacy apps?
Then we will continue to be at the same old issue of they exist, people will
continue
On Tue, 2008-02-05 at 23:19 +, Richard Quadling wrote:
On 05/02/2008, Tomi Kaistila [EMAIL PROTECTED] wrote:
No one seems to have answered my point that actually relying on type
juggling for anything other than string concatenation is asking for a
problem.
Probably because there
On Wed, 2008-02-06 at 00:27 +0100, Markus Fischer wrote:
Tomi Kaistila wrote:
No one seems to have answered my point that actually relying on type
juggling for anything other than string concatenation is asking for a
problem.
Probably because there isn't a way to answer that point.
As with so many topics on this list, I have no authority to influence
the outcome. I personally think they've all got rules to instantly
delete my email (but that's cause I'm paranoid).
That's rubbish Richard - in some ways you're the most important person on
the list. Odd, eh?
I think
On Feb 6, 2008 1:01 AM, Daniel Brown [EMAIL PROTECTED] wrote:
On Feb 5, 2008 5:46 PM, Mike Willbanks [EMAIL PROTECTED] wrote:
I know they've been marked deprecated and all, but, really, what's
the cost/penalty to having a couple functions around for legacy apps?
Then we will
Hi Alexander,
Stupid question maybe, but why can't you use your given name for this?
Caveat: please don't let this email stand in the way of your giving your
gift.
- Steph
- Original Message -
From: Solar Designer [EMAIL PROTECTED]
To: Dmitry Stogov [EMAIL PROTECTED]
Cc: Stanislav
But this has been discussed to death. Please say +1/-1/0 =)
Pierre: Sorry, I didn't want to add to the noise, but for the sake of
completeness I'll give you my 0.
- Steph
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To
Daniel Brown wrote:
On Feb 5, 2008 3:26 PM, Daniel Brown [EMAIL PROTECTED] wrote:
On Feb 5, 2008 3:23 PM, Pierre Joye [EMAIL PROTECTED] wrote:
Hi,
It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE.
Personally
XX
Hi Rasmus,
On Feb 6, 2008 2:13 AM, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
Daniel Brown wrote:
On Feb 5, 2008 3:26 PM, Daniel Brown [EMAIL PROTECTED] wrote:
On Feb 5, 2008 3:23 PM, Pierre Joye [EMAIL PROTECTED] wrote:
Hi,
It seems that there is voices in favor of keeping the GPC
Hi Steph,
On Wed, Feb 06, 2008 at 12:18:37AM -, Steph Fox wrote:
Stupid question maybe, but why can't you use your given name for this?
I can, and I don't mind you replacing all occurrences of Solar
Designer with Alexander Peslyak in these two files - or would you
like me to do that myself?
iconv() will stop on conversion error and return partial string or empty
string. It will require even more complex code than 5.2.5
htmlspecialchars() does. With htmlspecialchars you check for empty string
before and after the call. With iconv you check for php errors during
iconv call.
the
45 matches
Mail list logo
