>I merely suggested that it could be a possibility.
It's never a possibility until you've exhausted all other options.

>So using %lf with printf is undefined behaviour?
In C89 it's undefined. In C99 the length modifier is quietly ignored because the committee realized this confusion was a very real problem.

>If %lu is okay why should %lf be not.
Because l is meant for integers, not floating-point.

>It sounds so natural.
Just because you see symmetry doesn't mean there is symmetry. What does %lf mean? Double? No, that's what %f means because varargs arguments use pre-C89 promotion rules. Long double? No, that's what %Lf is for. Why a capital L for long double? Because the committee realized that some moron would use %lf thinking it meant double, pass a double, and cause undefined behavior when printf treated it as a long double.

>The authors who wrote books on C and said %lf is a valid printf format specifier should be shot dead
Yes, but not for misleading you. They should be shot dead for trying to teach a language that they still haven't learned properly.

>Dave Sinkula, Narue, Ancient Dragon, Rashakifol and everyone else
>possesing a much better knowledge on C should be shot dead since they
>did not point this one out to me before
It's not our job to delint your programs. If it bothers you so much that we don't take the time to point out every little problem then go shell out $500 for PCLint and do it yourself.

>I believe I have used %lf with printf many a times before in this forum.
This is a problem that can easily be missed unless you're looking for it. Despite your obvious expectations, we're not capable of finding every little bug at a glance. I spend a lot of time looking closely at my code, referring to the standard, and using powerful tools like lint to catch as many problems as I can. I don't usually expend the same amount of effort on every piece of code posted to these forums by other people.

> With all that said my gcc still acts weird even if I use %f instead of %lf with printf
I use MinGW's 3.4.2 version of gcc, and I can't reproduce your problem. My educated guess would be that you really are hitting a floating-point rounding issue and it has nothing to do with gcc. What OS and processor do you use? Also, can you post a dozen or so iterations of the execution with the printf uncommented?

Just for you, I downloaded and installed Mingw.

Guess what - nothing unusual happening here either, despite your broken code.

Anyway, I've cleaned it up a bit (stop it looping forever for example) and shown an example session - I suggest you do the same for a problem case as Narue suggests.


My next guess is you have some crusty old pentium with an uncorrected FDIV bug. Other than that, I can't reproduce the problem so unless you post more details, there's not a lot else to do.

Thanks everyone for being so patient with me, especially Salem who actually downloaded MinGW gcc. I really appreciate that!

Here's the screen capture of what I am getting. First I compile the program with the printf statement commented. In this case the loop never ends. I had to Ctrl + C to kill it.

In the next case I uncomment the printf statement and the program works as expected.

The issue is only with MinGW gcc version 3.4.2. I have tested the code with lcc-win32, visual C++ 6.0 and Borland C++ 5.5.


Unzip and open the gcc.html file with your browser. You will see it yourselves.

%lf is valid for scanf(), so it is natural for anyone to think it is also valid for printf(). Things like this is easy to miss unless someone explicitly mentions it.

Now I want to know how much does this C and C++ standard costs? Or can you direct me to a modern book on C(not C++), cos I am thinking of getting a book that really teaches these subtle points. K&R, I guess, has become quite outdated.

>%lf is valid for scanf()
Yes, because scanf expects a pointer, and pointers must be appropriately typed. printf doesn't require a pointer, and default promotions apply.

>Things like this is easy to miss unless someone explicitly mentions it.
I agree, but C is a subtle language. Why do you think it takes so many years to become proficient with it?

>Now I want to know how much does this C and C++ standard costs?
$18 for the PDF version at www.ansi.org, or about $60 for the Wiley hardcopy, or about $200 for the official ANSI hardcopy.

>Or can you direct me to a modern book on C
A good reference that makes few mistakes is C: A Reference Manual (5th Edition) by Harbison and Steele. It's a nice alternative to the standard if you can't take hundreds of pages of legalese. But there are a few minor points (that should only come up in a debate of pedantry) where C: A Reference Manual is not entirely accurate.

>K&R, I guess, has become quite outdated.
Not really. K&R is still my most referenced book on C. I'm on my 3rd copy because the other two fell apart from overuse, and the binding is excellent.

>You will see it yourselves.
My guess remains the same. First fix your floating-point comparison so that it uses a fudge factor. If the problem remains, post the code you used. Since we can't reproduce your problem, the only way we can help is to offer suggestions and make sure that your code is 100% correct for troubleshooting.

First you explain to me how come uncommenting a printf() statement makes the loop end. This simply doesn't make any sense.

Within a few iterations the new value of x1 differs so small from the prev value of x1 that it is well beyond the precision of 15 decimal places. x1 is then unchanged. So a match between x0 and x1 should be true(since I do a x0 = x1). The loop should exit. It works with all the compilers. Even you people could not reproduce the problem.

Oh yeah it is. K&R IS outdated. K&R was written around C89 standard. It doesn't teach you the features available in C99 . You can still use it as a reference because most of the compilers still haven't implemented all of C99. So that you can tell people,"Hey not all compilers have implemented C99 fully, so don't use this or that; your code has undefined behaviour according to C89, your code is broken according to C89 etc. etc." In my view that book is outdated.

>First you explain to me how come uncommenting a printf() statement makes the loop end.
No, fix your damn code first. Then we'll talk about weird things happening. If you want help, stop being a prick about the help you're getting. If you want to be a smartass, we'll be happy to offer you a cold shoulder.

>You can still use it as a reference because most of the compilers still haven't implemented all of C99.
When you're intimately familiar with both C89 and C99, then you're welcome to debate the validity of K&R's content. Until then, take my word for it.

>In my view that book is outdated.
In my view you lack the foundation to make that judgement.

If you run the loop for say 50 times that's enough most of the time to get the desired result. So instead of using x1 != x0, I would use the following code

But the number of iteration that is required depends very much on the value of a, for some it would require 5 iterations and for some it would take 19. So why should I run the code 50 times for each value of a. That's not very elegant IMHO.

The second method that came into my mind was to use fabs(a - x1 * x1) > 0.00000000000001 to make the loop continue until it reaches 15 decimal precision. Then again for the most of the values of a it goes into a infinite loop. I guess that's quite expected and I should use something like this: fabs(fabs(a - x1 * x1) - 0.00000000000001) )> (FUDGE_FACTOR). I am just not quite sure what to use for the fudge factor so that I do get the precision upto 15 decimal places.
Originally I was solving the follwing problem


as

I thought x0 != x1 would be the best way to simulate .

Can't you find a better way of conveying your results other than some bloated shockwave flash file, which by the way I've no intention of running while I'm at work.

Does the enhanced exit condition in my example code loop forever on your machine as well?

This is what happens when I use your code. The effect is same as mine. This time it's in GIF format. Hope that's okay with you.