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

[Jonathan Berry]

On 2/6/06, Patrick von der Hagen <patrick at wudika.de> wrote:
> John Reiser wrote:
> >> Using gcc-3.5 on Debian-Sarge runs as expected, but on T2 and Rawhide j
> >> is set to 0 after fscanf!!!
> >
> > Run under gdb, put a breakpoint on fscanf, upon arrival put a watchpoint on j:
> >       (gdb) print &j
> >       (gdb) watch *(int *)0x....
> >       (gdb) continue
> >
> >> double x, y, z, korr, SekundeSat;
> >> long j, JahrSat;
> >
> > It's conceivable that this is some fallout from the [impending ?] change
> > to long double.  Note that 'j' is declared just after some 'double' locals,
> > and "%lf" appears in the fscanf.

I think that is the issue here, too.

> Changing those lines like this
> "double x, y, z, korr, SekundeSat;
> char d;
> long j, JahrSat;"
> works on my system. "d" is just some unused placeholder to put something
> between double and long.
[snip]
> Now, whom should I contact? glibc, gnu-c or gnu-c++?

None.  The issue is in the code.  Change all %lf in the scanf to %f. 
Or better yet, use std::cin and the extraction operator since you are
using std::cout.  Or perhaps those are just your additions for
debugging...  Either way, scanf is not a very good (read: safe) method
for getting input.

One of the changes in the new gcc ABI is to treat long doubles as 128
bits wide (as I understand from my little bit of reading about it). 
This is why it works on other systems but breaks on FC5T2 system; the
others have the old compiler.  %lf refers to a long double and will
stomp on the 128 bits of memory after the address being used in the
scanf.  Adding the extra variable moves things around to where the
double and long are not adjacent (apparently gcc pads the char to 32
bits...).  I've seen similar things on a 64-bit system using %ld with
a long, which was 64 bits wide rather than 32.  Lots of fun.

Jonathan