Re: [PHP-DEV] Programming question
Right now, the zend_function struct contains a char *function_name but no int function_name_len. In light of the comments below, I think this is a bug, or a bug waiting to happen. George 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 sto me that there are ways of accomplishing this that allow for this without breaking compatibility of that string with standard string functions, for exampla an ANSI-like standard prohibiting userland functions begnning with __ or using a non-null, low ascii character (say 0x07). agreed, but php has been binary-safe for a looong time. and \0 is the most obvious thing to embed and show anybody (who reads the c-code) that this is only to-be used internally. I guess, but it means that it is unsafe to use the common string functions on function names in the function_table. There are valid reasons to directly access function_table in php extensions, so why severely limit the library functions you can use to manipulate function names? It just seems to me that while it may make it obvious that it's for internal use, there are better ways of doing it that still allow you to treat a string as a string in c. tc -- 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 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 PROTECTED]
Re: [PHP-DEV] Programming question
On Thu, Aug 02, 2001 at 12:24:03PM -0400, George Schlossnagle
wrote:
On a related note, placing null-bytes in the middle of strings
(for example
in the names of the so-called lambda_functions generated from
create_function()) seems like a pretty questionable practice.
why, this makes sure that function-names generated by
create_function() will never clash with userland code.
i think that makes perfect sense.
tc
In that case, I should point out that
function __lambda_func() {}
$fn = create_function('', '');
does not work.
Dan
--
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]
Re: [PHP-DEV] Programming question
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 sto me that there are ways of accomplishing this that allow for this without breaking compatibility of that string with standard string functions, for exampla an ANSI-like standard prohibiting userland functions begnning with __ or using a non-null, low ascii character (say 0x07). agreed, but php has been binary-safe for a looong time. and \0 is the most obvious thing to embed and show anybody (who reads the c-code) that this is only to-be used internally. I guess, but it means that it is unsafe to use the common string functions on function names in the function_table. There are valid reasons to directly access function_table in php extensions, so why severely limit the library functions you can use to manipulate function names? It just seems to me that while it may make it obvious that it's for internal use, there are better ways of doing it that still allow you to treat a string as a string in c. tc -- 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 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 PROTECTED]
Re: [PHP-DEV] Programming question
can it be assumed that zval.str.val[zval.str.len] = '\0'? i.e., the byte after the string in a zval is the null-byte? That is assumed in various places in ext/standard/string.c, and AFAIK that may not always be true. No code in PHP should assume this. PHP should always check the length. However, many external libraries that take string arguments are not going to be able to check our length property and we therefore should strive to null-terminate all strings. I noticed Thies has been going through recently and cleaning this up a bit. -Rasmus -- 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]
Re: [PHP-DEV] Programming question
On Thu, Aug 02, 2001 at 09:18:40AM -0700, Rasmus Lerdorf wrote: can it be assumed that zval.str.val[zval.str.len] = '\0'? i.e., the byte after the string in a zval is the null-byte? That is assumed in various places in ext/standard/string.c, and AFAIK that may not always be true. No code in PHP should assume this. PHP should always check the length. However, many external libraries that take string arguments are not going to be able to check our length property and we therefore should strive to null-terminate all strings. I noticed Thies has been going through recently and cleaning this up a bit. in debug mode php will also trow a warning if it finds a not zero-terminated string during execution. tc -- 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]
Re: [PHP-DEV] Programming question
On a related note, placing null-bytes in the middle of strings (for example in the names of the so-called lambda_functions generated from create_function()) seems like a pretty questionable practice. - Original Message - From: Rasmus Lerdorf [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, August 02, 2001 12:18 PM Subject: Re: [PHP-DEV] Programming question can it be assumed that zval.str.val[zval.str.len] = '\0'? i.e., the byte after the string in a zval is the null-byte? That is assumed in various places in ext/standard/string.c, and AFAIK that may not always be true. No code in PHP should assume this. PHP should always check the length. However, many external libraries that take string arguments are not going to be able to check our length property and we therefore should strive to null-terminate all strings. I noticed Thies has been going through recently and cleaning this up a bit. -Rasmus -- 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] -- 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]
Re: [PHP-DEV] Programming question
On Thu, Aug 02, 2001 at 12:24:03PM -0400, George Schlossnagle wrote: On a related note, placing null-bytes in the middle of strings (for example in the names of the so-called lambda_functions generated from create_function()) seems like a pretty questionable practice. why, this makes sure that function-names generated by create_function() will never clash with userland code. i think that makes perfect sense. tc -- 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]
