Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #4207 > unrolled thread

how to use regex library

Back to article view | Back to comp.lang.c

Contents

  how to use regex library Owner <Owner@Owner-PC.com> - 2011-05-17 23:11 -0400
    Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-18 03:33 +0000
      Re: how to use regex library Owner <Owner@Owner-PC.com> - 2011-05-18 06:41 -0400
        Re: how to use regex library James Kuyper <jameskuyper@verizon.net> - 2011-05-18 08:00 -0400
          Re: how to use regex library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-18 20:00 +0100
            Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-18 19:44 +0000
              Re: how to use regex library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 00:43 +0100
                Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-19 00:52 +0000
                  Re: how to use regex library Owner <Owner@Owner-PC.com> - 2011-05-18 22:04 -0400
                    Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-19 02:21 +0000
                      Re: how to use regex library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 04:04 +0100
                        Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-19 03:14 +0000
                          Re: how to use regex library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 12:03 +0100
                            Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-19 14:37 +0000
                              Re: how to use regex library Geoff <geoff@invalid.invalid> - 2011-05-19 11:29 -0700
                                Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-19 19:08 +0000
                                  Re: how to use regex library Geoff <geoff@invalid.invalid> - 2011-05-19 12:11 -0700
                                  Re: how to use regex library Kenneth Brody <kenbrody@spamcop.net> - 2011-05-20 12:55 -0400
                  Re: how to use regex library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 04:01 +0100
              Re: how to use regex library cri@tiac.net (Richard Harter) - 2011-05-19 16:02 +0000
                Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-19 16:34 +0000
                  Re: how to use regex library Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 13:59 -0700
                    Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-19 22:06 +0000
                      Re: how to use regex library Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-24 02:03 -0700
                    Re: how to use regex library Kenneth Brody <kenbrody@spamcop.net> - 2011-05-20 13:14 -0400
                      Re: how to use regex library Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-24 02:16 -0700
              Re: how to use regex library Kenneth Brody <kenbrody@spamcop.net> - 2011-05-19 14:37 -0400
            Re: how to use regex library James Kuyper <jameskuyper@verizon.net> - 2011-05-18 19:44 -0400
              Re: how to use regex library Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 03:49 +0100
                Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-19 03:03 +0000
                  Re: how to use regex library Ike Naar <ike@iceland.freeshell.org> - 2011-05-19 06:48 +0000
                    Re: how to use regex library James Kuyper <jameskuyper@verizon.net> - 2011-05-19 05:58 -0400
                    Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-19 14:37 +0000
              Re: how to use regex library Kenneth Brody <kenbrody@spamcop.net> - 2011-05-19 14:48 -0400
                Re: how to use regex library Shao Miller <sha0.miller@gmail.com> - 2011-05-19 15:05 -0400
        Re: how to use regex library Mark Bluemel <mark_bluemel@pobox.com> - 2011-05-18 13:36 +0100
          Re: how to use regex library Owner <Owner@Owner-PC.com> - 2011-05-18 13:13 -0400
          Re: how to use regex library Owner <Owner@Owner-PC.com> - 2011-05-18 22:13 -0400
            Re: how to use regex library Mark Bluemel <mark_bluemel@pobox.com> - 2011-05-19 08:55 +0100
              Re: how to use regex library Owner <Owner@Owner-PC.com> - 2011-05-19 07:59 -0400
                Re: how to use regex library Keith Thompson <kst-u@mib.org> - 2011-05-19 08:50 -0700
                Re: how to use regex library Owner <Owner@Owner-PC.com> - 2011-05-19 15:12 -0400
                  Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-19 19:40 +0000
                    Re: how to use regex library cri@tiac.net (Richard Harter) - 2011-05-19 20:58 +0000
                      Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-19 22:06 +0000
                        Re: how to use regex library cri@tiac.net (Richard Harter) - 2011-05-20 01:01 +0000
                          Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-20 01:57 +0000
                        Re: how to use regex library Kenneth Brody <kenbrody@spamcop.net> - 2011-05-20 13:27 -0400
                      Re: how to use regex library Kenneth Brody <kenbrody@spamcop.net> - 2011-05-20 13:08 -0400
                        Re: how to use regex library Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-20 18:54 +0100
                          Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-20 19:14 +0000
                            Re: how to use regex library Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-21 00:04 +0100
                          Re: how to use regex library Kenneth Brody <kenbrody@spamcop.net> - 2011-05-23 12:42 -0400
                            Re: how to use regex library Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-23 20:16 +0100
                        Re: how to use regex library cri@tiac.net (Richard Harter) - 2011-05-23 21:16 +0000
                          Re: how to use regex library Kenneth Brody <kenbrody@spamcop.net> - 2011-05-24 12:08 -0400
                            Re: how to use regex library cri@tiac.net (Richard Harter) - 2011-05-25 05:27 +0000
                      Re: how to use regex library Michael Press <rubrum@pacbell.net> - 2011-05-22 21:41 -0700
                        Re: how to use regex library cri@tiac.net (Richard Harter) - 2011-05-23 21:33 +0000
        Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-18 16:03 +0000
      Re: how to use regex library Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-18 14:05 +0000
    Re: how to use regex library Owner <Owner@Owner-PC.com> - 2011-05-20 22:06 -0400
      Re: how to use regex library Seebs <usenet-nospam@seebs.net> - 2011-05-21 03:49 +0000
        Re: how to use regex library Owner <Owner@Owner-PC.com> - 2011-05-21 20:25 -0400
      Re: how to use regex library Shao Miller <sha0.miller@gmail.com> - 2011-05-21 13:17 -0500

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#4334

Owner <Owner@Owner-PC.com> writes:
>> Try spending more time looking at the information you have rather than 
>> asking other people to do your thinking for you.
>
> Sorry to bother you again.  
>
> Now I get it some of it.  My mind was stick to the getting a matched
>
> position and length, I didn't see that getting those information is
>
> irrelevant.  And the library provides mainly whether there is 
>
> a match, and routine for replacing matched string.  
[...]

Please don't double-space your text like this.  It just makes it more
difficult to read.  Use paragraphs to separate paragraphs, not lines.

See the vast majority of articles in this newsgroup for examples.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#4358

I got one more problem.  I dont' think Man page mentioned
about second matching on the same string, when I read it.
I tried call "i = regexec(r, argv[2]);" twice, but didn't move
forward after first match.  I did found however
"i = regexec(r, r->endp[0]);" matches the second substring.
but I don't think it's meant to be used this way.
How do you match same pattern more than twice on the same line?

[toc] | [prev] | [next] | [standalone]

#4360

On 2011-05-19, Owner <Owner@Owner-PC.com> wrote:
> I got one more problem.  I dont' think Man page mentioned
> about second matching on the same string, when I read it.
> I tried call "i = regexec(r, argv[2]);" twice, but didn't move
> forward after first match.  I did found however
> "i = regexec(r, r->endp[0]);" matches the second substring.
> but I don't think it's meant to be used this way.
> How do you match same pattern more than twice on the same line?

Well, typically, you would find a point in the line after the first
match, and use regexec to match there.

Why don't you think it's meant to be used this way?  What seems unusual
to you about using the endpoint of a previous match as the starting place
to look to see whether there are any more matches?  Why would you think
that it would "move forward" after the first match?

Let's translate this all into plain language.

Consider this string.  We need a name for it, let's call it "Bob".
	"hello, world, hello, dolly, hello, sailor".

Now, I ask you:  Does Bob contain the word hello?  If so, where?

You respond with something like:
	Yes: ">hello<, world, hello, dolly, hello, sailor".

Okay.  Now I ask you:  Does Bob contain the word hello?  If so, where?

Why would your answer be different?  I didn't ask you a different
question.  Nothing changed.  The string isn't different from what it
used to be.  It would be ridiculous for your answer to be different.

Now, imagine instead that I asked you "Does Bob contain the word hello
somewhere after the 5th character?  If so, where?", then you might
respond:
	Yes: ", world, >hello<, dolly, hello, sailor".

Computers do exactly what you ask them to.  They do not do what you
meant, and they don't care whether you just asked them that two seconds
ago; they're just going to keep answering the question you asked.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#4369

On 19 May 2011 19:40:38 GMT, Seebs <usenet-nospam@seebs.net> wrote:

>On 2011-05-19, Owner <Owner@Owner-PC.com> wrote:
>> I got one more problem.  I dont' think Man page mentioned
>> about second matching on the same string, when I read it.
>> I tried call "i = regexec(r, argv[2]);" twice, but didn't move
>> forward after first match.  I did found however
>> "i = regexec(r, r->endp[0]);" matches the second substring.
>> but I don't think it's meant to be used this way.
>> How do you match same pattern more than twice on the same line?
>
>Well, typically, you would find a point in the line after the first
>match, and use regexec to match there.
>
>Why don't you think it's meant to be used this way?  What seems unusual
>to you about using the endpoint of a previous match as the starting place
>to look to see whether there are any more matches?  Why would you think
>that it would "move forward" after the first match?

Because that is a quite reasonable expectation.  Many search
facilities operate either operate that way or they have a 'next
instance' command.  It is misleading to say that computers 'do what
you tell them to do'.  Unless you are programming down to the bare
iron you don't tell computers what to do - you tell some piece of
software what to do.  What that software does is (sometimes) what the
programmer who wrote it decided it ought to do.  It is a serious
mistake to blame the computer for the design errors of the software
creators.

[snip very good example]

[toc] | [prev] | [next] | [standalone]

#4389

On 2011-05-19, Richard Harter <cri@tiac.net> wrote:
> Because that is a quite reasonable expectation.

Is it?

I can certainly see it being one of the possible outcomes, but I wouldn't
*expect* it.

> Many search
> facilities operate either operate that way or they have a 'next
> instance' command.

This is true, but some don't.  And I guess that's the thing; I might
anticipate the possibility of an interface doing something, but if I
test it and it doesn't, that's not usually going to be a major source
of confusion.

In C, if I write sqrt(1), I don't expect to get 1 the first time I call
it and -1 the second time I call it.  In general, unless an interface
is specified otherwise, I expect it to behave the same way every time,
and nearly all the interfaces that are specified otherwise, we avoid
like the plague because they're bugs waiting to happen.

*cough*strtok*cough*.

> It is misleading to say that computers 'do what
> you tell them to do'.  Unless you are programming down to the bare
> iron you don't tell computers what to do - you tell some piece of
> software what to do.  What that software does is (sometimes) what the
> programmer who wrote it decided it ought to do.  It is a serious
> mistake to blame the computer for the design errors of the software
> creators.

True enough, but in C, you generally have a pretty good bet that something
will do what it says it does.  If it doesn't say "repeated calls with the
same arguments will do different things", then they probably won't.  :)

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#4403

On 19 May 2011 22:06:22 GMT, Seebs <usenet-nospam@seebs.net> wrote:

>On 2011-05-19, Richard Harter <cri@tiac.net> wrote:
>> Because that is a quite reasonable expectation.
>
>Is it?
>
>I can certainly see it being one of the possible outcomes, but I wouldn't
>*expect* it.

I wouldn't expect that you would expect it.  But that doesn't mean it
isn't reasonable.
>
>> Many search
>> facilities operate either operate that way or they have a 'next
>> instance' command.
>
>This is true, but some don't.  And I guess that's the thing; I might
>anticipate the possibility of an interface doing something, but if I
>test it and it doesn't, that's not usually going to be a major source
>of confusion.

I would have thought you would have read the documentation first - I
may be wrong but that seems like a reasonable expectation to me.

>
>In C, if I write sqrt(1), I don't expect to get 1 the first time I call
>it and -1 the second time I call it.

Sqrt is a search function?  

>In general, unless an interface
>is specified otherwise, I expect it to behave the same way every time,
>and nearly all the interfaces that are specified otherwise, we avoid
>like the plague because they're bugs waiting to happen.
>
>*cough*strtok*cough*.

I'm with you.  I expect fgets to return the same line each time I call
it.  :-)

More seriously, there is a difference between "returns the same
result" and "behaves the same way".
>
>> It is misleading to say that computers 'do what
>> you tell them to do'.  Unless you are programming down to the bare
>> iron you don't tell computers what to do - you tell some piece of
>> software what to do.  What that software does is (sometimes) what the
>> programmer who wrote it decided it ought to do.  It is a serious
>> mistake to blame the computer for the design errors of the software
>> creators.
>
>True enough, but in C, you generally have a pretty good bet that something
>will do what it says it does.  If it doesn't say "repeated calls with the
>same arguments will do different things", then they probably won't.  :)


Except when they do.   :-)

[toc] | [prev] | [next] | [standalone]

#4407

On 2011-05-20, Richard Harter <cri@tiac.net> wrote:
> I wouldn't expect that you would expect it.  But that doesn't mean it
> isn't reasonable.

I tend to feel that forming a definite expectation is counterproductive
in the absence of clear data.

> I would have thought you would have read the documentation first - I
> may be wrong but that seems like a reasonable expectation to me.

Well, I'm assuming for the sake of argument that the documentation is
unclear on the issue, because otherwise why would I get to the point of
posting on Usenet about it?

>>In C, if I write sqrt(1), I don't expect to get 1 the first time I call
>>it and -1 the second time I call it.

> Sqrt is a search function?  

No, but it's a function which tells me something about its argument.

>>In general, unless an interface
>>is specified otherwise, I expect it to behave the same way every time,
>>and nearly all the interfaces that are specified otherwise, we avoid
>>like the plague because they're bugs waiting to happen.

>>*cough*strtok*cough*.

> I'm with you.  I expect fgets to return the same line each time I call
> it.  :-)

> More seriously, there is a difference between "returns the same
> result" and "behaves the same way".

Yes.

But fundamentally, asking whether a string matches a pattern does not
consume the string.  Asking for the next line of input consumes input.

I wouldn't expect a regex function to consume the string, because the
string is const-qualified.

>>True enough, but in C, you generally have a pretty good bet that something
>>will do what it says it does.  If it doesn't say "repeated calls with the
>>same arguments will do different things", then they probably won't.  :)

> Except when they do.   :-)

Sure.  But generally there's a clear reason for which that has to happen,
or it's explicit that that's what happens.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#4441

On 5/19/2011 6:06 PM, Seebs wrote:
[...]
> In C, if I write sqrt(1), I don't expect to get 1 the first time I call
> it and -1 the second time I call it.  In general, unless an interface
> is specified otherwise, I expect it to behave the same way every time,
> and nearly all the interfaces that are specified otherwise, we avoid
> like the plague because they're bugs waiting to happen.
>
> *cough*strtok*cough*.
[...]

7.21.5.8p2:

     The first call in the sequence has a non-null first argument;
     subsequent calls in the sequence have a null first argument.

Note that, unlike "owner"'s attempt to call regexec() with the same pointer, 
strtok() requires that you pass NULL for a "get next" functionality.

Of course, strtok() modifies the original string, but repeatedly calling it 
with the same values will still return the same thing each time.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#4438

On 5/19/2011 4:58 PM, Richard Harter wrote:
> On 19 May 2011 19:40:38 GMT, Seebs<usenet-nospam@seebs.net>  wrote:
>
>> On 2011-05-19, Owner<Owner@Owner-PC.com>  wrote:
>>> I got one more problem.  I dont' think Man page mentioned
>>> about second matching on the same string, when I read it.
>>> I tried call "i = regexec(r, argv[2]);" twice, but didn't move
>>> forward after first match.  I did found however
>>> "i = regexec(r, r->endp[0]);" matches the second substring.
>>> but I don't think it's meant to be used this way.
>>> How do you match same pattern more than twice on the same line?
>>
>> Well, typically, you would find a point in the line after the first
>> match, and use regexec to match there.
>>
>> Why don't you think it's meant to be used this way?  What seems unusual
>> to you about using the endpoint of a previous match as the starting place
>> to look to see whether there are any more matches?  Why would you think
>> that it would "move forward" after the first match?
>
> Because that is a quite reasonable expectation.  Many search
> facilities operate either operate that way or they have a 'next
> instance' command.

Yes, but then they have separate "get first" and "get next" calls, or they 
have "initialize" and "do it" calls, or some other method of saying 
"continue from where you left off".

If all you pass it is a regex and a buffer pointer, why would you expect it 
to do a "get next" on the second call?  If you expect the answer to be 
"because I passed the _same_ pointer both times, so it should 'know' I meant 
to do 'get next' on it", then how would you ever use it in a loop where the 
same buffer is passed, though the contents have changed?  (For example, 
something like "grep", which would print any line that has a match to the 
regex.)


>  It is misleading to say that computers 'do what
> you tell them to do'.  Unless you are programming down to the bare
> iron you don't tell computers what to do - you tell some piece of
> software what to do.  What that software does is (sometimes) what the
> programmer who wrote it decided it ought to do.  It is a serious
> mistake to blame the computer for the design errors of the software
> creators.

Well, in that case "you" told the computer to use a defective piece of 
software, and it did just that.  :-)

> [snip very good example]



-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#4445

Kenneth Brody <kenbrody@spamcop.net> writes:

> If all you pass it is a regex and a buffer pointer, why would you
> expect it to do a "get next" on the second call?  If you expect the
> answer to be "because I passed the _same_ pointer both times, so it
> should 'know' I meant to do 'get next' on it", then how would you ever
> use it in a loop where the same buffer is passed, though the contents
> have changed?  (For example, something like "grep", which would print
> any line that has a match to the regex.)

It could store a hash of the search string somewhere in the (opaque)
compiled regexp.

I know, I know.  But I want to exercise my angels.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#4454

On 2011-05-20, Dr Nick <3-nospam@temporary-address.org.uk> wrote:
> Kenneth Brody <kenbrody@spamcop.net> writes:
>> If all you pass it is a regex and a buffer pointer, why would you
>> expect it to do a "get next" on the second call?  If you expect the
>> answer to be "because I passed the _same_ pointer both times, so it
>> should 'know' I meant to do 'get next' on it", then how would you ever
>> use it in a loop where the same buffer is passed, though the contents
>> have changed?  (For example, something like "grep", which would print
>> any line that has a match to the regex.)

> It could store a hash of the search string somewhere in the (opaque)
> compiled regexp.

That's const-qualified.

I'm pretty sure that it would, at the very least, violate the spirit of
the interface for the compiled regexp to be modified in any way.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#4471

Seebs <usenet-nospam@seebs.net> writes:

> On 2011-05-20, Dr Nick <3-nospam@temporary-address.org.uk> wrote:
>> Kenneth Brody <kenbrody@spamcop.net> writes:
>>> If all you pass it is a regex and a buffer pointer, why would you
>>> expect it to do a "get next" on the second call?  If you expect the
>>> answer to be "because I passed the _same_ pointer both times, so it
>>> should 'know' I meant to do 'get next' on it", then how would you ever
>>> use it in a loop where the same buffer is passed, though the contents
>>> have changed?  (For example, something like "grep", which would print
>>> any line that has a match to the regex.)
>
>> It could store a hash of the search string somewhere in the (opaque)
>> compiled regexp.
>
> That's const-qualified.

OK, so when you regcomp it could put a unique key into the compiled
regexp, that points into a hidden memory area where it stores ...

>
> I'm pretty sure that it would, at the very least, violate the spirit of
> the interface for the compiled regexp to be modified in any way.

Oh yes.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#4567

On 5/20/2011 1:54 PM, Dr Nick wrote:
> Kenneth Brody<kenbrody@spamcop.net>  writes:
>
>> If all you pass it is a regex and a buffer pointer, why would you
>> expect it to do a "get next" on the second call?  If you expect the
>> answer to be "because I passed the _same_ pointer both times, so it
>> should 'know' I meant to do 'get next' on it", then how would you ever
>> use it in a loop where the same buffer is passed, though the contents
>> have changed?  (For example, something like "grep", which would print
>> any line that has a match to the regex.)
>
> It could store a hash of the search string somewhere in the (opaque)
> compiled regexp.

And when your grep-like code reads two identical lines in a row from the file?

> I know, I know.  But I want to exercise my angels.

That pin-head is getting a bit cramped?  :-)

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#4579

Kenneth Brody <kenbrody@spamcop.net> writes:

> On 5/20/2011 1:54 PM, Dr Nick wrote:
>> Kenneth Brody<kenbrody@spamcop.net>  writes:
>>
>>> If all you pass it is a regex and a buffer pointer, why would you
>>> expect it to do a "get next" on the second call?  If you expect the
>>> answer to be "because I passed the _same_ pointer both times, so it
>>> should 'know' I meant to do 'get next' on it", then how would you ever
>>> use it in a loop where the same buffer is passed, though the contents
>>> have changed?  (For example, something like "grep", which would print
>>> any line that has a match to the regex.)
>>
>> It could store a hash of the search string somewhere in the (opaque)
>> compiled regexp.
>
> And when your grep-like code reads two identical lines in a row from the file?

Curse you!  Foiled again.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

[toc] | [prev] | [next] | [standalone]

#4595

On Fri, 20 May 2011 13:08:14 -0400, Kenneth Brody
<kenbrody@spamcop.net> wrote:

>On 5/19/2011 4:58 PM, Richard Harter wrote:
>> On 19 May 2011 19:40:38 GMT, Seebs<usenet-nospam@seebs.net>  wrote:
>>
>>> On 2011-05-19, Owner<Owner@Owner-PC.com>  wrote:
>>>> I got one more problem.  I dont' think Man page mentioned
>>>> about second matching on the same string, when I read it.
>>>> I tried call "i = regexec(r, argv[2]);" twice, but didn't move
>>>> forward after first match.  I did found however
>>>> "i = regexec(r, r->endp[0]);" matches the second substring.
>>>> but I don't think it's meant to be used this way.
>>>> How do you match same pattern more than twice on the same line?
>>>
>>> Well, typically, you would find a point in the line after the first
>>> match, and use regexec to match there.
>>>
>>> Why don't you think it's meant to be used this way?  What seems unusual
>>> to you about using the endpoint of a previous match as the starting place
>>> to look to see whether there are any more matches?  Why would you think
>>> that it would "move forward" after the first match?
>>
>> Because that is a quite reasonable expectation.  Many search
>> facilities operate either operate that way or they have a 'next
>> instance' command.
>
>Yes, but then they have separate "get first" and "get next" calls, or they 
>have "initialize" and "do it" calls, or some other method of saying 
>"continue from where you left off".

Or else the first call initializes the search.  
>
>If all you pass it is a regex and a buffer pointer, why would you expect it 
>to do a "get next" on the second call?  If you expect the answer to be 
>"because I passed the _same_ pointer both times, so it should 'know' I meant 
>to do 'get next' on it", then how would you ever use it in a loop where the 
>same buffer is passed, though the contents have changed?  (For example, 
>something like "grep", which would print any line that has a match to the 
>regex.)

You seem to be just saying "it won't work" without actually thinking
it out.  The issue at hand is the possibility of a regexec based
search that is passed a buffer address; each time it is called with
the same buffer address it returns the next match until there are no
more matches.  There are three separate issues - can it be done,
should it be done, and is it reasonable to expect it.  

The "can it be done" is fairly trivial.  What is needed is a bit of
memory.  One way to do it is to have two pointers, one to the buffer
currently being processed, and one to the next search point.
Initially the pointers are set 0,0.  If the buffer being passed in
does not match the stored buffer we set the pointers to
(buffer,buffer).   In other words we reinitialize every time we change
buffers.  Next we search for a match beginning at the search point.
If no match is found we reset to (0,0) and return no match.  If a
match is found we (a) reinitialize if the buffer is exhausted, or
(b)we set the next search point. That done, we return the found match.

The "should it be done" is another matter.  The plus side is that it
saves boilerplate code in the calling program.  The down side is that
it requires state memory.  This could be in the regexec struct, in the
calling program, or in the search routine.

Finally, "is it reasonable to expect it?"  That depends.  For
implementers who are wedded to the thought that "buffer" must be the
search point, probably not.  For users who want a bit of convenience,
probably. 

    
>
>
>>  It is misleading to say that computers 'do what
>> you tell them to do'.  Unless you are programming down to the bare
>> iron you don't tell computers what to do - you tell some piece of
>> software what to do.  What that software does is (sometimes) what the
>> programmer who wrote it decided it ought to do.  It is a serious
>> mistake to blame the computer for the design errors of the software
>> creators.
>
>Well, in that case "you" told the computer to use a defective piece of 
>software, and it did just that.  :-)

Or not at all.  :-)

[toc] | [prev] | [next] | [standalone]

#4704

On 5/23/2011 5:16 PM, Richard Harter wrote:
> On Fri, 20 May 2011 13:08:14 -0400, Kenneth Brody
> <kenbrody@spamcop.net>  wrote:
[...]
>> If all you pass it is a regex and a buffer pointer, why would you expect it
>> to do a "get next" on the second call?  If you expect the answer to be
>> "because I passed the _same_ pointer both times, so it should 'know' I meant
>> to do 'get next' on it", then how would you ever use it in a loop where the
>> same buffer is passed, though the contents have changed?  (For example,
>> something like "grep", which would print any line that has a match to the
>> regex.)
>
> You seem to be just saying "it won't work" without actually thinking
> it out.

Well, by "work", I require more functionality than simply an implicit "next" 
ability by passing the same parameters repeatedly.  (See below.)

> The issue at hand is the possibility of a regexec based
> search that is passed a buffer address; each time it is called with
> the same buffer address it returns the next match until there are no
> more matches.  There are three separate issues - can it be done,
> should it be done, and is it reasonable to expect it.
>
> The "can it be done" is fairly trivial.  What is needed is a bit of
> memory.  One way to do it is to have two pointers, one to the buffer
[...]
> If no match is found we reset to (0,0) and return no match.  If a
> match is found we (a) reinitialize if the buffer is exhausted, or
> (b)we set the next search point. That done, we return the found match.

Sure, it "can be done".  The problem with that approach is there is no way 
for force a restart.  Unless, of course, you include an "init" call, which 
is what this thread assumes is lacking.

It is not unreasonable to reuse the same buffer on multiple searches, 
including the possibility that a subsequent call will contain the same data 
in the buffer, despite wanting to restart the search.

[...]
> Finally, "is it reasonable to expect it?"  That depends.  For
> implementers who are wedded to the thought that "buffer" must be the
> search point, probably not.  For users who want a bit of convenience,
> probably.

I, personally, find a function which does an implicit "next", without any 
way to explicitly "init", very distasteful.  That is, of course, just my 
personal opinion, though it is based on 27+ years of using and writing 
enumerator functions in C.  YMMV.

[...]

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#4744

On Tue, 24 May 2011 12:08:43 -0400, Kenneth Brody
<kenbrody@spamcop.net> wrote:

>On 5/23/2011 5:16 PM, Richard Harter wrote:
>> On Fri, 20 May 2011 13:08:14 -0400, Kenneth Brody
>> <kenbrody@spamcop.net>  wrote:
>[...]
>>> If all you pass it is a regex and a buffer pointer, why would you expect it
>>> to do a "get next" on the second call?  If you expect the answer to be
>>> "because I passed the _same_ pointer both times, so it should 'know' I meant
>>> to do 'get next' on it", then how would you ever use it in a loop where the
>>> same buffer is passed, though the contents have changed?  (For example,
>>> something like "grep", which would print any line that has a match to the
>>> regex.)
>>
>> You seem to be just saying "it won't work" without actually thinking
>> it out.
>
>Well, by "work", I require more functionality than simply an implicit "next" 
>ability by passing the same parameters repeatedly.  (See below.)

Codswallop.  (See below.)
>
>> The issue at hand is the possibility of a regexec based
>> search that is passed a buffer address; each time it is called with
>> the same buffer address it returns the next match until there are no
>> more matches.  There are three separate issues - can it be done,
>> should it be done, and is it reasonable to expect it.
>>
>> The "can it be done" is fairly trivial.  What is needed is a bit of
>> memory.  One way to do it is to have two pointers, one to the buffer
>[...]
>> If no match is found we reset to (0,0) and return no match.  If a
>> match is found we (a) reinitialize if the buffer is exhausted, or
>> (b)we set the next search point. That done, we return the found match.
>
>Sure, it "can be done".  The problem with that approach is there is no way 
>for force a restart.  Unless, of course, you include an "init" call, which 
>is what this thread assumes is lacking.
>
>It is not unreasonable to reuse the same buffer on multiple searches, 
>including the possibility that a subsequent call will contain the same data 
>in the buffer, despite wanting to restart the search.

Now really, you should try a little harder than that.  The obvious way
to force a restart is to pass in a buffer address of 0.  

Since you seem to have difficulty coming up with a valid objection,
let me help you.  Consider what happens if you have two buffers, call
them a and b, and you want to alternate between them.  First you
search a and get the its first match.  Next you search b and get its
first match.  Now you go back to a to get its second match.  Oops,
you've just reset the stored buffer so you get the first match.

So, have we shown that the scheme doesn't work.  No, we haven't.  We
could do what we would have to do anyway your "pass in the current
start point", namely pass in the current start point.

What we have shown is that we cannot consistently rely on the scheme
to do the right thing by default.  In other words the magic only works
some of the time.  That's the argument you should have been making.

   
>
>[...]
>> Finally, "is it reasonable to expect it?"  That depends.  For
>> implementers who are wedded to the thought that "buffer" must be the
>> search point, probably not.  For users who want a bit of convenience,
>> probably.
>
>I, personally, find a function which does an implicit "next", without any 
>way to explicitly "init", very distasteful.  That is, of course, just my 
>personal opinion, though it is based on 27+ years of using and writing 
>enumerator functions in C.  YMMV.

Since your objections were specious they provide no legitimate basis
for distaste.  On the other hand, your personal opinions are data.  In
my 28+ years of using and writing C my view has been that it is better
to think things out instead of relying on gut emotion.  YMMV.

     

[toc] | [prev] | [next] | [standalone]

#4542

In article <4dd5822c.3772884@text.giganews.com>,
 cri@tiac.net (Richard Harter) wrote:

> On 19 May 2011 19:40:38 GMT, Seebs <usenet-nospam@seebs.net> wrote:
> 
> >On 2011-05-19, Owner <Owner@Owner-PC.com> wrote:
> >> I got one more problem.  I dont' think Man page mentioned
> >> about second matching on the same string, when I read it.
> >> I tried call "i = regexec(r, argv[2]);" twice, but didn't move
> >> forward after first match.  I did found however
> >> "i = regexec(r, r->endp[0]);" matches the second substring.
> >> but I don't think it's meant to be used this way.
> >> How do you match same pattern more than twice on the same line?
> >
> >Well, typically, you would find a point in the line after the first
> >match, and use regexec to match there.
> >
> >Why don't you think it's meant to be used this way?  What seems unusual
> >to you about using the endpoint of a previous match as the starting place
> >to look to see whether there are any more matches?  Why would you think
> >that it would "move forward" after the first match?
> 
> Because that is a quite reasonable expectation.  Many search
> facilities operate either operate that way or they have a 'next
> instance' command.  It is misleading to say that computers 'do what
> you tell them to do'.  Unless you are programming down to the bare
> iron you don't tell computers what to do - you tell some piece of
> software what to do.  What that software does is (sometimes) what the
> programmer who wrote it decided it ought to do.  It is a serious
> mistake to blame the computer for the design errors of the software
> creators.

Even the bare iron was designed by a person/design team. 
It is often useful to think of the carefully designed
constellation of programs as a machine. It responds the
same to the same inputs---very machine like. Yes, it is
also extremely useful to remember that the piece of
garbage frustrating my efforts to make good use of it
was put together by a brain damaged time server; but
Seebs metaphor of the human designed interface as a computer 
is well taken where he used it.

-- 
Michael Press

[toc] | [prev] | [next] | [standalone]

#4600

On Sun, 22 May 2011 21:41:52 -0700, Michael Press <rubrum@pacbell.net>
wrote:

>In article <4dd5822c.3772884@text.giganews.com>,
> cri@tiac.net (Richard Harter) wrote:
[snip]

>Even the bare iron was designed by a person/design team. 
>It is often useful to think of the carefully designed
>constellation of programs as a machine. It responds the
>same to the same inputs---very machine like. Yes, it is
>also extremely useful to remember that the piece of
>garbage frustrating my efforts to make good use of it
>was put together by a brain damaged time server; but
>Seebs metaphor of the human designed interface as a computer 
>is well taken where he used it.

Point well taken.  That said, it's a bit misleading to say "It
responds the same to the same inputs".  If by "the same inputs" you
mean the entire history of inputs to the "machine", that is a
reasonable expectation.  If one is talking about a particular sequence
of inputs, not necessarily.  The "machine" has a state that changes
over time.  It only responds the same if the changes in state don't
happen to matter.

[toc] | [prev] | [next] | [standalone]

#4228

On 2011-05-18, Owner <Owner@Owner-PC.com> wrote:
> I apologize for vagueness.  I'm asking to anyone knows how to use
> henry spencer's regex library.

Well, sure, but again...  What on earth are you using that doesn't have
one already?

> I expected to send RE pattern
> and target string to the library, then it send me back with either
> match was found of not, if found send me back position in the
> target string and length of matched string.

That is indeed what it does.

> but when I saw
> the only file with main(); try.c, quickly I got confused.

This is not specific.

> I got lost and don't even know how to use the henry spencer's 
> lib functions(even though I have copy of it).  that's why I called 
> for help.  Just getting a small clue wouldbe make this question 
> wealthy.  thank you

Okay, here's the clue:

	http://www.catb.org/~esr/faqs/smart-questions.html

Read that.  Think about it.  Then try to ask a smart question.

Here's some food for thought:

* Why don't you start by reading the documentation?
* If you have access to any sort of Unix-like system, consider reading the
  docs for the regular expression library the system *already has*.
* In fact, if Windows systems don't have one too, that would sort of surprise
  me, this is very basic functionality.
* What you may be missing is that taking a regular expression string and
  converting it into something that can be quickly and efficiently processed
  is computationally expensive...
* ... and most programs which use a regular expression use it more than once.
* Because of this, regex libraries typically separate out the "compilation"
  of a regex from a string into an internal data structure, and the use of
  that data structure to match stuff.

But seriously, this question is really too vague to do anything with.  You
don't give us any clue what you want to do, what you've tried, or whether
you even know what "documentation" is, let alone whether you've read it.
Saying that you are confused by reading example code suggests that you haven't
yet looked at documentation.

Try using regcomp, regexec, and then regfree, in that order.  If that's
not enough of a clue, you really are going to have to learn to ask better
questions.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web