Re: 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: php-dev-unsubscribe@lists.php.net > >For additional commands, e-mail: php-dev-help@lists.php.net > >To contact the list administrators, e-mail: php-list-admin@lists.php.net > > -- > Zeev Suraski <zeev@zend.com> > CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/¶Ît`J > Æ*âƒ`LµI| > >