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

[Patrick von der Hagen]

Hi all,

I have a very strange problem. A little program (mixture of C and C++)
done by a friend of mine works fine on MS-Windows and on Debian Linux.
Compiling on FC 5 T2 and todays rawhide works fine, but running it gives
very strange results....

This is the crucial loop....

char c;
int SatNr, MonatSat, TagSat, StundeSat, MinuteSat;
double x, y, z, korr, SekundeSat;
long j, JahrSat;

for (j = 0; j < daten->anzSat; j++)
{
	if (j == 11)
	{
		daten->beobachtungen[j].satNr = 12;
                daten->beobachtungen[j].xKoor = 0.0;
                daten->beobachtungen[j].yKoor = 0.0;
                daten->beobachtungen[j].zKoor = 0.0;
                daten->beobachtungen[j].Uhr = 0.0;
	}
	else
	{
		int rv = 0;
		std::cout << "j before fscanf: " << j << std::endl;
                rv = fscanf(input, "%s %d %lf %lf %lf %lf", &c, &SatNr,
&x, &y, &z, &korr);
                std::cout << "fscanf-rv: " << rv << std::endl;
                std::cout << "j nach fscanf: " << j << std::endl;
                daten->beobachtungen[j].satNr = SatNr;
                daten->beobachtungen[j].xKoor = x * 1000.;
                daten->beobachtungen[j].yKoor = y * 1000.;
                daten->beobachtungen[j].zKoor = z * 1000.;
                daten->beobachtungen[j].Uhr = korr * 10e6;
        }
}

Using gcc-3.5 on Debian-Sarge runs as expected, but on T2 and Rawhide j
is set to 0 after fscanf!!!

Now my question: who is to blame and how to debug? Does this sound like
a compiler-issue? Or could it be related to some library?
On the one hand, I'd bet lots of money that this is some compiler-bug,
on the other hand I don't dare to trust myself on this, that my friend
has stumbled upon an compiler-bug, when FC 5 T2 has been compiled using
that compiler without obvious problems....

Any suggestions?
BTW, this isn't my sourcecode... I'd care to initialize all variables,
and would care more about the fscanf-return-value, but that shouldn't be
related to the problem here....
-- 
CU,
   Patrick.