[PHP-DEV] CVS Account Request: cappa
Maintaining www.php.net -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Mandatory File Locking in PHP?
So, as of now, do we restrict PHP script to use only advisory file locking? Thanks, Ananth. George Schlossnagle [EMAIL PROTECTED] 01/30/03 06:54AM On Wednesday, January 29, 2003, at 07:11 PM, Marcus Börger wrote: The real question is why you need mandatory locks and not advisory locks. If everyone is playing on the same team, advisory locks should provide all the semantics you need (and are very portable). Mandatory locks (on linux at least) require not only special mount options, but special perms to the file (g-x, g+s, I believe). That seems like a lot to require inside an extension. The dba solution so far is based on flock() and where not appropriate use fctnl(). I tried to have the lock stuff working on as many systems as possible. Right. Both of these are pretty portable, one being present on all BSD-style systems and the other on POSIX systems. They are also advisory locks. Mandatory locks actually prevent read and write calls from _anyone_ else succeeding on that file. On linux, mandatory locks are set with fcntl, but it's not part of the standard POSIX standard. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why i believe we need final
MB If you want real life examples (and surely it seems you will never MB trust me) get yourself a book from scott meyers (going to my I would certainly trust you if you gave me an example. Marcus, I'm not here to personally attack you. I just do not see the value of this feature. If you do - why not enlighten me? I submit that if an idea has a value, there ought to be a way to show others that value - or at least to try it, including providing examples on how this idea should be useful. Referring me to textbooks on OO is not going to prove anything - I had my OO classes and I know what OO is. I just don't see how 'final' can be really useful in PHP - not in OO-textbook theorteical way, but in practice. And I believe there are more people that do think so - otherwise I would have been enlightened already by someone who sees the practical use of it. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] system() function call: Strange error on NetWare!
Hi,
I am using the system function on NetWare. I find the following strange
error:
1. If I use single quoted strings, then I don't have any problem with
any combination of the slash.
system('sys:\system\p.nlm');// WORKS
system('sys:\\system\\p.nlm'); // WORKS
system('sys:\system\r.nlm');// WORKS
system('sys:\\system\\r.nlm'); // WORKS
2. If I use doble quoted string then it works in these cases:
system(sys:\system\p.nlm);// WORKS
system(sys:\\system\\p.nlm); // WORKS
system(sys:\\system\\r.nlm); // WORKS
3. If I use double quoted string and I use single slash and the nlm
name starts with 'n' or 'r' or 't', then the system function call fails
to load the nlm thought the nlm is present in the given location. That
is the below does not work:
system(sys:\system\r.nlm);// WORKS
This erros appears to be strange with only three letters not being
allowed. Can anyone throw some light as to what is happening here? Could
there be a mistake in the NetWare port?
I have debugged to the point that:
- In zend_execute.c, the execution comes to the execute function.
- Inside that it comes upto case ZEND_DO_FCALL:
- There is gets into the ZEND_INTERNAL_FUNCTION where it does a
ALLOC_ZVAL and INIT_ZVAL.
- Then it calls the correspoing Internal Function which in this case is
system.
- Inside the system function, if we pring the Z_STRVAL_PP(arg1), we
find that it is only contains value like sys:\system for the last case
(mentioned above) for which there is error.
Thanks,
Ananth.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] system() function call: Strange error on NetWare!
On Thu, 30 Jan 2003, Ananth Kesari wrote:
Hi,
I am using the system function on NetWare. I find the following strange
error:
1. If I use single quoted strings, then I don't have any problem with
any combination of the slash.
system('sys:\system\p.nlm'); // WORKS
system('sys:\\system\\p.nlm');// WORKS
system('sys:\system\r.nlm'); // WORKS
system('sys:\\system\\r.nlm');// WORKS
2. If I use doble quoted string then it works in these cases:
system(sys:\system\p.nlm); // WORKS
system(sys:\\system\\p.nlm);// WORKS
system(sys:\\system\\r.nlm);// WORKS
3. If I use double quoted string and I use single slash and the nlm
name starts with 'n' or 'r' or 't', then the system function call fails
to load the nlm thought the nlm is present in the given location. That
is the below does not work:
system(sys:\system\r.nlm); // WORKS
This erros appears to be strange with only three letters not being
allowed. Can anyone throw some light as to what is happening here? Could
there be a mistake in the NetWare port?
If used in a string, these characters have the following meaning:
\r = #13 (CR)
\n = #10 (LF)
\t = #9 (tab)
so that's the reason why it doesnt work.
Derick
--
-
Derick Rethans http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals http://php-mag.net/
-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] system() function call: Strange error onNetWare!
oh oh... Why didn't I think of this earlier!?:-)
Thanks anyway...
Derick Rethans [EMAIL PROTECTED] 01/30/03 03:33PM
On Thu, 30 Jan 2003, Ananth Kesari wrote:
Hi,
I am using the system function on NetWare. I find the following
strange
error:
1. If I use single quoted strings, then I don't have any problem
with
any combination of the slash.
system('sys:\system\p.nlm'); // WORKS
system('sys:\\system\\p.nlm');// WORKS
system('sys:\system\r.nlm'); // WORKS
system('sys:\\system\\r.nlm');// WORKS
2. If I use doble quoted string then it works in these cases:
system(sys:\system\p.nlm); // WORKS
system(sys:\\system\\p.nlm);// WORKS
system(sys:\\system\\r.nlm);// WORKS
3. If I use double quoted string and I use single slash and the nlm
name starts with 'n' or 'r' or 't', then the system function call
fails
to load the nlm thought the nlm is present in the given location.
That
is the below does not work:
system(sys:\system\r.nlm); // WORKS
This erros appears to be strange with only three letters not being
allowed. Can anyone throw some light as to what is happening here?
Could
there be a mistake in the NetWare port?
If used in a string, these characters have the following meaning:
\r = #13 (CR)
\n = #10 (LF)
\t = #9 (tab)
so that's the reason why it doesnt work.
Derick
--
-
Derick Rethans
http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals
http://php-mag.net/
-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] var_dump and friends dislike new style overload objects
The attached patch alters the var family of functions to be aware of the
get_class_name handler for overloaded objects.
It also checks that the object has a hash table for it's properties
before attempting to access it.
This patch is not 100% complete because it does not handle nested class
names.
I did not see a zend api function to do this, and IMO there should be
such a thing among the introspection functions in PHP 5.
Should I commit this patch?
--Wez.
Index: ext/standard/var.c
===
RCS file: /repository/php4/ext/standard/var.c,v
retrieving revision 1.155
diff -u -p -r1.155 var.c
--- ext/standard/var.c 18 Jan 2003 15:03:01 - 1.155
+++ ext/standard/var.c 30 Jan 2003 10:50:56 -
@@ -60,6 +60,8 @@ static int php_array_element_dump(zval *
void php_var_dump(zval **struc, int level TSRMLS_DC)
{
HashTable *myht = NULL;
+ char *class_name;
+ zend_uint class_name_len;
if (level 1) {
php_printf(%*c, level - 1, ' ');
@@ -93,13 +95,18 @@ void php_var_dump(zval **struc, int leve
goto head_done;
case IS_OBJECT:
myht = Z_OBJPROP_PP(struc);
- if (myht-nApplyCount 1) {
+ if (myht myht-nApplyCount 1) {
PUTS(*RECURSION*\n);
return;
}
- php_printf(%sobject(%s)(%d) {\n, COMMON, Z_OBJCE_PP(struc)-name,
zend_hash_num_elements(myht));
+
+ Z_OBJ_HANDLER(**struc, get_class_name)(*struc, class_name,
+class_name_len, 0 TSRMLS_CC);
+
+ php_printf(%sobject(%s)(%d) {\n, COMMON, class_name, myht ?
+zend_hash_num_elements(myht) : 0);
head_done:
- zend_hash_apply_with_arguments(myht, (apply_func_args_t)
php_array_element_dump, 1, level);
+ if (myht) {
+ zend_hash_apply_with_arguments(myht, (apply_func_args_t)
+php_array_element_dump, 1, level);
+ }
if (level 1) {
php_printf(%*c, level-1, ' ');
}
@@ -166,6 +173,8 @@ static int zval_array_element_dump(zval
void php_debug_zval_dump(zval **struc, int level TSRMLS_DC)
{
HashTable *myht = NULL;
+ char *class_name;
+ zend_uint class_name_len;
if (level 1) {
php_printf(%*c, level - 1, ' ');
@@ -195,9 +204,12 @@ void php_debug_zval_dump(zval **struc, i
goto head_done;
case IS_OBJECT:
myht = Z_OBJPROP_PP(struc);
- php_printf(%sobject(%s)(%d) refcount(%u){\n, COMMON,
Z_OBJCE_PP(struc)-name, zend_hash_num_elements(myht), Z_REFCOUNT_PP(struc));
+ Z_OBJ_HANDLER(**struc, get_class_name)(*struc, class_name,
+class_name_len, 0 TSRMLS_CC);
+ php_printf(%sobject(%s)(%d) refcount(%u){\n, COMMON, class_name,
+myht ? zend_hash_num_elements(myht) : 0, Z_REFCOUNT_PP(struc));
head_done:
- zend_hash_apply_with_arguments(myht, (apply_func_args_t)
zval_array_element_dump, 1, level);
+ if (myht) {
+ zend_hash_apply_with_arguments(myht, (apply_func_args_t)
+zval_array_element_dump, 1, level);
+ }
if (level 1) {
php_printf(%*c, level-1, ' ');
}
@@ -281,6 +293,8 @@ void php_var_export(zval **struc, int le
HashTable *myht;
char* tmp_str;
int tmp_len;
+ char *class_name;
+ zend_uint class_name_len;
switch (Z_TYPE_PP(struc)) {
case IS_BOOL:
@@ -319,8 +333,11 @@ void php_var_export(zval **struc, int le
if (level 1) {
php_printf(\n%*c, level - 1, ' ');
}
- php_printf (class %s {\n, Z_OBJCE_PP(struc)-name);
- zend_hash_apply_with_arguments(myht, (apply_func_args_t)
php_object_element_export, 1, level);
+ Z_OBJ_HANDLER(**struc, get_class_name)(*struc, class_name,
+class_name_len, 0 TSRMLS_CC);
+ php_printf (class %s {\n, class_name);
+ if (myht) {
+ zend_hash_apply_with_arguments(myht, (apply_func_args_t)
+php_object_element_export, 1, level);
+ }
if (level 1) {
php_printf(%*c, level - 1, ' ');
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Can't build xslt/sablot
What's doing the linking? Is it linking to lstdc++? J Sebastian Bergmann wrote: /usr/local/lib/libsablot.so: undefined reference to `operator new[](unsigned)' /usr/local/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/local/lib/libsablot.so: undefined reference to `operator delete(void*)' /usr/local/lib/libsablot.so: undefined reference to `__gxx_personality_v0' /usr/local/lib/libsablot.so: undefined reference to `__cxa_pure_virtual' /usr/local/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/local/lib/libsablot.so: undefined reference to `operator delete[](void*)' /usr/local/lib/libsablot.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' /usr/local/lib/libsablot.so: undefined reference to `operator new(unsigned)' collect2: ld returned 1 exit status make: *** [sapi/cgi/php] Error 1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build xslt/sablot
Sebast1an, On Thu, 30 Jan 2003, Sebastian Bergmann wrote: SB /usr/local/lib/libsablot.so: undefined reference to `operator new[](unsigned)' SB /usr/local/lib/libsablot.so: undefined reference to `vtable for SB __cxxabiv1::__si_class_type_info' SB /usr/local/lib/libsablot.so: undefined reference to `operator delete(void*)' SB /usr/local/lib/libsablot.so: undefined reference to `__gxx_personality_v0' SB /usr/local/lib/libsablot.so: undefined reference to `__cxa_pure_virtual' SB /usr/local/lib/libsablot.so: undefined reference to `vtable for SB __cxxabiv1::__class_type_info' SB /usr/local/lib/libsablot.so: undefined reference to `operator delete[](void*)' SB /usr/local/lib/libsablot.so: undefined reference to `vtable for SB __cxxabiv1::__vmi_class_type_info' SB /usr/local/lib/libsablot.so: undefined reference to `operator new(unsigned)' SB collect2: ld returned 1 exit status SB make: *** [sapi/cgi/php] Error 1 for some systems there seems to be a fix, when using gcc3, for some (Mac OSX) there isn't. IIC, adding -lstdc++ to ZEND_LD_FLAGS in the Makefile (to ensure -lstdc++ is the last library linked) seems to do the trick for most. -- With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build xslt/sablot
Melvyn Sopacua wrote: adding -lstdc++ to ZEND_LD_FLAGS in the Makefile (to ensure -lstdc++ is the last library linked) seems to do the trick for most. I added it to EXTRA_LDFLAGS and the problem was solved. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Mandatory File Locking in PHP?
On Thursday, January 30, 2003, at 04:28 AM, Ananth Kesari wrote:
So, as of now, do we restrict PHP script to use only advisory file
locking?
Mandatory locking is an OS thing, not a PHP userspace thing. Given
appropriate mount options on your fs (certainly out of the scope of
php's responsibility), and appropriate permissions on the file (doable
from within php of course, but seems odd to have to internally check
and chmod a file as part of a locking procedure), then fcntl locks will
be mandatory.
Assuming that your filesystem is mounted -o mand, you can just do this:
function mandatoryLock($file) {
// go through the arcane dance of setting g+s, g-x
$mode = (stat($file)[2)];
$mode = $mode ^ 0010;
$mode = $mode | 02000;
chmod($file, $mode);
// lock it
$fp = open($file, a+);
flock($fp, LOCK_EX);
}
The point I'm trying to make, is that you can already set up your
system so that you can do mandatory locks from within php (on systems
supporting it), but it is close to impossible to have php do all the
setup work for you (remounting a file system -o mand should be out of
the scope of php, imho).
George
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Thu, 30 Jan 2003, Jon Parise wrote: On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote: You're not the first to voice this opinion. *I* feel str_ireplace is better as it follows the naming convention of module_function. Others feel stri_replace is better as that follows eregi_replace's style. I have no trouble going with whatever the majority feels is best. Get rid of stri_replace() and/or str_ireplace() and just add a fourth optional parameter to str_replace() to control case-sensitivity. +1 on that. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On January 30, 2003 04:55 pm, Jon Parise wrote: On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote: You're not the first to voice this opinion. *I* feel str_ireplace is better as it follows the naming convention of module_function. Others feel stri_replace is better as that follows eregi_replace's style. I have no trouble going with whatever the majority feels is best. Get rid of stri_replace() and/or str_ireplace() and just add a fourth optional parameter to str_replace() to control case-sensitivity. +1 from me too, stri_replace sound like a function some users may have implemented them selves and we could end up breaking their code by introducing it. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: str_ireplace vs. stri_replace
Adding a parameter to an existing function is the way to go I agree. Timothy Hitchens (HiTCHO) Web Application Consulting e-mail: [EMAIL PROTECTED] -Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: Friday, 31 January 2003 8:00 AM To: Jon Parise Cc: Sara Golemon; PHP Developers Mailing List Subject: Re: [PHP-DEV] Re: str_ireplace vs. stri_replace On Thu, 30 Jan 2003, Jon Parise wrote: On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote: You're not the first to voice this opinion. *I* feel str_ireplace is better as it follows the naming convention of module_function. Others feel stri_replace is better as that follows eregi_replace's style. I have no trouble going with whatever the majority feels is best. Get rid of stri_replace() and/or str_ireplace() and just add a fourth optional parameter to str_replace() to control case-sensitivity. +1 on that. Derick -- -- --- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ -- --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Thu, 30 Jan 2003 17:11:53 -0500 Ilia A. [EMAIL PROTECTED] wrote: +1 from me too, stri_replace sound like a function some users may have implemented them selves and we could end up breaking their code by introducing it. exactly :). And why introduce function name with no respect of naming convention ? I read many times here that we do not have to do it this way O:-) anyway... pierre -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: str_ireplace vs. stri_replace
Jon Parise writes: Get rid of stri_replace() and/or str_ireplace() and just add a fourth optional parameter to str_replace() to control case-sensitivity. Yup. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
+1 from me too, stri_replace sound like a function some users may have implemented them selves and we could end up breaking their code by introducing it. exactly :). Only one complaint. Previously (including in 4.3.0) there already WAS a fourth (undocumented) parameter to str_replace. A boolean value which would allow the user to use an alternate search and replace method. True, this was undocumented, and was probably only included for developer debugging (Sascha? Can you enlighten us?). This alternate method has been removed (by virtue of being deprecated) and should produce wrong param count errors for users who include that fourth parameter currently (how many would even know of this?) so that they can fix their code. If we introduce a *new* fourth parametere (also boolean) which checks for case_sensitivity, this could potentially cause problems for users who were using this undocumented parameter. Leaving the fourth and adding a fifth would get even more confusing if the appearance is that the fourth parameter was just added *and* served no purpose. So, we could relegate those VERY few who might've used that fourth parameter already to the read the changelog or suffer bucket, ornot. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Thu, 30 Jan 2003, Sara Golemon wrote: SG +1 from me too, stri_replace sound like a function some users may have SG SG implemented them selves and we could end up breaking their code by SG introducing it. SG SG exactly :). SG SG Only one complaint. SG SG Previously (including in 4.3.0) there already WAS a fourth (undocumented) SG parameter to str_replace. A boolean value which would allow the user to use SG an alternate search and replace method. True, this was undocumented, and SG was probably only included for developer debugging (Sascha? Can you SG enlighten us?). [...] SG If we introduce a *new* fourth parametere (also boolean) which checks for SG case_sensitivity, this could potentially cause problems for users who were SG using this undocumented parameter. Leaving the fourth and adding a fifth SG would get even more confusing if the appearance is that the fourth parameter SG was just added *and* served no purpose. FWIW: Given this mess, and the fact that any php-coded stri_replace can be overloaded, I think a new function is better. Also - it's in sync with the other stri* functions. Either change all with a case-insensativity paramenter, or keep the namingconventions that 'plague' these functions. -- With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: str_ireplace vs. stri_replace
If your using an undocumented parameter, and that undocumented parameter changes what's the problem? The documentation doesn't say a word about a mystery undocumented parameter... I don't think we should be too concerned with someone using something they arguably shouldn't be. John -Original Message- From: Sara Golemon [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 30, 2003 5:39 PM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Re: str_ireplace vs. stri_replace +1 from me too, stri_replace sound like a function some users may +have implemented them selves and we could end up breaking their code by introducing it. exactly :). Only one complaint. Previously (including in 4.3.0) there already WAS a fourth (undocumented) parameter to str_replace. A boolean value which would allow the user to use an alternate search and replace method. True, this was undocumented, and was probably only included for developer debugging (Sascha? Can you enlighten us?). This alternate method has been removed (by virtue of being deprecated) and should produce wrong param count errors for users who include that fourth parameter currently (how many would even know of this?) so that they can fix their code. If we introduce a *new* fourth parametere (also boolean) which checks for case_sensitivity, this could potentially cause problems for users who were using this undocumented parameter. Leaving the fourth and adding a fifth would get even more confusing if the appearance is that the fourth parameter was just added *and* served no purpose. So, we could relegate those VERY few who might've used that fourth parameter already to the read the changelog or suffer bucket, ornot. -Pollita -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Thu, 30 Jan 2003, Melvyn Sopacua wrote: MS MS Given this mess, and the fact that any php-coded stri_replace can be overloaded, K, strike this. The tricks used by mbstring to overload functions, cannot be applied in userland alone. Sorry for the noise. -- With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
FWIW: Given this mess, and the fact that any php-coded stri_replace can be overloaded, I think a new function is better. Also - it's in sync with the other stri* functions. Either change all with a case-insensativity paramenter, or keep the namingconventions that 'plague' these functions. Aggreed! The additional parameter solution is a pure developer friendly solution. The separate function is a user friendly solution. If we would like to make all happy then add the case-insensativity parameter to all str_ (not stri_) functions and add the additional function. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question on bug list
hi, Wouldn't it be nice if one could attach himself to a bug and receive an email on every new message to that bug? And then how am i informed about new bugs? Is there a mailing list for that? Currently i read the bug-summary-list.. [EMAIL PROTECTED] Empty mail to [EMAIL PROTECTED] should do it. -daniek -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Thu, 30 Jan 2003 17:11:53 -0500 Ilia A. [EMAIL PROTECTED] wrote:
On January 30, 2003 04:55 pm, Jon Parise wrote:
On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote:
You're not the first to voice this opinion. *I* feel str_ireplace is
better as it follows the naming convention of module_function.
Others feel stri_replace is better as that follows eregi_replace's style.
I have no trouble going with whatever the majority feels is best.
Get rid of stri_replace() and/or str_ireplace() and just add a fourth
optional parameter to str_replace() to control case-sensitivity.
+1 from me too, stri_replace sound like a function some users may have
implemented them selves and we could end up breaking their code by
introducing it.
Although this is not my area of expertise, I would like to express my
negative opinion towards solving the problems with extra parameters.
Why?
1. Not all users will notice the extra parameter easily. Will take some
time.
2. If some users made their own function called stri_replace, this is
nothing that should be stopping from implementing it officially. In fact,
to fix it would be as easy as encapsuling the function declaration in
if(!function_exists('stri_replace')) {
function stri_replace($str = '') {
// ... user code
}
}
... which means acting on a centralized object - two lines of code after
an upgrade.
3. There is no reason to believe that this function was already used so
many times - as noted before, many have simply used regex. Look at this:
http://www.google.com/search?hl=enlr=ie=UTF-8oe=UTF-8q=stri_replace+-php.net
only 17 results. Of course, the use of this name might be much more, but
still - gives an idea of not such used user function.
Thus, my conclusion is that I doubt there is any gain of stability by
solving this issue with a parameter instead of an intuitive function.
--
Maxim Maletsky
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] preg_replace oddity
Can someone explain what is going on here: --- foo.php --- ?php $a = ___! 52); echo(42 !___; $b = preg_replace(/!(.*)!/e, print(\\1);, $a); print(\n---\na: $a\nb: $b\n); ? --- end --- --- output --- 52 --- a: ___! 52); echo(42 !___ b: ___1___ --- end --- I understand that one is supposed to use single quotes around the \\1 in the above preg_replace. But what happens when they do not? Clearly the echo(42); is not executed, and it is not printed by print(). Even more interesting is if you put something like echo(\42 in $a, then you get a bunch of errors including: Fatal error - Failed evaluating code: print( 52); echo(\42 ); It seems like preg_replace() is doing some strange things, and might be something that could be exploitable if a remote user can supply the first argument, and the second argument does not enclose \\n options. -James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
1. Not all users will notice the extra parameter easily. Will take some time. This modification will not appear until PHP 5 is released, by then this extra parameter (hopefully) will be well documented and people will be aware that it exists. Adding extra code, which virtually does the same thing IMHO is pointless and only creates a messy code that is difficult to maintain at a future point. 2. If some users made their own function called stri_replace, this is nothing that should be stopping from implementing it officially. In fact, to fix it would be as easy as encapsuling the function declaration in You are correct in the event of a user writing a new function, however consider what will happen if we are dealing with a old code, especially if it is no longer used just by the author but rather by a variety of other people not familiar with PHP code. The result is that after they or their ISPs upgrade to new PHP their scripts will stop working. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
Well, if you're doing that, go ahead and change stristr() and strstr() too... And eregi() and ereg()... It should be done one way or another. Besides, wasn't one of the points in introducing this function that so many users were looking for it? Jon Parise [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote: You're not the first to voice this opinion. *I* feel str_ireplace is better as it follows the naming convention of module_function. Others feel stri_replace is better as that follows eregi_replace's style. I have no trouble going with whatever the majority feels is best. Get rid of stri_replace() and/or str_ireplace() and just add a fourth optional parameter to str_replace() to control case-sensitivity. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Thu, 30 Jan 2003, Sara Golemon wrote: Only one complaint. snip So, we could relegate those VERY few who might've used that fourth parameter already to the read the changelog or suffer bucket, ornot. I think this group of people is very small (less then 10 I assume), so I dont see it as much of a problem to 're'use the 4th parameter. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On Fri, 31 Jan 2003, Derick Rethans wrote: On Thu, 30 Jan 2003, Sara Golemon wrote: Only one complaint. snip So, we could relegate those VERY few who might've used that fourth parameter already to the read the changelog or suffer bucket, ornot. I think this group of people is very small (less then 10 I assume), so I dont see it as much of a problem to 're'use the 4th parameter. Let me add that even I have never used it. It's save to redeploy. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
