tech-misc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: "stop and wait" scanf [was Re: Bug in TRE regular expression library]



On 20.07.2010 22:53, der Mouse wrote:

>> I never put any thought into this scanf arguments, simply because
>> > they serve a single purpose: Stop the application so I can read its
>> > output and press any key to quit quickly.  Works fine for me here.
>
> It actually looks as though you meant to write "%*s" but got the * and
> % switched.  %*s is not quite what you want either, since it will
> silently consume whitespace, including newlines.

As I thought about it once more and read some docs I recall that
scanf("%*s") is indeed what I intended. Thanks for the clearing this up.

>You might want %*c,
> but that will consume only the next character, rather than up to the
> next newline (which I suspect is what you want) - scanf("%*c") is
> pretty much the same as getchar() in this use.

I tested and found that getchar(), scanf("%*c"), and scanf("%*s") are
working likewise well for my purpose.

> There is actually a syntax that is very close to what I think you want:
> scanf("%*[^\n]").  The * suppresses assignment, so you don't have to
> pass a pointer, and the format spec says to consume a string of
> unlimited length made up of non-newlines.  However, it does not consume
> the \n, so if you use it twice, the second call will return
> immediately.  It might work to do scanf("%*[^\n]%*1[\n]") (the second
> format specifier attempts to consume at most one newline), but I'd want
> to test that before depending on it - I suspect that's a piece of scanf
> that gets little testing and thus is likely to be buggy.

What I really want is a single command to stop and wait for just _any_
key-press -- not the RETURN key only. Searching the web indicates that
this does not exist, at least not in a simple and platform independent
way. So I can happily live with getchar() as you suggested.

>> > I am sorry to say that I am not much concerned about any problems
>> > this key press might cause elsewehere, as this is not a working
>> > application but some simple code to demonstrate a problem somewhere
>> > else, possibly in production code.
>
> Normally, I'd feel the same way.  But this looks like not a standalone
> test program but a small part of a larger test scaffold, and if running
> one test can corrupt things so as to cause a later test to fail
> spuriously, that sounds to me like a real problem.

I appreciate your concern, but it is in fact just a standalone test program.

Now that this is settled, I would love to read from someone with the
same enthusiasm for my original TRE regular expression problem! ;-)

Below is the test code again, now properly using getchar().

Ralf

----------------

#define p "(.)\\1$"

int _tmain(int argc, _TCHAR* argv[])
{
  regex_t RE;

  int nMatches, rc;

  regmatch_t *matches;

  TRE_MB_CUR_MAX = 2;

  rc = tre_regncomp(&RE, p, strlen(p), REG_EXTENDED);
  printf ("%d\n", rc);

  nMatches = RE.re_nsub + 1;
  matches =  malloc (nMatches * sizeof(matches[0]));

  rc = tre_regexec(&RE, "foox", nMatches, matches, 0);
  printf("Result: %d\n", rc);

  free(matches);

  tre_regfree(&RE);

  printf ("\nDone");
  getchar(); /* Keep app window open until key press. */

  return 0;
}


Home | Main Index | Thread Index | Old Index