Re: [Mingw-users] msvcrt printf bug
- Date: Mon, 16 Jan 2017 23:22:21 +0800
- From: KHMan <keinhong@xxxxxxxxx>
- Subject: Re: [Mingw-users] msvcrt printf bug
On 1/16/2017 4:36 PM, tei.andu@xxxxxxxxxxxx wrote:
> Thank you for replying. My attached C file was scrubbed. I am
> sorry, I am new to mailing lists.
> It was just asigning 0x5D5F27A4 to a float - uint32_t union and
> printing the float with printf.
I think everyone on the list wants to help, including me.
There are now 4 persons who have responded to you, all are in
general agreement with how floats and doubles work. Isn't it time
you think for a bit that you may be on the wrong track? Now, if
you happen to be in high school or something, it is important that
you are missing a lot of stuff that you will be learning hopefully
in the future.
Let's just say that if you have done CompSci properly, it would be
quite impossible to make the kind of argument that you are doing now.
Sometimes when we think we are onto something, the thrill and
excitement can make us focus and keep focusing on a wrong
hypothesis. Nobody here seems to be in agreement with your
arguments. You should reevaluate.
> KHMan: I think you are wrong here. Every valid floating point
> representation that is not NaN or inf
> corresponds to an exact, non recurring fraction representation in
> decimal. There is no reason why
> printf shouldn't print that exact representation when needed, as
> the glibc printf does.
> For instance:
> 0x5D5F27A3: 14624675 * 2^(59 - 23) = 1005000013434060800 this
> prints correctly with msvcrt printf
> 0x5D5F27A4: 14624676 * 2^(59 - 23) = 1005000082153537536 this
> prints wrong with msvcrt printf for me: 1005000082153537500.
> Larger values also print slightly off.
> We are talking about whole numbers here, fractional part is zero.
> An acceptable loss in precision occurs when converting from a
> decimal representation to a float number due to limited precision
> in float:
> 0.1 is closest represented by 0x3DCCCCCD, which is exactly:
> 13421773 * 2^(-4 - 23) = 0.100000001490116119384765625
> 3e20 is closest represented by 0x61821AB1, which is exactly:
> 8526513 * 2^(68 - 23) = 300000006012263202816. We get 7 valid
> digits, this is normal and acceptable.
> Also the fact that the float number is converted to double doesn't
> matter, double can hold every possible float without loss in
> I also tried the printf in the old crtdll.dll, same behavior.
Sometimes smart people laser focus on the wrong things.
I will leave this discussion to other folks on the list.
Kein-Hong Man (esq.)
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
MinGW-users mailing list
This list observes the Etiquette found at
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
You may change your MinGW Account Options or unsubscribe at: