Xref: news2.mv.net comp.os.msdos.djgpp:2373
From: Broeker AT axp03 DOT physik DOT rwth-aachen DOT de (Hans-Bernhard Broeker)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: bug sscanf when match fails ?
Date: 1 Apr 96 10:29:17 GMT
Organization: RWTH -Aachen / Rechnerbetrieb Informatik
Lines: 72
Message-ID: <Broeker.828354557@axp03>
References: <9603292252 DOT AA02443 AT phi2 DOT Eng DOT Sun DOT COM>
NNTP-Posting-Host: axp03.physik.rwth-aachen.de
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

pierre AT dahlgren-19 DOT Eng DOT Sun DOT COM (Pierre Willard / Thomson Sun Interactive) writes:


>It seems that sscanf does not stop parsing when a match fails (as it
>should). The following shows the bug. This has been tested on v1, but
>someone told me it was the same with v2.
[rest del'ed]

This could be the very same bug I found in fsanf().  Could you (and
everyone else with scanf-family problems, as well), please check if the
solution I provided for bug number 68 in DJ Delorie's DJGPP Bug Tracking
System? The fault I detected there was that doscanf() tried to go on
reading input, although input had already been used up.  That was
because a statement that stops its execution normally has been commented
out, so maybe this same statement is causing you trouble as well (doscan
should have exited immediately, after all, when it had found that the
scanning format %d wasn't compatible with the data it had, shouldn't
it?). 

In addition to this possible 'known fix', I'll take the example source
code and try if I can hunt down that one as well, now I'm kind of used
to the internals of DJGPP's scanf() library functions :-)

For the impatient, here's the patch I put into the Bug Tracker:
(in the Tracker, it seems to have been garbled: \n's replaced
by line-ends)

----------- begin doscan.dif ---------------
*** doscan.c_o  Mon Mar 25 12:36:52 1996
--- doscan.c    Mon Mar 25 12:37:44 1996
***************
*** 104,112 ****
               &amp;fileended) &amp;&amp; ptr)
        nmatch++;
  /* breaks %n */
! /*    if (fileended) {
        return(nmatch? nmatch: -1);
!     } */
      break;    
    case ' ':
    case '\n':
--- 104,112 ----
               &amp;fileended) &amp;&amp; ptr)
        nmatch++;
  /* breaks %n */
!     else if (fileended) { /* HBB: if conversion failed, stop action immediately*/
        return(nmatch? nmatch: -1);
!     }
      break;
    case ' ':
    case '\n':
--------------- end doscan.dif -------------

To find out if this one is the reason for the misbehaviour you observed, 
do this:

* get doscan.c from DJ's library sources (djlsr200.zip)
* apply the patch I gave above
* compile it (plain 'gcc -c -O2' should do)
* add it to the end of your linking line, i.e. if the only source is
  a file, called testit.c, compile it like this:
        
       gcc -o testit.c {...options...} doscan.o {...libraries...}

If this cures your problems, you might want to replace the doscan.o
in libc.a with the one you just built (or, perhaps, rebuild the
whole library instead, but that's quite an amount of work). And, please,
report to me and/or the newsgroup about your findings. 

Hoping this helps at least some of you

Hans-Bernhard Broeker (Aachen, Germany)