> fscanf-rv: 6
> (gdb) print &j
> $1 = (long int *) 0xbfc34df0
> (gdb) watch *(int *)0xbfc34df0
> Hardware watchpoint 4: *(int *) 3217247728
> (gdb) step
> j nach fscanf: 0
> (gdb) step
> (gdb) step
> (gdb) step
> (gdb) step
> (gdb) step
> (gdb) step
> Hardware watchpoint 4: *(int *) 3217247728
>
> Old value = 0
> New value = 1
> 0x080510d5 in leseDatenIGS (input=0x9c20170, daten=0x9c202e8) at
> lese.cpp:206
That [above] is the expected increment of j in your code.
> /home/patrick/jamila/lese.cpp:206:5112:beg:0x80510d5
> (gdb) step
> (gdb) step
> (gdb) step
> (gdb) step
> (gdb) step
> j vor fscanf: 1
> (gdb) step
> Hardware watchpoint 4: *(int *) 3217247728
>
> Old value = 1
> New value = 0
> 0x0040c24f in _IO_vfscanf_internal () from /lib/libc.so.6
That is the unexpected change of j by _IO_vfscanf_internal.
Your code was:
rv = fscanf(input, "%s %d %lf %lf %lf %lf", &c, &SatNr,
&x, &y, &z, &korr);
The manual page for scanf(3) says:
l Indicates either that the conversion will be one of diouxX or n
and the next pointer is a pointer to a long int or unsigned long
int (rather than int), or that the conversion will be one of efg
and the next pointer is a pointer to double (rather than float).
Specifying two l characters is equivalent to L. If used with %c
or %s the corresponding parameter is considered as a pointer to
a wide character or wide character string respectively.
L Indicates that the conversion will be either efg and the next
pointer is a pointer to long double or the conversion will be
dioux and the next pointer is a pointer to long long.
So it looks like _IO_vfscanf_internal is interpreting your "%lf" as "%Lf",
which is a bug. File a bug report with bugzilla about glibc.
--
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list