Mail Archives: djgpp-workers/2000/09/29/07:46:22
Consider the program below. It is a variant of one of the examples in
the Draft C9X Standard (example 3 on page 271).
The issue I want to raise is when this program is presented with the
last line from that example (see page 272):
100ergs of energy
Since the format is "%f%20s of %20s", I think this should store 100 in
the float variable that corresponds to the %f conversion specifiers,
and leave the following `e' for the char [] variable which is
converted by %20s.
Our current implementation of _doscan indeed stores 100 in the FP
variable, but swallows `e', and stores only "rgs" in the char []
variable. I think this is wrong, since "100e" is not a valid FP
number.
However, the Draft says that the conversion should fail entirely,
because "100e" fails to match "%f". This seems wrong to me, although
I did write a version of _doscan which behaves like that.
To make this even more interesting, I ran the test program on DJ's
Irix box and his Red Hat machine. On Irix, the FP variable gets
assigned 100, and the char [] variable gets "ergs" copied into it.
However, Red Hat works exactly like DJGPP's libc does.
So, the question is: should we fix _doscan, and if so, how? I'd like
to hear opinions.
Here's the test program I used. Perhaps people could run it on more
systems, including on different Linux releases, and see what they get.
#include <stdio.h>
int main (void)
{
int count;
float quant;
char units[21], item[21];
do {
int c;
count = fscanf (stdin, "%f%20s of %20s", &quant, units, item);
printf ("count: %d quant: %f units: %s item: %s\n",
count, quant, units, item);
printf ("buffered chars: '");
while ((c = getc (stdin)) != '\n' && c != EOF)
putc (c, stdout);
printf ("'\n");
} while (!feof (stdin) && !ferror (stdin));
return 0;
}
- Raw text -