Re: [PHP-DEV] preg_match() option for anchored offset?

2017-06-08 Thread Rasmus Schultz 
> You are looking for the \G anchor or the A modifier.

Both of these options work great!

I've submitted a patch to the manual page with a note explaining these
options.

Thanks :-)


On Wed, Jun 7, 2017 at 10:13 PM, Nikita Popov  wrote:

> On Wed, Jun 7, 2017 at 10:03 PM, Rasmus Schultz 
> wrote:
>
>> What do you think about adding another option to preg_match() to allow the
>> $offset parameter to be treated as the start anchor?
>>
>> The manual proposes to do this:
>>
>> $subject = "abcdef";
>> $pattern = '/^def/';
>> $offset = 3;
>> preg_match($pattern, substr($subject, $offset), $matches);
>>
>> In other words, use substr() to copy the entire remainder of the string.
>>
>> I just wrote a simple SQL parser tonight, and had to use this approach,
>> which (I imagine) must be pretty inefficient?
>>
>> I'd like to be able to do the following:
>>
>> $subject = "abcdef";
>> $pattern = '/^def/';
>> $offset = 3;
>> preg_match($pattern, $subject, $matches, PREG_ANCHOR_OFFSET, $offset);
>>
>> This new option would make the ^ anchor work from the given $offset, which
>> allows me to parse the entire $subject without copying anything.
>>
>> Thoughts?
>>
>
> You are looking for the \G anchor or the A modifier.
>
> Nikita
>
>

Re: [PHP-DEV] preg_match() option for anchored offset?

2017-06-07 Thread Nikita Popov 
On Wed, Jun 7, 2017 at 10:03 PM, Rasmus Schultz  wrote:

> What do you think about adding another option to preg_match() to allow the
> $offset parameter to be treated as the start anchor?
>
> The manual proposes to do this:
>
> $subject = "abcdef";
> $pattern = '/^def/';
> $offset = 3;
> preg_match($pattern, substr($subject, $offset), $matches);
>
> In other words, use substr() to copy the entire remainder of the string.
>
> I just wrote a simple SQL parser tonight, and had to use this approach,
> which (I imagine) must be pretty inefficient?
>
> I'd like to be able to do the following:
>
> $subject = "abcdef";
> $pattern = '/^def/';
> $offset = 3;
> preg_match($pattern, $subject, $matches, PREG_ANCHOR_OFFSET, $offset);
>
> This new option would make the ^ anchor work from the given $offset, which
> allows me to parse the entire $subject without copying anything.
>
> Thoughts?
>

You are looking for the \G anchor or the A modifier.

Nikita

Re: [PHP-DEV] preg_match() option for anchored offset?

2017-06-07 Thread Rowan Collins 

On 07/06/2017 21:03, Rasmus Schultz wrote:

What do you think about adding another option to preg_match() to allow the
$offset parameter to be treated as the start anchor?

The manual proposes to do this:

 $subject = "abcdef";
 $pattern = '/^def/';
 $offset = 3;
 preg_match($pattern, substr($subject, $offset), $matches);

In other words, use substr() to copy the entire remainder of the string.

I just wrote a simple SQL parser tonight, and had to use this approach,
which (I imagine) must be pretty inefficient?

I'd like to be able to do the following:

 $subject = "abcdef";
 $pattern = '/^def/';
 $offset = 3;
 preg_match($pattern, $subject, $matches, PREG_ANCHOR_OFFSET, $offset);

This new option would make the ^ anchor work from the given $offset, which
allows me to parse the entire $subject without copying anything.

Thoughts?



How would you propose to implement this? Is it something PCRE already 
supports? Or would you manipulate the subject string pointer at the 
point it's passed down? The latter approach seems doable, but I'm not 
sure if there are any subtle gotchas.


Regards,

--
Rowan Collins
[IMSoP]


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

[PHP-DEV] preg_match() option for anchored offset?

2017-06-07 Thread Rasmus Schultz 
What do you think about adding another option to preg_match() to allow the
$offset parameter to be treated as the start anchor?

The manual proposes to do this:

$subject = "abcdef";
$pattern = '/^def/';
$offset = 3;
preg_match($pattern, substr($subject, $offset), $matches);

In other words, use substr() to copy the entire remainder of the string.

I just wrote a simple SQL parser tonight, and had to use this approach,
which (I imagine) must be pretty inefficient?

I'd like to be able to do the following:

$subject = "abcdef";
$pattern = '/^def/';
$offset = 3;
preg_match($pattern, $subject, $matches, PREG_ANCHOR_OFFSET, $offset);

This new option would make the ^ anchor work from the given $offset, which
allows me to parse the entire $subject without copying anything.

Thoughts?

[PHP-DEV] preg_match

2011-07-08 Thread Rafael Dohms 
I was wondering if anyone ever thought of either fixing or writing a
new function that would make preg_match actually work in a way that
made sense?

right now i need to pass in a optional parameter that will receive the
match, in this case one or no match, why should this not be the
function's return already?

something like:

$string = tdmy text/td;
$result = preg_match(/\td\(.*)\\/td\/, $string);

$result // = my text

Maybe something like preg_extract? I do not have the C skills to write
a patch but i think adding a new function would not break BC or have
negative side effects, would it?

-- 
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br

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

Re: [PHP-DEV] preg_match

2011-07-08 Thread Nikita Popov 
The most common use for preg_match is validation:

if (!preg_match('~...~', $string)) { /* do something */ }

Here $matches is not required, only the 0/1 return value of preg_match is of
interest.

Furthermore, even if you need $matches, you should always combine it with an
if:

if (!preg_match('~...~', $string, $matches)) { /* do something with $matches
*/ }

Otherwise you will access $matches even though the match failed (which will
result in errors).

Thus: There is no need to change behavior here.

On Fri, Jul 8, 2011 at 2:12 PM, Rafael Dohms lis...@rafaeldohms.com.brwrote:

 I was wondering if anyone ever thought of either fixing or writing a
 new function that would make preg_match actually work in a way that
 made sense?

 right now i need to pass in a optional parameter that will receive the
 match, in this case one or no match, why should this not be the
 function's return already?

 something like:

 $string = tdmy text/td;
 $result = preg_match(/\td\(.*)\\/td\/, $string);

 $result // = my text

 Maybe something like preg_extract? I do not have the C skills to write
 a patch but i think adding a new function would not break BC or have
 negative side effects, would it?

 --
 Rafael Dohms
 PHP Evangelist and Community Leader
 http://www.rafaeldohms.com.br
 http://www.phpsp.org.br

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

Re: [PHP-DEV] preg_match

2011-07-08 Thread Rafael Dohms 
On Fri, Jul 8, 2011 at 9:20 AM, Nikita Popov nikita@googlemail.com wrote:
 The most common use for preg_match is validation:

 if (!preg_match('~...~', $string)) { /* do something */ }

 Here $matches is not required, only the 0/1 return value of preg_match is of
 interest.

 Furthermore, even if you need $matches, you should always combine it with an
 if:

 if (!preg_match('~...~', $string, $matches)) { /* do something with $matches
 */ }

 Otherwise you will access $matches even though the match failed (which will
 result in errors).

 Thus: There is no need to change behavior here.

That is just one use case as i see it its very cluncky to use this in
case you want to extract matches, you need to initilize the $matches
variable beforehad or you get a notice, so a simple extract is now 3
lines of code.

Thus, that is the reason why i suggest a new preg_extract function
that would handle the other use cases in a optimized way.

-- 
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br

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

Re: [PHP-DEV] preg_match

2011-07-08 Thread Nikita Popov 
No, you don't need to initialize $matches. It's passed by reference and thus
doesn't need to be initialized.
And as I already said: It is good practice to ensure that preg_match
actually matched something:

if (preg_match(REGEX, $string, $matches)) {
// in here $matches is guaranteed to be defined
}

If you don't do that you will work with $matches even though there was no
match - which is pointless and
will probably result in bugs.

On Fri, Jul 8, 2011 at 3:18 PM, Rafael Dohms lis...@rafaeldohms.com.brwrote:

 That is just one use case as i see it its very cluncky to use this in
 case you want to extract matches, you need to initilize the $matches
 variable beforehad or you get a notice, so a simple extract is now 3
 lines of code.

 Thus, that is the reason why i suggest a new preg_extract function
 that would handle the other use cases in a optimized way.

 --
 Rafael Dohms
 PHP Evangelist and Community Leader
 http://www.rafaeldohms.com.br
 http://www.phpsp.org.br

Re: [PHP-DEV] preg_match

2011-07-08 Thread Ivan Enderlin @ Hoa 

Hi Rafael :-),

On 08/07/11 15:18, Rafael Dohms wrote:

On Fri, Jul 8, 2011 at 9:20 AM, Nikita Popovnikita@googlemail.com  wrote:

The most common use for preg_match is validation:

if (!preg_match('~...~', $string)) { /* do something */ }

Here $matches is not required, only the 0/1 return value of preg_match is of
interest.

Furthermore, even if you need $matches, you should always combine it with an
if:

if (!preg_match('~...~', $string, $matches)) { /* do something with $matches
*/ }

Otherwise you will access $matches even though the match failed (which will
result in errors).

Thus: There is no need to change behavior here.

That is just one use case as i see it its very cluncky to use this in
case you want to extract matches, you need to initilize the $matches
variable beforehad or you get a notice, so a simple extract is now 3
lines of code.

Thus, that is the reason why i suggest a new preg_extract function
that would handle the other use cases in a optimized way.

Here is my proposition:

function preg_extract ( $pattern, $subject ) {

return false !== preg_match($pattern, $subject, $matches)
   ? $matches
   : false;
}

I think it is the trick you are looking for. But making a dedicated C 
implementation is not necessary IMHO.


Best regards.

--
Ivan Enderlin
Developer of Hoa Framework
http://hoa.42/ or http://hoa-project.net/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


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

Re: [PHP-DEV] preg_match

2011-07-08 Thread Rafael Dohms 
Still, this is preg_match it only returns one match, why should i get
a array and have to use ugly things like $matches[0] afterwards?
It just makes for very ugly syntax and extra code, a simple function
would make this cleaner and more intuitive, first time using
preg_match is a nightmare.

-- 
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br

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

Re: [PHP-DEV] preg_match

2011-07-08 Thread Alexey Shein 
2011/7/8 Rafael Dohms lis...@rafaeldohms.com.br:
 Still, this is preg_match it only returns one match, why should i get
 a array and have to use ugly things like $matches[0] afterwards?
 It just makes for very ugly syntax and extra code, a simple function
 would make this cleaner and more intuitive, first time using
 preg_match is a nightmare.


You forget about subpatterns, so array can contain more than 1 value:
php  preg_match('/p(hp)/', 'php', $matches); var_dump($matches);
array(2) {
  [0]=
  string(3) php
  [1]=
  string(2) hp
}


 --
 Rafael Dohms
 PHP Evangelist and Community Leader
 http://www.rafaeldohms.com.br
 http://www.phpsp.org.br

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





-- 
Regards,
Shein Alexey

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

RE: [PHP-DEV] preg_match

2011-07-08 Thread Mike Robinson 
On July-08-11 10:01 AM Rafael Dohms wrote:

[snip]

 first time using preg_match is a nightmare.

IMHO, preg_match is poetry in motion.

Going through a million lines of code replacing ereg[i] with preg_match
because it was deprecated in 5.3 - *that* is a nightmare.

Best Regards

Mike Robinson


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

Re: [PHP-DEV] preg_match

2011-07-08 Thread Richard Quadling 
On 8 July 2011 16:31, Mike Robinson m...@rile.ca wrote:
 On July-08-11 10:01 AM Rafael Dohms wrote:

 [snip]

 first time using preg_match is a nightmare.

 IMHO, preg_match is poetry in motion.

 Going through a million lines of code replacing ereg[i] with preg_match
 because it was deprecated in 5.3 - *that* is a nightmare.

 Best Regards

 Mike Robinson


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



Could've used preg_replace_all() ? Maybe? You _are_ a programmer, right?

-- 
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea

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

Re: [PHP-DEV] preg_match

2011-07-08 Thread Ferenc Kovacs 
On Fri, Jul 8, 2011 at 6:09 PM, Richard Quadling rquadl...@gmail.com wrote:
 On 8 July 2011 16:31, Mike Robinson m...@rile.ca wrote:
 On July-08-11 10:01 AM Rafael Dohms wrote:

 [snip]

 first time using preg_match is a nightmare.

 IMHO, preg_match is poetry in motion.

 Going through a million lines of code replacing ereg[i] with preg_match
 because it was deprecated in 5.3 - *that* is a nightmare.

 Best Regards

 Mike Robinson


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



 Could've used preg_replace_all() ? Maybe? You _are_ a programmer, right?


that heading into the wrong direction.

to reply to the original thread: I also had some use cases, when
returning the match(es) would have been nice, and could have saved me
from typing some boilerplate code.

Tyrael

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

Re: [PHP-DEV] preg_match and shared libpcre3 bug

2007-11-10 Thread Nuno Lopes 

With installing a security update for the pcre3 library on Debian
(http://lists.debian.org/debian-security-announce/debian-security-announ
ce-2007/msg00177.html), preg_match('|^\(|', 'xxx') suddenly returns 1
instead of 0 using PHP 5.1.6.


the correct value is 0, yes.



The thing is - I have built PHP using the bundled PCRE library and the
error happens only with the apache2 module, not with a CLI binary.
phpinfo() shows PCRE 6.6 and ldd shows no dependencies against the
shared libpcre.so.3, neither for the php-cli binary nor for the apache
module.

Any ideas what might cause that? I can't see why the shared library
update makes a difference at all.


You are right that updating the shared library shouldn't matter. If the 
problem happens only with apache2 it suggests that there is some symbol 
clashing problem. Please try with a recent PHP version and report if it 
doesn't work (I remember fixing a bunch of these lately).
Anyway I would advise you to upgrade PHP to a more recent version, as PCRE 
6.6 has some security problems.



Nuno 


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

[PHP-DEV] preg_match and shared libpcre3 bug

2007-11-09 Thread Matthias Pigulla 
I know this is weird and off-topic but I hope that someone here can give
me a starting pointer.

With installing a security update for the pcre3 library on Debian
(http://lists.debian.org/debian-security-announce/debian-security-announ
ce-2007/msg00177.html), preg_match('|^\(|', 'xxx') suddenly returns 1
instead of 0 using PHP 5.1.6.

The thing is - I have built PHP using the bundled PCRE library and the
error happens only with the apache2 module, not with a CLI binary.
phpinfo() shows PCRE 6.6 and ldd shows no dependencies against the
shared libpcre.so.3, neither for the php-cli binary nor for the apache
module.

Any ideas what might cause that? I can't see why the shared library
update makes a difference at all.

Thanks! 
-mp.

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