This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[frey@udel.edu] Digested Articles



Hi glibc folks,

we've received the appended bug report.  Can somebody look into it,
please?

Thanks,
Andreas



Topics:
   libc/1639: sscanf, fscanf, scanf all fail using scanset...
   libc/1640: location of bug in sscanf, fscanf, scanf...


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

Date: Tue, 7 Mar 2000 22:05:52 -0500
From: frey@udel.edu
To: bugs@gnu.org
Subject: libc/1639: sscanf, fscanf, scanf all fail using scanset...
Message-Id: <200003080305.WAA29031@delysid.gnu.org>


>Number:         1639
>Category:       libc
>Synopsis:       sscanf, fscanf, scanf all fail using scanset...
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    libc-gnats
>State:          open
>Class:          sw-bug
>Submitter-Id:   unknown
>Arrival-Date:   Tue Mar 07 22:10:01 EST 2000
>Last-Modified:
>Originator:     frey@udel.edu
>Organization:
net
>Release:        latest
>Environment:
LinuxPPC Q3 distribution
>Description:
When using a scanset which catches the first character of the buffer/file/input line (for sscanf, fscanf, scanf, respectively), the i/o function exits prematurely, resulting in no further analysis of the format string, etc.  This is reproducible in EACH of the formatted input variants, sscanf, fscanf, and scanf.
>How-To-Repeat:
Use the following code:

#include <stdio.h>

main()
{
  char          buffer[200];
  int           temp;
  FILE*         file;

  file = fopen("temp.txt","w");
  fprintf(file,"[matx] 3,3 {}");
  fclose(file);

  printf("fscanf TESTING...\n");
  file = fopen("temp.txt","r");
  printf("Result: %d\n",fscanf(file,"%*[^[][%n",&temp));
  printf("Read:   %d\n",temp);

  printf("sscanf TESTING...\n");
  sprintf(buffer,"[matx] 3,3 [\n[ 1 0 0 ]\n");
  printf("Result: %d\n",sscanf(buffer,"%*[^[][%n",&temp));
  printf("Read:   %d\n",temp);

  printf("scanf TESTING...\n");
  printf("Result: %d\n",scanf("%*[^[][%n",&temp));
  printf("Read:   %d\n",temp);
}

The first two tests run without intervention; for the third, enter "[matx]" via the keyboard.  In all three cases, the input function indicates no assignments were made and makes no attempt to return a value for the number of characters read (%n)
>Fix:
>Audit-Trail:
>Unformatted:


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

Date: Tue, 7 Mar 2000 22:30:02 -0500
From: frey@udel.edu
To: bugs@gnu.org
Subject: libc/1640: location of bug in sscanf, fscanf, scanf...
Message-Id: <200003080330.WAA29123@delysid.gnu.org>


>Number:         1640
>Category:       libc
>Synopsis:       location of bug in sscanf, fscanf, scanf...
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    libc-gnats
>State:          open
>Class:          sw-bug
>Submitter-Id:   unknown
>Arrival-Date:   Tue Mar 07 22:40:01 EST 2000
>Last-Modified:
>Originator:     frey@udel.edu
>Organization:
net
>Release:        latest
>Environment:
LinuxPPC Q3 dist
>Description:
The exact reason why all three fail can be found in stdio-common/vfscanf.c:

         :
      if (width > 0)       <--- Line #1217
        --width;
        first = 0;
      		}
	      while (width != 0);

	      if (first)         <---- here is the bug!!
     conv_error ();

If the first character read is not in the scanset, the while loop terminates before "first" is set to 0.  First then contains the character which ended the loop, and is obviously not zero, yet still triggers the conv_error(); routine.  (See NEXT_WIDE_CHAR for what happens to "first" during the reading).  A quick fix would be:

	      if (first == EOF)         <---- here is a fix
     conv_error ();

This would yield the correct behavior EXCEPT:

      sscanf(buffer,"%[^[][%n",&tempInt);
         with buffer[] = "nothing to find!"

sscanf would scan the whole buffer and hit EOF and trigger the conv_error(); I just corrected; no value would be given to the %n conversion, which I believe would still be valid even when an EOF is reached, correct?

- Jeff

JT Frey, frey@udel.edu
University of Delaware
Graduate Student and Teaching Assistant, Dept. of Chemistry

>How-To-Repeat:

>Fix:
>Audit-Trail:
>Unformatted:


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

End of forward_ZAEWl Digest
***************************



-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]