gcvt and qgcvt do not always provide requested precsion

Bug #1899553 reported by Robert Gilmour
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
glibc (Ubuntu)
Won't Fix
Undecided
Unassigned

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

Revision history for this message
Balint Reczey (rbalint) 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.

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

Changed in glibc (Ubuntu):
status: New → Won't Fix
Revision history for this message
Robert Gilmour (syphilis) wrote : Re: [Bug 1899553] Re: gcvt and qgcvt do not always provide requested precsion

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.