Re: Command Languages Versus Programming Languages

cross@spitfire.i.gajendra.net (Dan Cross) writes:

Rainer Weikusat  <rweikusat@talktalk.net> wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

Rainer Weikusat  <rweikusat@talktalk.net> wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

[snip]
It's also not exactly right.  `[0-9]+` would match one or more
characters; this possibly matches 0 (ie, if `p` pointed to
something that wasn't a digit).

>
The regex won't match any digits if there aren't any. In this case, the
match will fail. I didn't include the code for handling that because it
seemed pretty pointless for the example.

>
That's rather the point though, isn't it?  The program snippet
(modulo the promotion to signed int via the "usual arithmetic
conversions" before the subtraction and comparison giving you
unexpected values; nothing to do with whether `char` is signed
or not) is a snippet that advances a pointer while it points to
a digit, starting at the current pointer position; that is, it
just increments a pointer over a run of digits.

>
That's the core part of matching someting equivalent to the regex [0-9]+
and the only part of it is which is at least remotely interesting.

>
Not really, no.  The interesting thing in this case appears to
be knowing whether or not the match succeeded, but you omited
that part.

This of interest to you as it enables you to base an 'argumentation'
(sarcasm) on arbitrary assumptions you've chosen to make. It's not
something I consider interesting and it's besides the point of the
example I posted.

But that's not the same as a regex matcher, which has a semantic
notion of success or failure.  I could run your snippet against
a string such as, say, "ZZZZZZ" and it would "succeed" just as
it would against an empty string or a string of one or more
digits.

>
Why do you believe that p being equivalent to the starting position
would be considered a "successful match", considering that this
obviously doesn't make any sense?

>
Because absent any surrounding context, there's no indication
that the source is even saved.

A text usually doesn't contain information about things which aren't
part of its content. I congratulate you to this rather obvious observation.

[...]

Something which would match [0-9]+ in its first argument (if any) would
be:
>
#include "string.h"
#include "stdlib.h"
>
int main(int argc, char **argv)
{
   char *p;
   unsigned c;
>
   p = argv[1];
   if (!p) exit(1);
   while (c = *p, c && c - '0' > 10) ++p;
   if (!c) exit(1);
   return 0;
}
>
but that's 14 lines of text, 13 of which have absolutely no relation to
the problem of recognizing a digit.

>
This is wrong in many ways.  Did you actually test that program?
>
First of all, why `"string.h"` and not `<string.h>`?  Ok, that's
not technically an error, but it's certainly unconventional, and
raises questions that are ultimately a distraction.

Such as your paragraph above.

Second, suppose that `argc==0` (yes, this can happen under
POSIX).

It can happen in case of some piece of functionally hostile software
intentionally creating such a situation. Tangential, irrelevant
point. If you break it, you get to keep the parts.

Third, the loop: why `> 10`? Don't you mean `< 10`?  You are
trying to match digits, not non-digits.

Mistake I made. The opposite of < 10 is > 9.

Fourth, you exit with failure (`exit(1)`) if `!p` *and* if `!c`
at the end, but `!c` there means you've reached the end of the
string; which should be success.

Mistake you made: [0-9]+ matches if there's at least one digit in the
string. That's why the loop terminates once one was found. In this case,
c cannot be 0.