FAQ
Hi geeks!

We're unable to disable the ereg extension today, yet it's been deprecated since PHP 5.3.0. Is this by design?

Regards,
Philip

Search Discussions

  • Pierre Joye at Jan 10, 2012 at 8:27 am
    is it not emulated using pcre now? as in, the ereg library is not used anymore
    On Tue, Jan 10, 2012 at 8:49 AM, Philip Olson wrote:
    Hi geeks!

    We're unable to disable the ereg extension today, yet it's been deprecated since PHP 5.3.0. Is this by design?

    Regards,
    Philip


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
  • Philip Olson at Jan 10, 2012 at 3:46 pm
    Hello Pierre,

    I mean that the ereg extension is deprecated, yet we cannot disable
    it while compiling PHP. In other words, ereg() and friends always
    exist in PHP, and emit E_DEPRECATED errors upon use. We should have
    the option of creating fatal undefined function errors… basically.

    Currently this exists for ereg:

    --with-regex[=TYPE]

    So I guess we want:

    --without-regex

    Even though --disable-ereg would feel more natural.

    Regards,
    Philip
    On Jan 10, 2012, at 12:27 AM, Pierre Joye wrote:

    is it not emulated using pcre now? as in, the ereg library is not used anymore
    On Tue, Jan 10, 2012 at 8:49 AM, Philip Olson wrote:
    Hi geeks!

    We're unable to disable the ereg extension today, yet it's been deprecated since PHP 5.3.0. Is this by design?

    Regards,
    Philip


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
  • Pierre Joye at Jan 10, 2012 at 5:28 pm
    what I mean is that, as far as I remember, the deprecation is only an
    information via the documentation. We did not want to break BC and all
    that as it is now emulated through pcre.
    On Tue, Jan 10, 2012 at 4:46 PM, Philip Olson wrote:
    Hello Pierre,

    I mean that the ereg extension is deprecated, yet we cannot disable
    it while compiling PHP. In other words, ereg() and friends always
    exist in PHP, and emit E_DEPRECATED errors upon use. We should have
    the option of creating fatal undefined function errors… basically.

    Currently this exists for ereg:

    --with-regex[=TYPE]

    So I guess we want:

    --without-regex

    Even though --disable-ereg would feel more natural.

    Regards,
    Philip
    On Jan 10, 2012, at 12:27 AM, Pierre Joye wrote:

    is it not emulated using pcre now? as in, the ereg library is not used anymore
    On Tue, Jan 10, 2012 at 8:49 AM, Philip Olson wrote:
    Hi geeks!

    We're unable to disable the ereg extension today, yet it's been deprecated since PHP 5.3.0. Is this by design?

    Regards,
    Philip


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org


    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
  • Ferenc Kovacs at Jan 10, 2012 at 6:11 pm

    On Tue, Jan 10, 2012 at 6:28 PM, Pierre Joye wrote:

    what I mean is that, as far as I remember, the deprecation is only an
    information via the documentation. We did not want to break BC and all
    that as it is now emulated through pcre.

    no, we deprecated it, and albeit it was a discussion to un-deprecate it, we
    kept it:
    I think we have enough reasons to keep it deprecated as we have much better
    alternative (pcre) which we want to recommend to the users.
    http://lxr.php.net/opengrok/xref/PHP_5_4/ext/ereg/ereg.c#54

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Pierre Joye at Jan 10, 2012 at 6:41 pm
    Can you please carefully read what I wrote? Thanks.

    I said:

    " the deprecation is only an information via the documentation"

    as in not adding noises to the language without any good reason.
    On Tue, Jan 10, 2012 at 7:11 PM, Ferenc Kovacs wrote:

    On Tue, Jan 10, 2012 at 6:28 PM, Pierre Joye wrote:

    what I mean is that, as far as I remember, the deprecation is only an
    information via the documentation. We did not want to break BC and all
    that as it is now emulated through pcre.

    no, we deprecated it, and albeit it was a discussion to un-deprecate it, we
    kept it:
    I think we have enough reasons to keep it deprecated as we have much better
    alternative (pcre) which we want to recommend to the users.
    http://lxr.php.net/opengrok/xref/PHP_5_4/ext/ereg/ereg.c#54

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu


    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
  • Philip Olson at Jan 10, 2012 at 7:33 pm
    Hi!

    This thread has veered off-course. So to summarize:

    (1) ereg is deprecated, and usage is discouraged
    (2) It emits E_DEPRECATED errors as of PHP 5.3
    (3) We cannot disable/remove ereg at compile time (today)

    I'm suggesting we alter (3) so that we, the people who compile
    PHP, can optionally remove this extension from our PHP 5.4+.

    This means adding --without-regex to go along with --with-regex,
    which is the current compile-time option for ext/ereg.

    Any objections? Regardless of deprecation status, this option
    should be available. Or if not, why?

    Regards,
    Philip
    On Jan 10, 2012, at 10:41 AM, Pierre Joye wrote:

    Can you please carefully read what I wrote? Thanks.

    I said:

    " the deprecation is only an information via the documentation"

    as in not adding noises to the language without any good reason.
    On Tue, Jan 10, 2012 at 7:11 PM, Ferenc Kovacs wrote:

    On Tue, Jan 10, 2012 at 6:28 PM, Pierre Joye wrote:

    what I mean is that, as far as I remember, the deprecation is only an
    information via the documentation. We did not want to break BC and all
    that as it is now emulated through pcre.

    no, we deprecated it, and albeit it was a discussion to un-deprecate it, we
    kept it:
    I think we have enough reasons to keep it deprecated as we have much better
    alternative (pcre) which we want to recommend to the users.
    http://lxr.php.net/opengrok/xref/PHP_5_4/ext/ereg/ereg.c#54

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu


    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
  • Stas Malyshev at Jan 10, 2012 at 7:52 pm
    Hi!
    (1) ereg is deprecated, and usage is discouraged
    (2) It emits E_DEPRECATED errors as of PHP 5.3
    (3) We cannot disable/remove ereg at compile time (today)

    I'm suggesting we alter (3) so that we, the people who compile
    PHP, can optionally remove this extension from our PHP 5.4+.
    OK, propose a patch :) Note that pgsql seems to be using regex, and may
    be other modules, so it should be made to use PCRE instead I guess.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Rasmus Lerdorf at Jan 10, 2012 at 7:54 pm

    On 01/10/2012 11:33 AM, Philip Olson wrote:
    Any objections? Regardless of deprecation status, this option
    should be available. Or if not, why?
    The main reason is that we are not done removing all the dependencies.
    This is a large deprecation that is going to require the process to span
    multiple versions. We could add a way to disable it, but it is going to
    break some extensions in ways that are not obvious to the user.

    -Rasmus
  • Philip Olson at Jan 10, 2012 at 11:15 pm

    On Jan 10, 2012, at 11:54 AM, Rasmus Lerdorf wrote:
    On 01/10/2012 11:33 AM, Philip Olson wrote:
    Any objections? Regardless of deprecation status, this option
    should be available. Or if not, why?
    The main reason is that we are not done removing all the dependencies.
    This is a large deprecation that is going to require the process to span
    multiple versions. We could add a way to disable it, but it is going to
    break some extensions in ways that are not obvious to the user.
    Makes sense. Removing ereg dependencies from PHP 5.5 (trunk) seems like
    the wise choice, and adding --without-regex then as well.

    Regards,
    Philip
  • Pierre Joye at Jan 11, 2012 at 12:55 am
    We can only do it for a 6.x, not for a 5.5. So I would not do it too
    early in the process.
    On Wed, Jan 11, 2012 at 12:14 AM, Philip Olson wrote:
    On Jan 10, 2012, at 11:54 AM, Rasmus Lerdorf wrote:
    On 01/10/2012 11:33 AM, Philip Olson wrote:
    Any objections? Regardless of deprecation status, this option
    should be available. Or if not, why?
    The main reason is that we are not done removing all the dependencies.
    This is a large deprecation that is going to require the process to span
    multiple versions. We could add a way to disable it, but it is going to
    break some extensions in ways that are not obvious to the user.
    Makes sense. Removing ereg dependencies from PHP 5.5 (trunk) seems like
    the wise choice, and adding --without-regex then as well.

    Regards,
    Philip


    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
  • Ferenc Kovacs at Nov 30, 2012 at 10:01 am
    bump
    anybody working on this so that we can remove the ereg "dependency" for 5.5?
    would be nice if we could open an issue for this with the necessary info to
    anybody to jump into fixing it.

    On Wed, Jan 11, 2012 at 12:14 AM, Philip Olson wrote:

    On Jan 10, 2012, at 11:54 AM, Rasmus Lerdorf wrote:
    On 01/10/2012 11:33 AM, Philip Olson wrote:
    Any objections? Regardless of deprecation status, this option
    should be available. Or if not, why?
    The main reason is that we are not done removing all the dependencies.
    This is a large deprecation that is going to require the process to span
    multiple versions. We could add a way to disable it, but it is going to
    break some extensions in ways that are not obvious to the user.
    Makes sense. Removing ereg dependencies from PHP 5.5 (trunk) seems like
    the wise choice, and adding --without-regex then as well.

    Regards,
    Philip

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Oleg Oshmyan at Jan 10, 2012 at 9:01 pm

    (3) We cannot disable/remove ereg at compile time (today)

    I'm suggesting we alter (3) so that we, the people who compile
    PHP, can optionally remove this extension from our PHP 5.4+.
    For what it's worth, I was able to successfully remove ereg from PHP 5.3
    (.6, I think; this was a while ago) by just removing ext/ereg from the
    source tree before running configure (same with reflection and spl).

    I presume though that this only worked because I happened to disable all
    extensions that depended on ereg at the same time. Even so, an option
    would be useful even if it was accompanied by a warning saying that it
    might break the build depending on other extension choices.

    --
    Oleg
  • Johannes Schlüter at Jan 10, 2012 at 7:43 pm

    On Tue, 2012-01-10 at 18:28 +0100, Pierre Joye wrote:
    what I mean is that, as far as I remember, the deprecation is only an
    information via the documentation. We did not want to break BC and all
    that as it is now emulated through pcre.
    There is no emulation, the behavior of the ereg library and pcre is
    different that emulation is not possible in a useful way. It is also not
    only in documentation but by throwing E_DEPRECATED.
    Currently this exists for ereg:

    --with-regex[=TYPE]

    So I guess we want:

    --without-regex

    Even though --disable-ereg would feel more natural.
    --disable is the counterpart to --enable as generated by autoconf.
    --without the counterpart to --with. We use --with for things using some
    library. ereg uses by default a bundled library but could also be
    configured to use a system configured library. Therefor "--with" is
    correct, therefore --without is the "correct" consequence.

    We're unable to disable the ereg extension today, yet it's been
    deprecated since PHP 5.3.0. Is this by design?
    It's at least partly by design. We had some code using ereg library
    stuff internally, so core PHP depended on it. The plan was to rewrite
    these code parts to use pcre. I'm not sure that has been done, yet. Till
    then we can't make ereg optional.

    We should look into this for 5.5, using ereg is a bit dangerous (0-byte
    safety etc.) so dropping it is a good thing, even aside from reducing
    the amount of code to maintain.

    johannes

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJan 10, '12 at 7:49a
activeNov 30, '12 at 10:01a
posts14
users7
websitephp.net

People

Translate

site design / logo © 2022 Grokbase