Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Posix regexec - matching subexpression

Reply
Thread Tools

Posix regexec - matching subexpression

 
 
Gregory Toomey
Guest
Posts: n/a
 
      02-13-2005
Apologies if this is somehat offtopic.

Can somebody point to a simple example of matching subexpressions? I've read
http://www.gnu.org/software/libc/man...X-Regexps.html

Using the code below I can match "product_(.*)htm" to "product_abcd.htm".
What I get returned is "product_abcd.htm" but I want "abcd" (like the $1
matching variable in Perl). Is there an API for this?

gtoomey

------------
Return first substring mating the regex:

char *matchre ( char *pattern, char *string) {
char *p;
char *match;
int retval;
regex_t re;
char buf[BUFSIZE];
regmatch_t pmatch[100];
int status;
char *ps;
int eflag;

setlocale(LC_ALL, "");
if((status = regcomp( &re, pattern, REG_EXTENDED))!= 0){
regerror(status, &re, buf, 120);
exit(2);
}

ps = string;
eflag = 0;

match=(char *)malloc(1000);
if (status = regexec( &re, ps, 1, pmatch, eflag)==0){

/*printf("match found at: %d-%d, string=%s\n",
pmatch[0].rm_so, pmatch[0].rm_eo, ps
+pmatch[0].rm_so);*/
match=(char *)malloc(1000);
strcpy(match,ps +pmatch[0].rm_so);
/* return first match */
return match;
}
return "";
}
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      02-13-2005
Gregory Toomey <> writes:
> Apologies if this is somehat offtopic.


It is. Standard C has no built-in support for regular expressions.
Try comp.unix.programmer.

[...]
> match=(char *)malloc(1000);


The general consensus here is that casting the result of malloc() is a
bad idea. The cast is unnecessary, and it can sometimes (depending on
the compiler and settings) mask the error of forgetting the
"#include <stdlib.h>".

(If a troll with initials ERT posts a followup claiming that the cast
is necessary, ignore him.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
 
 
 
Jonathan Burd
Guest
Posts: n/a
 
      02-19-2005
Keith Thompson wrote:
> Gregory Toomey <> writes:
>


<snip>

>
> The general consensus here is that casting the result of malloc() is a
> bad idea. The cast is unnecessary, and it can sometimes (depending on
> the compiler and settings) mask the error of forgetting the
> "#include <stdlib.h>".
>
> (If a troll with initials ERT posts a followup claiming that the cast
> is necessary, ignore him.)
>


Of course, casting the result of malloc is a bad idea when using
standard C. However, most GNU code uses casts to make code compilable on
pre-ANSI compilers. I'm sure you know about it, but for the
benefit of other readers here who want to know more about it, here
is a link to Richard Heathfield's article on casting.

http://www.cognitiveprocess.com/~rjh...s/casting.html

That article says that one shouldn't cast malloc and
also gives a proper explanation for cases when one may want to.

Regards,
Jonathan.

--
Email: "jonathan [period] burd [commercial-at] gmail [period] com" sans-WSP

"I usually swear at C++, but so far it has never sworn back."
- Ben "Noir"
 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      02-19-2005
On Sat, 19 Feb 2005 15:51:31 +0530, in comp.lang.c , Jonathan Burd
<> wrote:

>Keith Thompson wrote:
>>
>> The general consensus here is that casting the result of malloc() is a
>> bad idea.

>
>Of course, casting the result of malloc is a bad idea when using
>standard C. However, most GNU code uses casts to make code compilable on
>pre-ANSI compilers.


Its worth noting that while its laudable to continue to support compilers
that are more than 15 years old, there's no particularly food reason for
doing so and absolutely no good reason for learning this way.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      02-21-2005
Jonathan Burd <> wrote:

> Of course, casting the result of malloc is a bad idea when using
> standard C. However, most GNU code uses casts to make code compilable on
> pre-ANSI compilers.


You surprise me. I thought most GNU code was intentionally written to be
compilable on Ganuck, and Ganuck only. Other C compilers need not
comply; pre-ANSI compilers are laughed away.

Richard
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      02-21-2005
(Richard Bos) writes:

> I thought most GNU code was intentionally written to be
> compilable on Ganuck, and Ganuck only.


Most GNU programs compile on a wide range of C implementations.
--
"I should killfile you where you stand, worthless human." --Kaz
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      02-23-2005
Ben Pfaff <> wrote:

> (Richard Bos) writes:
>
> > I thought most GNU code was intentionally written to be
> > compilable on Ganuck, and Ganuck only.

>
> Most GNU programs compile on a wide range of C implementations.


Do the gcc team know this? They must be tearing their hair out.

Richard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
regexec from regex.h Segmentation fault al.moorthi@gmail.com C Programming 3 02-04-2008 04:03 PM
facing problem while using regexec apoorva.groups@gmail.com C Programming 2 12-07-2007 05:07 PM
order of subexpression evaluation mario semo C++ 2 06-27-2006 10:44 AM
Help wih regexec() function in libc.a library ( Solaris platform) zoltan C Programming 2 03-13-2006 08:43 AM
AST Manipulation and Common Subexpression Elimination Robert Kern Python 6 10-20-2003 09:49 AM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57