gcvt and qgcvt do not always provide requested precsion

[Robert Gilmour]

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

[Balint Reczey (rbalint)]

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.

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.

Out of curiosity I've checked the results on Fedora and they are the same:

 [root@fedora ~]# cat > test.c
#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;
}
[root@fedora ~]# gcc test.c
[root@fedora ~]# ./a.out
0.10000000000000001
0.100000000000000000001

[Robert Gilmour (syphilis)]

Hi,

On Wed, Feb 3, 2021 at 3:46 AM Balint Reczey <email address hidden>
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