It removes trailing spaces. It's not supposed to remove leading spaces.
Zeev
At 16:10 13/7/2001, void wrote:
$littlelist[$i][1] = whatever
the command in the subject line doesn't work !
it does not get rid of the spaces in the $littlelist[$i][1] var.
or is it just me ..?
i would
It's not a dead issue, James is still on vacation (I think). He'll draft
something up when he comes back.
Zeev
At 11:57 16/7/2001, Joey Smith wrote:
Is this a dead issue, or were we ever going to finish this? Is James
still gone on vacation?
On Tue, 10 Jul 2001, Zeev Suraski wrote
administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact
Sorry for the 2nd typo - Jeroen :)
At 17:09 16/7/2001, [EMAIL PROTECTED] wrote:
ID: 10721
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Closed
Bug Type: Scripting Engine problem
Operating System: GNU/Linux
PHP Version: 4.0.6
Assigned To: jeroen
New Comment
Sounds like a broken build to me. Any chance you switched between debug
and non-debug recently? Try a clean build...
Zeev
At 11:21 17/7/2001, Joey Smith wrote:
I'm getting the following error trying to compile latest CVS:
undefined reference to `_zval_ptr_dtor_wrapper'
This appears a number
. *
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL
That's not what I asked :) I played with this code (a bit) a couple of
days ago. Can you verify whether this problem is happening in the old
(say, 4.0.6) version..?
At 22:49 17/07/2001, Andrei Zmievski wrote:
On Tue, 17 Jul 2001, Zeev Suraski wrote:
Is that a new problem related to your
I found the problem, trying to figure out a fix.
Zeev
At 22:16 17/07/2001, Andrei Zmievski wrote:
I updated from Zend CVS today, and recompiled everything freshly. Ran
into a problem with the following:
?php
class matcher {
var $arg_types = array();
function get($type
No good reason for that. When I wanted to change that, it was already too
late in the game.
It'd probably make good sense to add a mysql_get_field_name_ex() which
returns a more accurate value.
Zeev
At 00:37 19/07/2001, Cynic wrote:
Hi there,
could anyone tell me what is the reasoning
I think it'd break a huge amount of scripts, which is why I didn't even do
it in the 3.0-4.0 move.
Zeev
At 00:55 19/07/2001, Cynic wrote:
Hi Zeev,
thanks for the prompt reply. I don't think another function
is necessary if this gets changed in 4.1. what do you think?
could you add
(or not) this change
would be if you asked in php-general@. I could do it if you're
interested.
At 23:56 7/18/2001, Zeev Suraski wrote the following:
--
I think it'd break a huge amount of scripts, which is why I didn't even
do it in the 3.0
or .htaccess.
Zeev
At 10:49 19/07/2001, J. Jones wrote:
I am not subscribed to this list, so please CC: or reply directly to me.
Thanks!
I may be doing something wrong.. I'm not real sure. Neither $argc or $argv
seem to be registered with the cgi version of php 4.0.6 and up.
The test script:
?php
It's kind-of odd that you use this function in a module, it's not really an
API function that's useful outside the context of the engine. Are you sure
that's the right thing to do in there..?
Zeev
At 11:58 19/07/2001, Marc Boeren wrote:
Hi,
If I build the dbx module I get the following
Yes, just use the same zval *, increase refcount accordingly, and set the
is_ref bit. It'd be much faster (and also more correct) than using the
assign_to_variable_reference() function...
Zeev
At 12:30 19/07/2001, Stanislav Malyshev wrote:
MB I want the fieldname to be a true reference
have to set is_ref once.
(b) If you don't increase the refcount, the behavior is undefined, and is
likely to end up crashing PHP. Not increasing refcount may actually give
you the same behavior as setting is_ref to 1, but it would crash, sooner or
later.
Zeev
--
PHP Development Mailing List
to each other (changing one will
change the other), you need to set is_ref to 1. Otherwise, you don't. In
any case, you must update the refcount.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
debugging capabilities to performance, so we do perform
these checks.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
till the last connection is closed.
( 8 hours after a pconnect ).
Huh? If we are talking about Apache on any UNIX platform then there are
no threads.
True, but it doesn't change much in the explanation...
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL
Sure, [EMAIL PROTECTED]
At 23:39 19/07/2001, James E. Flemer wrote:
Are (any of) the Zend lists public? (either to browse or
submit.)
-James
On Thu, 19 Jul 2001, Zeev Suraski wrote:
Language-level things like this one are being discussed at
[EMAIL PROTECTED] This feature was actually
branch, fix also the 4.0.6 branch, so that we at least can check out
one version back. What do you guys think?
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators
buffering mechanism instead, which should make it work with output
compression automatically. I could be wrong about this though, I haven't
actually looked into it.
Zeev
At 11:19 20/07/2001, Björn Schotte wrote:
Hi,
we're using
zlib.output_compression = On
e.g. transparent gzip output
The status is don't hold your breath waiting for it :)
At 01:47 21/07/2001, Holger Zimmermann wrote:
Hi,
what's the current status of the piece of code responsible for indent mode
output
in the CGI sapi?
This snippet is from function main()
#if 0
/* Zeev might want to do
else has any thoughts about this...
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List
concrete needs from
us (as in the PHP group), let us know.
Zeev
At 14:47 22/07/2001, Michael Glazer wrote:
Your right.
Its no big deal. My tactics have failed. I'm beyond that I don't expect
anything else.
What concerns me at this point is the attitude of you folks its pretty
endearing and warm
,
$HTTP_GET_VARS, and so forth. As of PHP 4.0.3 (IIRC), these variables are
always defined, and are protected (to a degree) by PHP. Setting
register_globals to off effectively prevents any outer access to your
namespace, outside $HTTP_*_VARS[].
Zeev
At 12:28 24/07/2001, PHP wrote:
Hey all,
I
, that it probably should be changed not to be the
default. I will raise this issue soon, after making some improvements to
PHP, which would make working with register_globals off a bit more easy
than it is today.
Zeev
At 06:07 25/07/2001, Andy wrote:
If register_globals = off is highly recommended
is not able to handle this,
he is not able to write scripts if register_globals is turned off
too
- Peter
--
*ZIMT - where PHP meets needs*
Homepage: www.cyberfly.net - [EMAIL PROTECTED]
PHP Usergroups: www.phpug.de - [EMAIL PROTECTED]
Just for Fun: www.fist-center.de - [EMAIL PROTECTED]
--
Zeev Suraski
don't think that this arguments holds much water, as register_globals is
the mother of many many security bugs, found in the most popular PHP apps
out there. We need to find a way to access form variables easily, but
without encouraging insecure coding, the way we do now.
Zeev
--
PHP
=on attacks, we can't (shouldn't) blame the whole world,
but fix the language instead.
Zeev
At 10:49 25/07/2001, Brian Tanner wrote:
I'm gonna have to go ahead and agree with Peter. As a relative Newbie to
PHP (1 year), I can tell you that when I switched from Perl to PHP, one of
the biggest Wow
No obscure %$!@*% variables was one of our main design goals in PHP, only $
for denoting variables. This one is here to stay :)
At 14:58 25/07/2001, PHP wrote:
On Tue, Jul 24, 2001 at 08:27:21PM -0700, Zeev Suraski wrote:
Setting register_globals to off (which is highly recommended) would
,
which is why I agree that the language is at fault. Of course, declaring
and not initializing your variable is still a programming error, but it's
much less severe and much less prone to exploits than this problem.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e
of this not caught by E_NOTICE are difficult to come up
with.
They're trivial to come up with; Pretty much any good code (E_NOTICE free)
that doesn't take into account the fact that variables can pop out of
nowhere into your global namespace is exploitable.
Zeev
--
PHP Development Mailing
set to on
(d) Release 4.0.8 with register_globals set to off
We can (and probably should) make the E_NOTICE change at the same time.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact
.
Zeev
At 23:56 26/07/2001, Cynic wrote:
At 08:32 7/27/2001, Zeev Suraski wrote the following:
--
Zeev,
while I'll applaud to the changes you propose, I suggest this
happens in 4.1. I know, this is really a cosmetic change only,
and doesn't
denominator doesn't make since IMHO, and we should derive our
decision from a security/reliability perspective, and not the
newbie-friendliness perspective.
Zeev
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
- do you have anything to say about this?
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
, and not an opinion.
Zeev
At 03:15 27/07/2001, Björn Schotte wrote:
* Rasmus Lerdorf wrote:
significantly more secure PHP scripts out there. It will simply cause
scripts to break in non-obvious ways and the knee-jerk fix will be to
swear at those annoying PHP folks and then turn
be resolved specifically, and in my opinion, by changing the
default.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
At 03:36 27/07/2001, Zeev Suraski wrote:
Guys,
Please read the advisory. You simply can't say that register_globals=off
wouldn't have resulted in more secure apps, because there are *3* examples
(or more, I don't remember) there of applications that would have not been
exploitable had
should try to provide a
system that at least isn't prone to common, repeated and innocent looking
security bugs. PHP with register_globals=on is.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
At 20:58 02/01/1999, Peter Petermann wrote:
i dont think it is easier to write more secure applications
with turning a feature of.
Read the advisory before your next post or I'll have Kristian smack you the
next time he sees you! :)
Zeev
--
PHP Development Mailing List http://www.php.net
, will
be prone to errors (i.e., it's pretty much impossible for us to think of
everything), and I'd argue that it'd be less convenient on the long run, as
people know and expect to rely on environment/server variables.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e
and using the
parking brakes to achieve equivalent safety. It works, but it's wrong.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
it equally easy (at the least),
and old users will be made aware, quite clearly, that this feature is
unsafe. They can always turn it back on if they wish to take the
chances. Right now, we're taking the chances for them.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe
PHP
applications. Right now, PHP encourages them to write bad apps, which is a
bad thing, and gives PHP bad reputation.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list
I'm definitely in favour of that, and some of the other suggestions that
were raised. We won't be able to make all steps at once, but whomever can
contribute is obviously quite welcome to do so.
Zeev
At 04:15 27/07/2001, Björn Schotte wrote:
* Zeev Suraski wrote:
equivalent to shipping
and theoretical problems, directly related to it. That, on the other hand,
is not a matter of taste.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL
At 04:51 27/07/2001, Marc Boeren wrote:
Changing to register globals=off surely does very little in
terms of security for the easily fakeable GPC variables.
Maybe not for these variables, but other variables used in your script
cannot be faked by passing them as HTTP_POST_VARS.
e.g., with
yourself in the foot.
I also don't subscribe to the idea that it's one of the coolest features of
PHP because it's a global variable. Auto registration of form variables is
equally cool if it's made in a secure way, instead of the security pitfall
we have right now.
Zeev
--
PHP Development
At 10:26 27/07/2001, Phil Driscoll wrote:
On Friday 27 July 2001 17:35, Zeev Suraski wrote:
Have you read the advisory? That's simply not true.
Yes, and I beleive it is true in most cases.
There are two main types of security problems related to this:
(a) Ones that originate in the fact
Please hold your commits until further notice. A pretty huge mega patch is
coming, and since it touches pretty much all of PHP, I need a 'relaxed'
repository...
Thanks
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
), and obviously, solve the security issues we've been
discussing.
If we release it as 4.1.0, it's going to generate enough noise to make
people aware of this issue, which is also a good thing.
Zeev
At 10:30 27/07/2001, Rasmus Lerdorf wrote:
This is an important step, that as I said, I wanted to make
of
other apps which can also be manipulated to behave differently, and quite a
few of them can be manipulated into doing 'dangerous' things.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development
to security problems.
In a perfect world, you'd be able to address #1 and then #2 would have been
a non issue. But we're walking the Earth, and not wonderland, so I think
we should concentrate on solving #2 :)
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL
:
Zeev
If the thread safety stuff you've just committed might fiz the ISAPI
problems, and you want some testing doing, please shout out.
Cheers
--
Phil Driscoll
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http
is not. Unfortunately,
both are very common.
At 05:45 28/07/2001, Hartmut Holzgraefe wrote:
Zeev Suraski wrote:
Anyway, to be more constructive - Andi had an idea when we were catching a
cab earlier today (yesterday). His idea (which I'm just pitching, we
haven't thought this through at all yet
At 16:28 28/07/2001, Ron Chmara wrote:
On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote:
At 06:01 28/07/2001, Phil Driscoll wrote:
I and no doubt thousands of others will turn
register_globals on because it gives much more readable code, much less
typing and does not IMHO add one
(..., *), but it should display an E_NOTICE warning about
the security implications of such a move. If you really want to do it
still, you'd have to shut this warning off with a @.
Over all, I think this is much closer to what I want to see happening.
Zeev
--
PHP Development Mailing List http
At 01:04 29/07/2001, Phil Driscoll wrote:
On Saturday 28 July 2001 20:52, Zeev Suraski wrote:
a rebuf to each of my arguments :)
Rather than prolong the agony, my point is that in all the cases where a
malicious user has the chance to inject a dodgy variable, the code must
normally have a logic
it. If we end up having a semi-major version before 5.0 (which I doubt,
considering the way things are going now), we can always release 4.2.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
the simplest one to understand, and the least prone to human errors.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
that would actually be easier than the pattern matching approach,
because using this method, the users only have to change their form
handling scripts, whereas using the glob approach, they also have to change
their forms.
Zeev
At 04:20 29/07/2001, Jeffrey A.Stuart wrote:
I like this proposal a LOT
At 10:27 29/07/2001, Phil Driscoll wrote:
On Sunday 29 July 2001 17:35, Zeev Suraski wrote:
*sigh* :) As I said numerous times, PHP gives you standard clean ways to
test your variables without generating E_NOTICE's, namely, isset() (very
popular) and empty() (less popular, but available
is always never a good idea. Setting register_globals to off gives you
development-time security.
Zeev
At 11:42 29/07/2001, Stephen van Egmond wrote:
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
Think about whether in each of these cases it would have happened if the
developers of the app had
Generally I agree, except I don't think we should go as far as changing the
theme of PHP. Putting form variables into a different space would be the
simplest and equally secure way to do the trick.
At 08:32 26/07/2001, [EMAIL PROTECTED] wrote:
Hi Zeev!
On Thu, 26 Jul 2001, Zeev Suraski wrote
imagine no situation (except for laziness) that you would not
call it.
While it may be rare to find a situation in which it's useful more than
move_uploaded_file(), these cases do exist. I'm not sure what's wrong with
it, can you be more specific?
Zeev
--
PHP Development Mailing List http
At 02:40 29/07/2001, Sterling Hughes wrote:
Ahh well, I guess I'll have to commit it before the changes and then
expect Zeev and Andi to fix it :)
We have no plans to fix those, because they'd require complete rewrites :)
Zeev
--
PHP Development Mailing List http://www.php.net
,
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
At 21:34 29/07/2001, Stephen van Egmond wrote:
Zeev Suraski ([EMAIL PROTECTED]) wrote:
- register_globals=on leads to insecure code, which was demonstrated time
and time again in the past.
- Once it's off, we're going to provide methods of accessing variables
which are just as easy
functions, preferably two.
At 20:09 29/07/2001, Zeev Suraski wrote:
Guys,
Please follow the coding standards as they appear in the CODING_STANDARDS
with code you commit to the PHP repository.
Stuff I noticed while going over large portions of code in the last few days:
- open-curly-braces should
simple, and that way, it clearly isn't. If you want
three different scopes, use 3 calls. If you want register_globals-like
behavior only prefixed, use import_globals(GPC, form_). KISS should be
our guiding light here.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e
in my code.
Zeev was recently saying that he believed empty() was not as popular as
isset() - and I suspect this is the reason.
My guess is that empty() came into the language at a much later stage.
I think that empty() (for scalars) really should behave thus:
function empty($var)
{
return
wrote:
Zeev,
Since you've been updating TSRM stuff, I've noticed some
inconsistencies. For example, php_ldap.h says:
# define LDAPG(v) TSRMG(ldap_globals_id, zend_ldap_globals *, v)
But ldap_globals_id is not declared anywhere. Should it be?
-Andrei
Nobody tried to design Windows - it just grew
This one should already be fixed (update Zend)
At 07:26 30/07/2001, [EMAIL PROTECTED] wrote:
Hi Andrei!
On Mon, 30 Jul 2001, Andrei Zmievski wrote:
Zeev,
Since you've been updating TSRM stuff, I've noticed some
inconsistencies. For example, php_ldap.h says:
# define LDAPG(v) TSRMG
approach.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
.
Zeev
At 11:56 30/07/2001, Harald Radi wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi zeev,
is there a short explanation of this tsrm stuff somewhere ? i'd like to
know which kind of functions should take use of the tsrm features. while
reviewing your changes to the ext/com module i'm
error(s), 6 warning(s)
[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend
At 09:05 02/08/2001, Andrei Zmievski wrote:
On Thu, 02 Aug 2001, Zeev Suraski wrote:
It's only going to affect the TS build, so most extensions will be left
unharmed. At any rate, leaving stuff for 4.1 has always been a way of
saying 'maniana' in our group... As far as I'm concerned, we
It should be fairly easy to support both codebases by just defining the
right things depending on the API_NO. At any rate, whether we call it 4.1
or 4.0.7 doesn't really matter. It had to be done, and would involve the
same kind of issues regardless of the name.
Zeev
At 06:47 02/08/2001
?
Sometime soon :)
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
The register_globals change must go through one iteration where we have the
new APIs available, but still haven't changed the default. So, we can't
combine these two changes together...
Zeev
At 10:41 02/08/2001, Sebastian Bergmann wrote:
Zeev Suraski wrote:
- For the register_globals
number because of an
API change which is transparent to end users is a bit odd, but if most
people think otherwise, it's very much possible...
Zeev
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http
PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail
If the string functions (str*()) don't work with function names in PHP,
it's all for the better. Code that works with these function names should
only be using mem*() functions anyway, they're quicker and they're binary safe.
Zeev
At 10:22 02/08/2001, George Schlossnagle wrote:
It seem
It's only going to affect the TS build, so most extensions will be left
unharmed. At any rate, leaving stuff for 4.1 has always been a way of
saying 'maniana' in our group... As far as I'm concerned, we can just
release the current code base as 4.1.
Zeev
At 06:18 02/08/2001, Andrei
At 08:38 02/08/2001, Thies C. Arntzen wrote:
On Thu, Aug 02, 2001 at 07:09:35AM -0700, [EMAIL PROTECTED] wrote:
On Thu, 02 Aug 2001, Zeev Suraski wrote:
zeev Thu Aug 2 09:16:20 2001 EDT
Modified files:
/Zend zend.c zend_execute_API.c zend_hash.c zend_hash.h
Ok, I'll try to get source-level compatibility going next week.
Zeev
At 09:14 02/08/2001, Andrei Zmievski wrote:
On Thu, 02 Aug 2001, Zeev Suraski wrote:
At 09:05 02/08/2001, Andrei Zmievski wrote:
On Thu, 02 Aug 2001, Zeev Suraski wrote:
It's only going to affect the TS build, so most
If you register the constant with CONST_CS, it will be case
sensitive. Most of the constants in PHP are case sensitive.
Zeev
At 08:34 04/08/2001, Andrei Zmievski wrote:
Does PHP really support case-sensitive constants? PHP-GTK needs to
register both GDK_A and GDK_a constants (they define key
You can't have two constants with the same string but different case
sensitivity. It's a limitation of the current implementation.
Zeev
At 09:03 05/08/2001, Andrei Zmievski wrote:
At 06:34 PM 8/4/01 +0300, Zeev Suraski wrote:
If you register the constant with CONST_CS, it will be case
No time for this in the near future, I'm afraid :I
Zeev
At 16:58 05/08/2001, Andrei Zmievski wrote:
At 12:17 AM 8/5/01 +0300, Zeev Suraski wrote:
You can't have two constants with the same string but different case
sensitivity. It's a limitation of the current implementation.
That's exactly
I don't believe the fix is trivial at all. Hint - if it's just nuking the
strtolower there, you got it wrong :)
At 18:34 05/08/2001, Andrei Zmievski wrote:
At 05:35 PM 8/5/01 +0300, Zeev Suraski wrote:
No time for this in the near future, I'm afraid :I
Um, the fix is trivial. Want me to do
Date: Mon, 06 Aug 2001 16:07:55 +0300
To: Thies C. Arntzen [EMAIL PROTECTED]
From: Zeev Suraski [EMAIL PROTECTED]
Subject: Re: [[EMAIL PROTECTED]: Re: [PHP-DEV] incomplete class broken?]
Cc: Thies C. Arntzen [EMAIL PROTECTED], Andi Gutmans [EMAIL PROTECTED]
At 16:00 06/08/2001, Thies C. Arntzen
. dl() should most probably be
deprecated from the language, as it's not supported in thread safe mode,
it's slow and insecure. It also creates a host of interesting bugs/buglets
that are difficult to hunt and fix. Other than that - it's great :)
Zeev
At 17:22 06/08/2001, Thies C. Arntzen
At 17:42 06/08/2001, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Zeev Suraski wrote:
By the way, if it's really important, we can look into supporting it. The
way it was before - it worked in most cases (assuming you never tried to
use a class before you dl() the corresponding extension
At 17:49 06/08/2001, Stig Sæther Bakken wrote:
[Zeev Suraski [EMAIL PROTECTED]]
By the way, if it's really important, we can look into supporting it.
The way it was before - it worked in most cases (assuming you never
tried to use a class before you dl() the corresponding extension
At 17:52 06/08/2001, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Zeev Suraski wrote:
How so? I can understand that people get used to it, but it's really
bad. extensions should be loaded in the php.ini file. There's really no
good reason for using dl() over the php.ini method.
Of course
Please don't just say it's useful, please say why :)
dl() has absolutely nothing over loading in php.ini, and has many drawbacks.
Zeev
At 17:55 06/08/2001, Andy wrote:
I disagree, is there any way dl() can be fixed,
because it is a useful function...
On Mon, 06 Aug 2001, Zeev Suraski wrote
BTW, there's no good reason not to load all of the extensions you may need
in all of your scripts from php.ini. Loading many extensions doesn't pose
a significant/noticeable load. Loading using dl() does.
Zeev
At 17:52 06/08/2001, Andrei Zmievski wrote:
On Mon, 06 Aug 2001, Zeev Suraski
401 - 500 of 1273 matches
Mail list logo
