php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #56653 Regular expression matches always return NULL
Submitted: 2005-11-15 19:26 UTC Modified: 2006-11-10 11:38 UTC
From: ramsey@php.net Assigned: pajoye (profile)
Status: Closed Package: filter (PECL)
PHP Version: 5.2.0 OS: Mac OS X 10.4.8
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: ramsey@php.net
New email:
PHP Version: OS:

 

 [2005-11-15 19:26 UTC] ramsey@php.net
Description:
------------
Everytime I try to use the FL_REGEXP filter, it returns NULL. This is when compiled against the system's pcre.h.

Reproduce code:
---------------
<?php
var_dump(filter_data('foo', FL_REGEXP, array('regexp' => '/^\w+$/')));
?>

Expected result:
----------------
string(3) "foo"

Actual result:
--------------
NULL

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-11-15 19:48 UTC] ramsey@php.net
Thank you for taking the time to write to us, but this is not
a bug.

Removed the forward slash delimiters and it works. Manual should note that delimiters are not required (in fact, it will not work if the delimiters are provided).
 [2006-05-08 13:02 UTC] pierre dot php at gmail dot com
This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.

You can use the same expression format as ext/pcre. It uses now the extension API.
 [2006-11-10 11:08 UTC] ramsey@php.net
I'm reopening this bug because, now, FILTER_VALIDATE_REGEXP always appear to return FALSE (even if removing the forward slash delimiters).

EXAMPLE CODE:

<?php

// $_GET['name'] = 'John Doe'
$name = 'John Doe';

$expression = '/^[[:alpha:]\ \-\']+$/';
$options = array('regexp' => $expression);

var_dump(filter_input(INPUT_GET, 'name', FILTER_VALIDATE_REGEXP, $options));

var_dump(preg_match($expression, $_GET['name']));

var_dump(filter_var($name, FILTER_VALIDATE_REGEXP, $options));

var_dump(preg_match($expression, $name));

?>

EXPECTED RESULT:

string(8) "John Doe"
int(1)
string(8) "John Doe"
int(1)

ACTUAL RESULT:

bool(false)
int(1)
bool(false)
int(1)
 [2006-11-10 11:38 UTC] ramsey@php.net
I'm closing this bug because my last comment was bogus. I should've been passing the options arguments like this:

array('options' => array('regexp' => $expression))

So, the comment wasn't even related to the earlier problems described here. The API simply changed, and I didn't notice it.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 08:01:28 2024 UTC