|View Issue Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000502||mercury||Feature Request||public||2020-04-28 23:25||2020-06-09 11:37|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0000502: print unsigned numbers|
|Description||string.format and io.format should be able to print unsigned integers without|
the user having to explicitly convert them to a signed integer first.
At the monent, signed ints can be printed with the d and i conversion chars,
which print them as the signed ints they are, and with the o, u, x, X, and p
conversion chars, which print them as if they were unsigned. I think the last
five should be the conversion chars for which one should be able to pass
*either* a i(int) poly_type, *or* a u(uint) polytype.
|Additional Information||When targeting C, the Mercury standard library can use either sprintf,|
or its own implementation. We have long defaulted to using sprintf, but
we do already bypass it when dealing with data it would mishandle,
such as non-ASCII UTF chars. The argument in favor of using sprintf
has always been that it is faster than the library's format string interpreter,
but this argument has lost most of its force when we started interpreting
format strings at compile time. Perhaps it is time to stop using sprintf.
|Tags||No tags attached.|
It was always intended that the format predicates be extended to support all of the new integer types (not just uint). The first thing that needs to be decided is which conversion specifiers apply to which types (in particular should format support printing out unsigned integers as signed values).
There are two main uses of sprintf in the standard library:
1. in the primitive to_string conversion of things like integers and floats; here it's most probably a loss for us since the conversion specifier is fixed and we end up wasting time processing it.
2. in the implementation of the format predicates
I'm in favour of replacing use case (2) for the C backends now.
I don't know any use case that would justify being able to print uint values
as signed with %d or %i. The use case for reverse (being able to print int
values as unsigned with %u, %o, %x, %X or %p) was two-fold and obvious:
the absence of uint at the time, and the fact that we implemented printing
by calling C's print, which allowed it. In fact, it allowed this precisely because
due to its variadic nature, printf couldn't be told that any integers passed to it
were unsigned. So in both cases, the possible loss of meaning as a negative
number was treated as unsigned was unavoidable. That is not the case here.
|I'm not arguing that we need to support signed conversion specifiers with unsigned values -- I can't see any obvious use case for it either -- just that we need to define what is / will be supported.|
|Implemented by commit 9528f32.|
|2020-04-28 23:25||zs||New Issue|
|2020-04-29 17:42||juliensf||Note Added: 0001090|
|2020-05-01 17:33||zs||Note Added: 0001091|
|2020-05-01 18:21||juliensf||Note Added: 0001092|
|2020-05-22 14:27||juliensf||Assigned To||=> juliensf|
|2020-05-22 14:27||juliensf||Status||new => assigned|
|2020-06-09 11:37||juliensf||Status||assigned => resolved|
|2020-06-09 11:37||juliensf||Resolution||open => fixed|
|2020-06-09 11:37||juliensf||Note Added: 0001093|