|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #15486 'Invalid range end' with eregi_replace() under certain conditions.
Submitted: 2002-02-10 09:33 UTC Modified: 2002-02-10 11:58 UTC
From: cahagn_o at epita dot fr Assigned:
Status: Not a bug Package: *Regular Expressions
PHP Version: 4.0.6 OS: Linux
Private report: No CVE-ID: None
 [2002-02-10 09:33 UTC] cahagn_o at epita dot fr
There's an annoying bug with eregi_replace() which sometimes send Invalid Range End.
This is reproducible with Linux RH7.2 and PHP 4.0.6 compiled '--with-regex=system'.

I couldn't find this bug on This might be a known bug but, please, don't close it, I would really like to know on which systems the problem occurs exacly so as to add workaround on a Webmail client FAQ I wrote:

It happens on this system (which I'm not the Webmaster of):

I couldn't reproduce the problem on Win2k+Apache 2.0.28+PHP 4.0.6 as CGI.

Some other reports:

I will attach testcase, which is long but the user on the above system couldn't reduce testcase. And I cannot reduce it myself as I don't have the bug on my system.
The regexp might seem to be complicated but it runs very fine  on many Web servers (NetBSD w/ Apache, Windows w/ Xitami, etc.) but some servers under certain conditions which makes it hard to reproduce.
Fortunately, this time, it seems that I have a 100% reproducible testcase.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-02-10 09:47 UTC] cahagn_o at epita dot fr
The testcase can be downloaded here:

(btw, this server doesn't show the bug, running PHP 4.0.6 as CGI: for options).
This really confirms the bug only occurs on Linux (RedHat ? glibc problem ?) when compiled '--with-regex=system'.
 [2002-02-10 11:58 UTC]
If it only fails with --with-regex=system then it's VERY likely not to be a bug in PHP, but in your system's regex library.
Just compile PHP with it's own regexes.
 [2002-07-01 16:30 UTC] gray dot php at mailnull dot com
We are seeing a similar problem under linux with glibc-common-2.2.4-13 under 7.2.  Two instances of the same program.  The first one compiles the pattern "^[5-?] fine but the 2nd instance of the same program fails.  [5-9] works, [5-:] fails. [5-9:-?] works.  If you comment out that test then another one later on fails.

Compiling glibc with stubs removes the problem (of course).  This seems to me to be some sort of shared library issue otherwise why would the 1st one work and the 2nd fail.

Love to get some more information.
 [2002-11-19 09:05 UTC] p_holdsworth at talk21 dot com
I have been having this problem, it doesn't happen every time, but I was validating several email addresses in the same bit of code and when the error happened it happened for all email addresses.  I simplified the code to a valid character check only and the problem still occurred.  When I removed the check for the underscore on one of the email  address checks, this email check worked fine.
Of course this is not a fix as we need to check for underscore, but could it shed light on the problem, or is it just coincidence ???
After all the underscore is fairly unique to email address validation.
 [2002-11-19 09:59 UTC] p_holdsworth at talk21 dot com
Just to add to my last email, I seem to have made this thing work.  I had the following code

  if (!eregi("^([0-9a-z]+)(([0-9a-z\.-_]+)?)@([0-9a-z]+)\.([0-9a-z]+)(([0-9a-z_\.-]+)?)$", $formdata[email])) {

and changed it to

  if (!eregi("^([0-9a-z]+)(([0-9a-z_\.-]+)?)@([0-9a-z]+)\.([0-9a-z]+)(([0-9a-z_\.-]+)?)$", $formdata[email])) {

Spot the difference - note the placement of the underscore in the second grouping.  The first statement failed regularly, the second works fine.

Go figure !!!

After having wasted an afternoon on this and last night fixing cookie processing because of the new p3p idiocy, I can actually get on and do something useful.

P.S. Useful site, it is always nice to know that the problem is not of your own making.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Feb 26 22:01:28 2024 UTC