strange problem with self-compiled software on FC 5 T2...

[John Reiser]

> 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.

--