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.


At 10:22 02/08/2001, George Schlossnagle wrote:
> > > It seem sto me that there are ways of accomplishing this that allow for
> > > without breaking compatibility of that string with standard string
> > > functions, for exampla an ANSI-like standard prohibiting userland
> > > 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]

Reply via email to