On 2/6/06, Patrick von der Hagen <patrick@xxxxxxxxx> 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 -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list