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]
