Do we think there's value in using a better regexp library in 3.0? The Exim guys wrote PCRE and bundled it with the Exim source until relatively recently, so if we don't want an external dependency that might be an option (having said that, they removed it about a year ago and it's a dependency now)
On 25 Jul 2011, at 14:11, Phil Mayers wrote:
Do we think there's value in using a better regexp library in 3.0?
The Exim guys wrote PCRE and bundled it with the Exim source until relatively recently, so if we don't want an external dependency that might be an option (having said that, they removed it about a year ago and it's a dependency now)
Yes absolutely. Atomic look around is very useful... and i'm not sure if Extended regexp supports non capturing sub expressions... i.e. (?:stuff). I wonder how difficult it'd be to work in named captures... /(?<request:Stripped-User-Name>[^@\\/])/... Regular expressions are a bit of crutch in unlang, they do the work of chomp/split/substr etc, so the more powerful and feature-full the better. -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org RADIUS - Half the complexity of Diameter
Phil Mayers wrote:
Do we think there's value in using a better regexp library in 3.0?
Yes.
The Exim guys wrote PCRE and bundled it with the Exim source until relatively recently, so if we don't want an external dependency that might be an option (having said that, they removed it about a year ago and it's a dependency now)
We can add pcre support. So long as there's the typical configure/ifdef magic to make it work. If you're doing a patch, just make sure that the ifdef's are there. I can go fight with configure. Alan DeKok.
On 25/07/11 13:56, Alan DeKok wrote:
Phil Mayers wrote:
Do we think there's value in using a better regexp library in 3.0?
Yes.
The Exim guys wrote PCRE and bundled it with the Exim source until relatively recently, so if we don't want an external dependency that might be an option (having said that, they removed it about a year ago and it's a dependency now)
We can add pcre support. So long as there's the typical configure/ifdef magic to make it work.
If you're doing a patch, just make sure that the ifdef's are there. I can go fight with configure.
I'm in South America for 3 weeks from Saturday, so will be unlikely to look at this myself until September. However, PCRE has a posix-compatible API, so it could be as simple as replacing: #include <regex.h> ...with: #ifdef HAVE_PCREPOSIX_H #include <pcreposix.h> #else #include <regex.h> #endif ...and adding "-lpcreposix" to the link libs. I might have a quick go at that today.
On 25/07/11 14:35, Phil Mayers wrote:
...and adding "-lpcreposix" to the link libs. I might have a quick go at that today.
Huh, that was easier than I thought: https://github.com/philmayers/freeradius-server/commit/1598bb91a330787d4c24a...
Phil Mayers wrote:
Huh, that was easier than I thought:
https://github.com/philmayers/freeradius-server/commit/1598bb91a330787d4c24a...
Nice. Pulled && pushed. Alan DeKok.
On 07/25/2011 08:11 AM, Phil Mayers wrote:
Do we think there's value in using a better regexp library in 3.0?
The Exim guys wrote PCRE and bundled it with the Exim source until relatively recently, so if we don't want an external dependency that might be an option (having said that, they removed it about a year ago and it's a dependency now)
I would vastly prefer if the regexp's in FreeRADIUS were Perl instead of Posix. FWIW Perl regexps have become a defacto standard because they are so much better and the PCRE library is widely available. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
John Dennis -
Phil Mayers