FAQ

Jani Taskinen schrieb:
If you're going to add it in PHP_5_1 branch,
why are you adding the thing in HEAD NEWS file?
Because for now it is in HEAD only. Once PHP 5.1.0 has been released and
the PHP_5_1 branch is open for this kind of check-in, I will MFH the
patch from HEAD and move the NEWS note from HEAD to the branch.

Best,
Sebastian

--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Search Discussions

  • Marcus Boerger at Oct 29, 2005 at 11:08 am
    Hello Sebastian,

    what do you think comes out first, 5.1.1 or 6.0 ?

    marcus

    Saturday, October 29, 2005, 12:36:04 PM, you wrote:
    Jani Taskinen schrieb:
    If you're going to add it in PHP_5_1 branch,
    why are you adding the thing in HEAD NEWS file?
    Because for now it is in HEAD only. Once PHP 5.1.0 has been released and
    the PHP_5_1 branch is open for this kind of check-in, I will MFH the
    patch from HEAD and move the NEWS note from HEAD to the branch.
  • Sebastian Bergmann at Oct 29, 2005 at 11:39 am

    Marcus Boerger schrieb:
    what do you think comes out first, 5.1.1 or 6.0 ?
    PHP 5.1.1, of course. But as I cannot yet commit to PHP_5_1 I did not
    want to have the patch in HEAD without a NEWS entry.

    --
    Sebastian Bergmann http://www.sebastian-bergmann.de/
    GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
  • Sebastian Bergmann at Oct 31, 2005 at 9:03 pm

    Dmitry Stogov schrieb:
    Of course we can. :)
    Go ahead and commit it if the current implementation breaks things.
    But probably $this can be really useful in debug backtrace.
    I just hope that this feature can be preserved, whether or not based
    upon my 5-minute-patch is secondary ;-)

    --
    Sebastian Bergmann http://www.sebastian-bergmann.de/
    GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
  • Marco Bambini at Nov 1, 2005 at 12:30 am
    I am developing a PHP plugin using PHP 4.4 SDK (not 5) and I need to
    access a parameter as a raw char * pointer instead of a string or any
    other C type.
    Until now to access parameters I am using the zend_get_parameters_ex
    routine and then the various convert_to_something routines.

    I think I can't use the convert_to_string function because my
    parameters is binary data but I wonder what I can use in this case, I
    need the raw char * pointer and not a C string...

    Thanks for you reply,
    Marco Bambini
  • Rasmus Lerdorf at Nov 1, 2005 at 12:35 am

    Marco Bambini wrote:
    I am developing a PHP plugin using PHP 4.4 SDK (not 5) and I need to
    access a parameter as a raw char * pointer instead of a string or any
    other C type.
    Until now to access parameters I am using the zend_get_parameters_ex
    routine and then the various convert_to_something routines.

    I think I can't use the convert_to_string function because my parameters
    is binary data but I wonder what I can use in this case, I need the raw
    char * pointer and not a C string...
    I think you are a bit confused. There is no such thing as a C string.
    A string in C is simply an array of chars or a char *. In order to deal
    with binary data you have to carry the length of the data around with
    the char * which is exactly what PHP does. Without that you have no way
    of knowing how much binary data you have. So in short, you should be
    fine using the standard PHP API string.

    -Rasmus
  • Marco Bambini at Nov 1, 2005 at 12:46 am
    Thanks a lot Rasmus, I have just (wrongly) assumed that the
    convert_to_string function tries to search for the 0 termination
    character.

    Thanks,
    Marco Bambini
    On Nov 1, 2005, at 1:35 AM, Rasmus Lerdorf wrote:

    Marco Bambini wrote:
    I am developing a PHP plugin using PHP 4.4 SDK (not 5) and I need
    to access a parameter as a raw char * pointer instead of a string
    or any other C type.
    Until now to access parameters I am using the
    zend_get_parameters_ex routine and then the various
    convert_to_something routines.
    I think I can't use the convert_to_string function because my
    parameters is binary data but I wonder what I can use in this
    case, I need the raw char * pointer and not a C string...
    I think you are a bit confused. There is no such thing as a C
    string. A string in C is simply an array of chars or a char *. In
    order to deal with binary data you have to carry the length of the
    data around with the char * which is exactly what PHP does.
    Without that you have no way of knowing how much binary data you
    have. So in short, you should be fine using the standard PHP API
    string.

    -Rasmus

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Derick Rethans at Nov 1, 2005 at 8:10 am

    On Tue, 1 Nov 2005, Marco Bambini wrote:

    Thanks a lot Rasmus, I have just (wrongly) assumed that the convert_to_string
    function tries to search for the 0 termination character.
    It doesn't - but, PHP strings always require \0 to be the last
    character so you always need to allocate one more byte and put the \0 in
    there - even for binary data.

    Derick
  • Rasmus Lerdorf at Nov 1, 2005 at 8:48 am

    Derick Rethans wrote:
    On Tue, 1 Nov 2005, Marco Bambini wrote:

    Thanks a lot Rasmus, I have just (wrongly) assumed that the convert_to_string
    function tries to search for the 0 termination character.
    It doesn't - but, PHP strings always require \0 to be the last
    character so you always need to allocate one more byte and put the \0 in
    there - even for binary data.
    That's not really a PHP requirement, but more of a good convention to
    prevent something external from falling off the end of a string. If you
    are just working with it internally you don't need it.

    -Rasmus
  • Derick Rethans at Nov 1, 2005 at 8:54 am

    On Tue, 1 Nov 2005, Rasmus Lerdorf wrote:

    Derick Rethans wrote:
    On Tue, 1 Nov 2005, Marco Bambini wrote:

    Thanks a lot Rasmus, I have just (wrongly) assumed that the
    convert_to_string
    function tries to search for the 0 termination character.
    It doesn't - but, PHP strings always require \0 to be the last character so
    you always need to allocate one more byte and put the \0 in there - even for
    binary data.
    That's not really a PHP requirement, but more of a good convention to prevent
    something external from falling off the end of a string. If you are just
    working with it internally you don't need it.
    Right, but if you store it as a string in a ZVAL you do, otherwise the
    engine can warn you about it.

    Derick
  • Zeev Suraski at Nov 1, 2005 at 8:55 am

    At 10:47 01/11/2005, Rasmus Lerdorf wrote:
    Derick Rethans wrote:
    On Tue, 1 Nov 2005, Marco Bambini wrote:

    Thanks a lot Rasmus, I have just (wrongly) assumed that the
    convert_to_string
    function tries to search for the 0 termination character.
    It doesn't - but, PHP strings always require \0 to be the last character
    so you always need to allocate one more byte and put the \0 in there -
    even for binary data.
    That's not really a PHP requirement, but more of a good convention to
    prevent something external from falling off the end of a string. If you
    are just working with it internally you don't need it.
    It's a mix of both, to clarify:

    - For 'PHP strings', i.e. strings that go back into PHP, it is a strict
    requirement.
    - For 'internal' strings, assuming internal means strings used by the
    extension that never go anywhere beyond that, there aren't any requirements
    of any kind, other than using the memory allocator perhaps. For that
    matter, strings are like any other kind of data structure.

    So it all depends on what people understand when they read 'PHP strings' or
    'internal'.

    Zeev

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedOct 29, '05 at 10:36a
activeNov 1, '05 at 8:55a
posts11
users6
websitephp.net

People

Translate

site design / logo © 2022 Grokbase