Thread: Why does it run differently?

Originally Posted by Leftos

And although I see quite clearly why fgets is a much more safe apporach and good practice, we haven't been taught it yet, so I'm not going to risk a point off my project just for being more correct.

Neither did I mean that you should, but rather suggesting that the teacher(s)/helper(s) should be able to "hide" the fact that you haven't got to fgets() in the book, and explain that "gets() is no good, use this for of fgets() instead" - without actually explaining all the ins and outs of how it works and why it's so much better. Get to WHY it's better when you get to that part of the book [and explaining how and why this is important, somewhere in the education too!].

--
Mats

It would seem to me that you're on the wrong course then. Since you already know some stuff, and have the sense to go digging for information yourself, you're already a step above the noobs who have to be spoon-fed all the way.

> Herbert Schildt's Teach Yourself C
Well if this is the reference text, then everybody is on the wrong course.
Schildt is famous for many many low-quality publications.

Originally Posted by Leftos

Same goes with Elysia's complaint. Of course I have wondered why every C compiler I've used complains about "gets" being very dangerous, and of course I'd love to use fgets, however we've only been taught scanf and gets, Chapter 2 and Chapter 5, while fgets is on Chapter 9, thus, no can't do mister.

Now THAT is madness. Gets is very dangerous because it can very easily create buffer overruns. Gets should never, ever be used. It should not even be teached!
It never fails to amaze me how teacher and books learn people to use gets or other unsafe functions.
As matsp mentioned there, fgets(buffer, size, stdin) is the same as doing gets(buffer) and it much, much safer. Gets is just a dumb version of fgets, basically.
Complain at those who teach you if you want, but please, use fgets or at the very least learn how to use it. In a real application you should NEVER use gets.
And btw, even for school projects, it can be dangerous as soon as you run the application. It can even crash. Doesn't look good, does it?

Complain at your teacher, though. Always a good thing. Tell them not to teach dangerous stuff.

Here's something I don't understand. Well, another thing. Given the input is 7.6...

Code:

float a;
scanf("%f", &a);
printf("%f", a * 10);

...gives 75.999999, while...

Code:

float a;
scanf("%f", &a);
a = a * 10;
printf("%f", a);

...gives 76.000000. Why is that?

A better all-around check:

Code:

	float a, b;
	int inta;
	scanf("%f", &a);
	b = a * 10;
	inta = (int)(a * 10);
	printf("%f %f %f %d", a, a * 10, b, inta);

Output: 7.600000 75.999999 76.000000 75

Originally Posted by Leftos

Here's something I don't understand. Well, another thing. Given the input is 7.6...

Code:

float a;
scanf("%f", &a);
printf("%f", a * 10);

...gives 75.999999, while...

Code:

  
float a;
scanf("%f", &a);
a = a * 10;
printf("%f", a);

...gives 76.000000. Why is that?

because the calculation is done a little bit differently - or the conversion from float to double is done differently [all floating point parameters to printf are double] , perhaps. You probably will find other cases where there are differences.

Actually, I reproduced the results you got on my machine, and there is a difference between the two code-sets is:

Code:

	fmulp	%st, %st(1)
	fstps	-4(%ebp)
	flds	-4(%ebp)
	fstpl	4(%esp)

This stores the value back in a, and then loads it and stores it as a double on the stack for printf. In the "just multiply a by ten", the red code is not present, meaning the more precise double value is stored onto the stack. Note that the precision of (x87) floating point calculations is decided at the store stage, not during the actual calculation.

I do apologize if you don't fancy reading assembler code and understanding what it means - but there's no way to explain the behaviour in any other way.

--
Mats

Originally Posted by Leftos

Don't worry. I'm glad you're still answering to my issues and explaining so well.

So the correct way to do floating point calculations would be outside functions such as printf. Here is the loop that made the program work on my computer too.

Code:

		do
		{
			printf("Dwse vathmo %dou ma8hth: ", i + 1);
			scanf("%f", &vathmoi[i]);
			vathmoi10 = vathmoi[i] * 10;
		}
		while ((int)(vathmoi10) != vathmoi10 | vathmoi[i] < 0 | vathmoi[i] > 10);

Thanks for all the help and info anyway, it's been very helpful. A little testing always helps and in this case taught me something.

I'm still wondering, though, about why the other exercise with the inverted string doesn't work on my computer but works on the server.

The red code above is broken in two senses:
1. It's comparing an integer with a float, which is likely to fail under some circumstances [you just don't KNOW what those circumstances may be] due to floating point not being precise.

Code:

fabs((int)(vathmoi10) - vathmoi10) > 0.01

would be a better solution.
2. You are using bitwise or rather than logical or, which isn't quite the same thing - it sort of works OK for this case, but it's the wrong thing to do here. Use || instead of | and all will be fine.


As someone else suggested:

Code:

        char linet[strlen(line)];
        char linet2[strlen(line)];

should probably be

Code:

        char linet[strlen(line)+1];
        char linet2[strlen(line)+1];

Although both are a bit dubious as they are extensions to gcc, so won't work on other compilers. Perhaps this is the best solution:

Code:

        char linet[200];
        char linet2[200];

You also should set the end-marker of linet2 to zero - currently you just leave it to whatever it happens to be. Since different machines have different "stuff" sitting around in stack-based locations, what actually ends up at the end of the string is completely random, and on one machine it may be zero, on another some other value, so you get "random failyures" - it may even be different for different length strings.

--
Mats