Re: [PHP-DEV] Programming question

[Daniel Cowgill]

> 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 
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

[George Schlossnagle]

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 
> >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 
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

[George Schlossnagle]

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

[Thies C. Arntzen]

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 
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

[Rasmus Lerdorf]

> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Programming question

[jeroen]

Hi,

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.

TIA,
Jeroen



-- 
PHP Development Mailing List 
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

[Zeev Suraski]

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 
>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 
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

[Zeev Suraski]

Actually, any code in PHP can assume this.  Any zval coming from the engine 
is NULL terminated, so zval.str.val[zval.str.len] is always 
NULL.  Obviously, if you create the string, you have to NULL terminate it 
before you can assume that :)
If a string is not NULL terminated, it is a bug.

At 09:18 02/08/2001, 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.
>
>-Rasmus
>
>
>--
>PHP Development Mailing List 
>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 
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

[Thies C. Arntzen]

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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]