[Bug 1899553] Re: gcvt and qgcvt do not always provide requested precsion

[Robert Gilmour]

Hi,

On Wed, Feb 3, 2021 at 3:46 AM Balint Reczey <1899553 at bugs.launchpad.net>
wrote:

> The first result is slightly less, the second one is slightly more
> accurate representation of 0.1 compared to the exected value thanks to
> the rounding.
>
> IMO it makes sense to omit the digits that are below the accuracy limit
> and the man page does not suggest the opposite.
>

I disagree with that.
The man page says:
"It produces ndigit significant digits in either printf(3) F format or E
format"

If the intention was to limit the value of "ndigit" to no more than 17,
then  I believe that documentation should have (and, indeed, would have)
specified that limit.

Every double (apart from infs and nans) encapsulates a precise base 2
value. I see nothing unreasonable in wanting to see that precise base 2
value expressed exactly in base 10.
That is what the "%.*g" formatting of sprintf provides - which is,
of course, the workaround I use.

gcvt's commitment to a string containing only "significant digits" implies
that no more than 768 digits will ever be output for any double.
That is, the precise value of  every finite double can be expressed exactly
in 768 (or fewer) decimal digits.


> If you deeply believe that glibc needs to be fixed in this aspect please
> report the issue upstream, because this is not a deliberate change in
> the Ubuntu packaging.
>
>
I do believe that gcvt and qcvt are not behaving in accordance with their
documented (nor expected) behaviours.
However, the man also says:
" Marked  as LEGACY in POSIX.1-2001.  POSIX.1-2008 removes the
specification of gcvt(), recommending the  use  of  sprintf(3)  instead
 (though  snprintf(3) may be preferable)."

Therein lie the only excuses I can see for *not* fixing it.

I think I would at least like "upstream" to be made aware of this issue.
And the best way to achieve this would be to file a bug report.
Can you provide me with a link to the correct location for doing this ?

Thanks for responding. I appreciate the time you've taken in doing this.

Cheers,
Rob

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1899553

Title:
  gcvt and qgcvt do not always provide requested precsion

Status in glibc package in Ubuntu:
  Won't Fix

Bug description:
  On Ubuntu 20.04.1 LTS, glibc-2.31:
  gcvt() will output no more than 17 digits of precision.
  qgcvt() will output no more than 21 digits of precision.

  Here is the demo :

  /************************************************/
  #include <stdio.h>
  #include <stdlib.h>

  int main(void) {
   char ebuf[80];

   gcvt(0.1, 55, ebuf);
   printf("%s\n", ebuf);

   qgcvt(0.1L, 67, ebuf);
   printf("%s\n", ebuf);

   return 0;
  }

  /************************************************/

  I got:
  0.10000000000000001
  0.100000000000000000001

  I expected:
  0.1000000000000000055511151231257827021181583404541015625
  0.1000000000000000000013552527156068805425093160010874271392822265625

  The "expected" values are exact base 10 representations of the values
  contained in the double 0.1, and in the (80-bit extended precision)
  long double 0.1.

  The same problem existed on Ubuntu-18.04. I expect it is a
  longstanding issue

  Cheers,
  Rob

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1899553/+subscriptions