Re: [PHP-DEV] Removal of unicode_semantics
On Thu, May 8, 2008 at 7:33 AM, Andi Gutmans [EMAIL PROTECTED] wrote: So for now we should remove the switch. We can do this if needed. Who is we in this context? Zend? Scott is already working on the removal but I'll bet he would really appreciate help with it. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: snaps scripts
On Thu, 8 May 2008, Steph Fox wrote: Thanks! I wasn't aware of --enable-snapshot-build - maybe it will do everything I wanted from it, will check. Maybe we need to re-organize configure --help output to put this kind of info near the top :) Why? This is something that's not meant for users. The --help output should be for users. Although this --enable-snapshot-build should be there, it might need to go at the bottom under a new heading Developer Switches or something. Don't confuse users with switches like this, because they think it will be a good idea to use it (whatever the reason). regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 Makefile template patch.
2008/5/7 Hannes Magnusson [EMAIL PROTECTED]: On Wed, May 7, 2008 at 6:42 PM, Richard Quadling [EMAIL PROTECTED] wrote: Hi. [..] The attached patch forces the use of 'rd' rather than 'rmdir'. Only plain/text attachments get through the list.. -Hannes Basically searchreplace rmdir with rd in the win32/build/Makefile Index: Makefile === RCS file: /repository/php-src/win32/build/Makefile,v retrieving revision 1.35.2.1.2.6.2.4 diff -u -u -r1.35.2.1.2.6.2.4 Makefile --- Makefile3 May 2008 21:12:55 - 1.35.2.1.2.6.2.4 +++ Makefile7 May 2008 16:16:31 - @@ -100,15 +100,15 @@ @echo Cleaning distribution build dirs @for %D in (_x $(BUILD_DIRS_SUB)) do @if exist %D @del /F /Q %D\*.* NUL [EMAIL PROTECTED] /F /Q $(BUILD_DIR)\*.res $(BUILD_DIR)\*.lib $(BUILD_DIR)\*.ilk $(BUILD_DIR)\*.pdb $(BUILD_DIR)\*.exp $(PHPDEF) $(BUILD_DIR)\php-$(PHP_VERSION_STRING)-Win32.zip $(BUILD_DIR)\pecl-$(PHP_VERSION_STRING)-Win32.zip NUL - -rmdir /s /q $(BUILD_DIR)\php-$(PHP_VERSION_STRING) + -rd /s /q $(BUILD_DIR)\php-$(PHP_VERSION_STRING) clean-pecl: @echo Cleaning PECL targets only - -rmdir /s /q $(BUILD_DIR)\pecl + -rd /s /q $(BUILD_DIR)\pecl clean-all: @echo Cleaning standard build dirs - @for %D in (_x $(BUILD_DIRS_SUB)) do @if exist %D @rmdir /s /q %D + @for %D in (_x $(BUILD_DIRS_SUB)) do @if exist %D @rd /s /q %D [EMAIL PROTECTED] /f /q $(BUILD_DIR)\*.res $(BUILD_DIR)\*.lib $(BUILD_DIR)\*.ilk $(BUILD_DIR)\*.pdb $(BUILD_DIR)\*.exp $(PHPDEF) $(BUILD_DIR)\*.rc $(BUILD_DIR)\*.dbg $(BUILD_DIR)\*.bin $(BUILD_DIR)\php*.dll $(BUILD_DIR)\php*.exe NUL test: @@ -124,8 +124,8 @@ -for %T in ($(PECL_TARGETS)) do $(MAKE) /I /nologo %T build-dist: $(BUILD_DIR)\deplister.exe - -rmdir /s /q $(BUILD_DIR)\php-$(PHP_VERSION_STRING) - -rmdir /s /q $(BUILD_DIR)\pecl-$(PHP_VERSION_STRING) + -rd /s /q $(BUILD_DIR)\php-$(PHP_VERSION_STRING) + -rd /s /q $(BUILD_DIR)\pecl-$(PHP_VERSION_STRING) -del /f /q $(BUILD_DIR)\php-$(PHP_VERSION_STRING)-Win32.zip -del /f /q $(BUILD_DIR)\php-debug-pack-$(PHP_VERSION_STRING)-Win32.zip -del /f /q $(BUILD_DIR)\pecl-$(PHP_VERSION_STRING)-Win32.zip -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Couple Windows build fixes
Hi all, Thanks guys and gals! (Steph, you're funny. ;o)) Yeah, I didn't get any karma after my account was approved a few weeks ago, though I told Marcus I'd been making random changes all across the PHP source, so would need access to php-src and ZendEngine2... But I didn't expect that to just be given right away, so I didn't want to bug anyone (more) about it. Luckily my first two simple commits worked without wiping out the entire history of PHP or anything. :-O BTW, if I had karma for Zend stuff, I guess I could fix Bugs #44681 and #44830, assuming my proposed fixes are acceptable (should I have marked them Verified?). And speaking of bugs, I wasn't sure if I should close #44767 as Bogus, for example. Maybe I will in a few days unless I'm told not to. :-) Thanks again, Matt - Original Message - From: Steph Fox Sent: Wednesday, May 07, 2008 Then we'd better ask for him. Matt's been pushing patches all across the PHP source (if mostly at the Zend Engine) for ages. He comes and goes, but pretty much all of his patches were subsequently accepted. I don't recall off-hand which bits of the source he was given karma for a few weeks ago, but it's downright weird that it was ever limited. He never asked. Steph Fox wrote: Hi Hannes, CVS HEAD wasn't updated yet with the Windows build system because I was waiting for re2c development to settle down first, given that there was no re2c binary available that PHP could be built with at all for several weeks. But I agree with you, Matt should've been given access to everything from Day One, we all know he's brilliant :) - Steph - Original Message - From: Hannes Magnusson [EMAIL PROTECTED] To: Matt Wilmas [EMAIL PROTECTED] Cc: internals@lists.php.net Sent: Wednesday, May 07, 2008 9:16 PM Subject: Re: [PHP-DEV] Couple Windows build fixes Could someone explain to me why he doesn't have karma? -Hannes On Wed, May 7, 2008 at 5:28 PM, Matt Wilmas [EMAIL PROTECTED] wrote: Hi, One patch for 5.3 and one for HEAD, where they're not synched with the other. 5.3's math changes the other day missed one change to the php_* function (snaps are failing). And HEAD's Win Makefile still contains references to flex.skl after the re2c change, which causes an error for me, though its snaps are building, so maybe I'm the only one? - Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Removal of unicode_semantics
See below: -Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED] Sent: Thursday, May 08, 2008 12:23 AM To: Andi Gutmans Cc: Andrei Zmievski; PHP Developers Mailing List Subject: RE: [PHP-DEV] Removal of unicode_semantics Scott is already working on this AFAIK. And like Andrei, I'd also be against defaulting to binary strings. Great. Dmitry can help out if needed. He'll be reviewing it anyway. I understand you are against it but as we discussed on this list a few months ago we will have to see what reality delivers when people actually start migrating applications. It's not something we should decide at this point before we are any smarter. For now we can definitely keep as Unicode and we'll learn how that works during the alpha/beta cycles. We do owe our users a feasible upgrade path whether it's with automated scripts or some other way. As we figure that out it'll become more apparent what makes sense. Andi
Re: [PHP-DEV] Win32 Makefile template patch.
Hi Richard, Basically searchreplace rmdir with rd in the win32/build/Makefile Why? rd's just an alias of rmdir, and rmdir's the more human-readable of the two. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 Makefile template patch.
2008/5/8 Steph Fox [EMAIL PROTECTED]: Hi Richard, Basically searchreplace rmdir with rd in the win32/build/Makefile Why? rd's just an alias of rmdir, and rmdir's the more human-readable of the two. - Steph If only I could send the sound of my shoulders slumping as yet another post is ignored/filtered. http://news.php.net/php.internals/37517 I truly believe that no one on this list reads my emails or automatically filters them. If you want to just f*ck off, then say so. As I said in the original post, if you have cygwin installed (as was needed to build the PHP documentation in the bad old days before phd), then rmdir.exe would be in your path). It seems that nmake follows the path BEFORE using the shell. My proof is that cygwin's rmdir.exe is executed. If I rename it then the shell's rmdir is used. Revert the rename and cygwin's rmdir.exe is executed. Simple. cygwin's rmdir.exe doesn't support /s or /q so this when you try to run nmake clean() you get an error from rmdir.exe and no cleaning. I could rename cygwin's rmdir, but then all my script relying on rmdir.exe's behaviour fail (windows rd doesn't support --parents --ignore-fail-on-non-empty, etc). By using rd, this isn't found in the path by nmake and runs correctly with the windows/dos options. You can use filemon to see nmake hunting for rmdir.xxx where xxx is the contents of PATHEXT in each PATH. Richard. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 Makefile template patch.
If only I could send the sound of my shoulders slumping as yet another post is ignored/filtered. http://news.php.net/php.internals/37517 I only asked why :) As I said in the original post, if you have cygwin installed (as was needed to build the PHP documentation in the bad old days before phd), then rmdir.exe would be in your path). Wouldn't having /cygwin/bin permanently in your PATH screw up native executables throughout? Can you use MS rmdir on your system at all? Aren't you running vcvars32.bat before you hit nmake? Or do you have MS headers permanently in your PATH too? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Couple Windows build fixes
Matt Wilmas wrote: BTW, if I had karma for Zend stuff, I guess I could fix Bugs #44681 and #44830 You already have Zend karma. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Couple Windows build fixes
Hi Rasmus, - Original Message - From: Rasmus Lerdorf Sent: Thursday, May 08, 2008 Matt Wilmas wrote: BTW, if I had karma for Zend stuff, I guess I could fix Bugs #44681 and #44830 You already have Zend karma. I was going by your CVSROOT/avail commit, and checking the file now, it seems I only have access to Zend[Engine2]/tests. I could try commiting something (don't know if there's another way for me to check), but I didn't expect that it would work. Maybe you just changed the wrong section...? :-) Ahh, just before I sent this, I see you changed it. Cool, thanks. Thanks, Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Supporting External Authentication in the Oracle OCI8 Extension
I've had a couple of recent requests for the OCI8 extension to support External Authentication (aka OS authentication). I also recall a discussion or two in the past, and there is at least one bug logged on it. Having external authentication would allow things like Kerberos to be used for OCI8 authentication. This need is clearly growing but I'm not in favor of having it always enabled in every web environment - I feel another php.ini parameter looming :( If anyone wants to be throw in some comments or help me re-evaluate the pros and cons, drop me a line. Some Oracle documentation discussing External Authentication is in: http://download.oracle.com/docs/cd/B28359_01/network.111/b28531/authentication.htm#CHDEGIFB Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] allow_call_time_pass_reference
Hi all, Following a long and fairly embarrassing exchange of views with one of my php|architect authors, I finally discovered that allow_call_time_pass_reference is still on by default in PHP_5_3 (d'oh). This makes no sense to me because: - it throws an E_DEPRECATED warning, which nobody will see during development because - it's a PHP_INI_SYSTEM|PHP_INI_PERDIR setting that is switched on by default and - on production sites, where it should be switched off, E_DEPRECATED is fairly likely to go unreported - we've been advising people to switch it off for over 8 years Does anyone have a good reason for keeping it switched on by default in PHP 5.3? Like, would switching it off by default break a lot of existing code, given that most users are a bit beyond PHP 3 now? If not, there's a trivial patch attached for main.c and both php.ini-* files. As an aside, by-ref is actually faster than by-value under Windows in my tests, for small amounts of data. That was what you might call an unexpected result - it definitely isn't the case under *nix, or with very large arrays. - Steph Index: php.ini-dist === RCS file: /repository/php-src/php.ini-dist,v retrieving revision 1.231.2.10.2.22.2.6 diff -u -r1.231.2.10.2.22.2.6 php.ini-dist --- php.ini-dist7 Apr 2008 21:24:04 - 1.231.2.10.2.22.2.6 +++ php.ini-dist8 May 2008 18:45:44 - @@ -164,12 +164,12 @@ ; at function call time. This method is deprecated and is likely to be ; unsupported in future versions of PHP/Zend. The encouraged method of ; specifying which arguments should be passed by reference is in the function -; declaration. You're encouraged to try and turn this option Off and make +; declaration. You're encouraged to try and keep this option Off and make ; sure your scripts work properly with it in order to ensure they will work ; with future versions of the language (you will receive a warning each time ; you use this feature, and the argument will be passed by value instead of by ; reference). -allow_call_time_pass_reference = On +allow_call_time_pass_reference = Off ; ; Safe Mode Index: php.ini-recommended === RCS file: /repository/php-src/php.ini-recommended,v retrieving revision 1.179.2.11.2.23.2.6 diff -u -r1.179.2.11.2.23.2.6 php.ini-recommended --- php.ini-recommended 7 Apr 2008 21:24:04 - 1.179.2.11.2.23.2.6 +++ php.ini-recommended 8 May 2008 18:46:09 - @@ -104,10 +104,6 @@ ; are emitted for non-critical errors, but that could be a symptom of a bigger ; problem. Most notably, this will cause error messages about the use ; of uninitialized variables to be displayed. -; - allow_call_time_pass_reference = Off [Code cleanliness] -; It's not possible to decide to force a variable to be passed by reference -; when calling a function. The PHP 4 style to do this is by making the -; function require the relevant argument by reference. ; - short_open_tag = Off [Portability] ; Using short tags is discouraged when developing code meant for redistribution ; since short tags may not be supported on the target server. @@ -213,7 +209,7 @@ ; at function call time. This method is deprecated and is likely to be ; unsupported in future versions of PHP/Zend. The encouraged method of ; specifying which arguments should be passed by reference is in the function -; declaration. You're encouraged to try and turn this option Off and make +; declaration. You're encouraged to try and keep this option Off and make ; sure your scripts work properly with it in order to ensure they will work ; with future versions of the language (you will receive a warning each time ; you use this feature, and the argument will be passed by value instead of by Index: main/main.c === RCS file: /repository/php-src/main/main.c,v retrieving revision 1.640.2.23.2.57.2.21 diff -u -r1.640.2.23.2.57.2.21 main.c --- main/main.c 22 Mar 2008 12:56:16 - 1.640.2.23.2.57.2.21 +++ main/main.c 8 May 2008 18:46:21 - @@ -370,7 +370,7 @@ PHP_INI_ENTRY_EX(highlight.keyword, HL_KEYWORD_COLOR, PHP_INI_ALL,NULL, php_ini_color_displayer_cb) PHP_INI_ENTRY_EX(highlight.string, HL_STRING_COLOR, PHP_INI_ALL,NULL, php_ini_color_displayer_cb) - STD_PHP_INI_BOOLEAN(allow_call_time_pass_reference, 1, PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateBool, allow_call_time_pass_reference, zend_compiler_globals, compiler_globals) + STD_PHP_INI_BOOLEAN(allow_call_time_pass_reference, 0, PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateBool, allow_call_time_pass_reference, zend_compiler_globals, compiler_globals) STD_PHP_INI_BOOLEAN(asp_tags, 0,
Re: [PHP-DEV] allow_call_time_pass_reference
On Thu, 2008-05-08 at 20:28 +0100, Steph Fox wrote:
...
Does anyone have a good reason for keeping it switched on by default in PHP
5.3? Like, would switching it off by default break a lot of existing code,
given that most users are a bit beyond PHP 3 now?
Well, I can at least comment on how it is used in the code that
I inherited. First it must be noted that the following throws
a fatal error:
function f($x=5) {
There are functions in our application that will use information
if it is available and update the information if it is provided,
but don't absolutely require such information in the first place.
I don't know of another clean way to do that besides call-time
pass-by-reference. Here is a useless example of the functionality.
(This is an example, and only an example. In the event of real
code, something useful would be accomplished. ;) )
?php
// $x is sometimes received by reference
function f($x=5) {
if ($x 10) {
print blue\n;
$x += 10;
$retval = true;
} else {
print green\n;
$x += 20;
$retval = false;
}
return $retval;
}
f();
f(10); // In this case info is provided, but the update is discarded
$y=5;
f($y);
f($y);
?
Without call-time pass-by-reference, that becomes:
function g($x) {
if ($x === null) {
$x = 5;
}
if ($x 10) {
print blue\n;
$x += 10;
$retval = true;
} else {
print green\n;
$x += 20;
$retval = false;
}
return $retval;
}
$y = null;
g($y);
$y = 10;
g($y);
$y=5;
g($y);
g($y);
So, without call-time pass-by-reference, if blocks would be
needed to set defaults and temp variables would be needed
anywhere an rvalue is used as an argument. It's true that
the former has more opportunities for design error and without
the comment about $x being received by reference there could
be confusion, but going back and changing all that code is not
desirable. Easier to read is always a tricky argument, but
I'm sure many would find the first code above easier to read.
- Todd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_call_time_pass_reference
Hi! I think we also had a proposal back then to have func_gets_arg[s] ability to accept params by reference, and it should help with some scenarios. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_call_time_pass_reference
Hi Todd, Well, I can at least comment on how it is used in the code that I inherited. Thanks for that. Just to be very clear, I'm not talking about removing it (even though it's been marked deprecated for 8 years plus). I'm just talking about switching it off by default. It's been turned off by default in php.ini-recommended since PHP 4.0, but never in php.ini-dist or in the source. In PHP 5.3 we have better support for PHP_INI_DIR, so it'd probably make better sense to do it now than before. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_call_time_pass_reference
Hi Stas, I think we also had a proposal back then to have func_gets_arg[s] ability to accept params by reference, and it should help with some scenarios. Sorry, I failed to parse that. What would help with some scenarios? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_call_time_pass_reference
On Thu, May 8, 2008 at 10:08 PM, Todd Ruth [EMAIL PROTECTED] wrote:
On Thu, 2008-05-08 at 20:28 +0100, Steph Fox wrote:
...
Does anyone have a good reason for keeping it switched on by default in PHP
5.3? Like, would switching it off by default break a lot of existing code,
given that most users are a bit beyond PHP 3 now?
Well, I can at least comment on how it is used in the code that
I inherited. First it must be noted that the following throws
a fatal error:
function f($x=5) {
No it doesn't.
That line does however not work exactly as you would expect..
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Supporting External Authentication in the Oracle OCI8 Extension
On Thu, May 8, 2008 at 2:02 PM, Christopher Jones [EMAIL PROTECTED] wrote: I've had a couple of recent requests for the OCI8 extension to support External Authentication (aka OS authentication). I also recall a discussion or two in the past, and there is at least one bug logged on it. Having external authentication would allow things like Kerberos to be used for OCI8 authentication. This need is clearly growing but I'm not in favor of having it always enabled in every web environment - I feel another php.ini parameter looming :( If anyone wants to be throw in some comments or help me re-evaluate the pros and cons, drop me a line. Some Oracle documentation discussing External Authentication is in: http://download.oracle.com/docs/cd/B28359_01/network.111/b28531/authentication.htm#CHDEGIFB Chris Hi Chris, That's interesting but the scenario that is becoming more common and is the case I'm interested in is using an existing credential to initiate authentication with Oracle. For example, using our extension a PHP script can acquire a Kerberos credential either through delegation (eg. during SPNEGO authentication), explicitly with a username and password (ie. get a TGT) or implicitly from the HTTP service account keytab file. The mod_auth_kerb module for Apache can also save the user's delegated Kerberos credential if present. Then Kerberos aware clients (e.g. pgsql_connect) look at the KRB5CCNAME environment variable and use that ccache file to acquire credentials for the desired resource. Does the PHP oci8 extension handle this scenario? Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_call_time_pass_reference
On Thu, May 8, 2008 at 9:28 PM, Steph Fox [EMAIL PROTECTED] wrote: Does anyone have a good reason for keeping it switched on by default in PHP 5.3? Like, would switching it off by default break a lot of existing code, given that most users are a bit beyond PHP 3 now? I've never understood the warning that switch throws: [EMAIL PROTECTED]:~$ php -dallow_call_time_pass_reference=0 -r 'strpos($var, 0);' Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of strpos(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. in Command line code on line 1 However, turning it on will not throw any warning or deprecated notice, wtf? I'd say throw the warning if the switch is on and someone does call-time-pass-by-reference and turn that switch off by default. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_call_time_pass_reference
On Thu, 2008-05-08 at 22:58 +0200, Hannes Magnusson wrote:
On Thu, May 8, 2008 at 10:08 PM, Todd Ruth [EMAIL PROTECTED] wrote:
On Thu, 2008-05-08 at 20:28 +0100, Steph Fox wrote:
...
Does anyone have a good reason for keeping it switched on by default in PHP
5.3? Like, would switching it off by default break a lot of existing code,
given that most users are a bit beyond PHP 3 now?
Well, I can at least comment on how it is used in the code that
I inherited. First it must be noted that the following throws
a fatal error:
function f($x=5) {
No it doesn't.
That line does however not work exactly as you would expect..
Quite right. I should have said leads to fatal errors.
It doesn't throw a fatal error on it's own, but if you have old
code that you must maintain in which a function is sometimes called
as f(), sometimes called as f(10), and sometimes called as f($y),
trying to fix it with the declaration above will lead to fatal
errors for the f(10) calls. (The defaulting part isn't the
problem for that case; it's using a non-variable when a reference
is needed that leads to the fatal error.)
BTW, in php4, there was an incentive to use call-time
pass-by-reference. Calling f(g()) was a very bad thing if
f always accepted its parameter by reference. There are a number
of other similar cases. In php5 (and the last few releases of
php4), it's still bad, but at least memory doesn't get
corrupted now. In contrast, not declaring f to accept its
parameter by reference and instead using call-time
pass-by-reference was (and is) safe (though deprecated).
- Todd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removal of unicode_semantics
The easiest thing would be just to default unicode_semantics to On internally and hide it from users. Don't remove all the UG(unicode) checks yet, because we can test migration/compatibility with those in place. -Andrei Derick Rethans wrote: On Wed, 7 May 2008, Andi Gutmans wrote: Yep, we said that we'd remove the switch. Then we'd see how compatibility fairs and if we discover the upgrade path is too painful we'd consider making be binary string and require u for Unicode strings. But this was TBD depending on people's experiences and our ability to deliver an easy migration path for applications. So for now we should remove the switch. We can do this if needed. Scott is already working on this AFAIK. And like Andrei, I'd also be against defaulting to binary strings. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_call_time_pass_reference
Steph Fox wrote:
Hi all,
Does anyone have a good reason for keeping it switched on by default in
PHP 5.3? Like, would switching it off by default break a lot of existing
code, given that most users are a bit beyond PHP 3 now?
As a new PHP extension author, it was one the first things I had to
make sure was enabled to avoid the warning. The extension has over 150
server API functions exposed and a majority have a C/C++ prototype of:
BOOL func(input, output);
So our C/C++ to converter make them pass back structures as arrays, for
example:
boolean wcLookupName(string name, TUserInfo uinfo);
But because of this issue, we are slowing making functions return
results as array:
TUserInfo wcLookupName(string name);
In many cases, it makes sense to have both, but I also think the former
allows for easier programming:
if (!wcLookup(hector, $uinfo)) {
die(error);
}
as opposed to:
if (($uinfo = wcLookup(hector) === null) {
die(error);
}
Six in one
May I suggest to make it [Extension] INI ready?
I explored this and it seem to work, but not sure if its really the
case. It appears that adding it in my PHP.INI [extension_name] section
appears to enabled the option only when the extension is loaded.
--
Hector
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_call_time_pass_reference
Hi Hector, As a new PHP extension author, it was one the first things I had to make sure was enabled to avoid the warning. huge snip / May I suggest to make it [Extension] INI ready? I explored this and it seem to work, but not sure if its really the case. It appears that adding it in my PHP.INI [extension_name] section appears to enabled the option only when the extension is loaded. The more I look into this, the weirder it seems. The first issue that we raised was changing the E_NOTICE error for call-time-pass-by-reference to an E_ERROR, or simply throwing a parse error. We argued over this case and we decided to change this E_NOTICE to an E_STRICT instead as it was argued that there is nothing wrong with doing a call-time pass by reference. http://php.net/~derick/meeting-notes.html#deprecated-behaviour There's nothing wrong with it? So why throw an error at all? I have to say, I'm really confused over this. Either it's wrong, so you deliver a warning, or it's OK, so you don't. But what *really* bothers me is that the community seems to be under the impression that the rules changed with PHP 5, which is absolutely untrue. This threw an E_NOTICE under PHP 4.0 which has been shifted, first to E_STRICT (I haven't checked this) and then to E_DEPRECATED in 5.3. All I know is it's slower in most (not all) situations. So the real question is: should there be a warning at all? And if so, shouldn't it be there by default? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
