Mercury Bugs - mercury
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000502mercuryFeature Requestpublic2020-04-28 23:252020-06-09 11:37
Reporterzs 
Assigned Tojuliensf 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000502: print unsigned numbers
Descriptionstring.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 InformationWhen 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.

TagsNo tags attached.
Relationships
Attached Files

Notes
(0001090)
juliensf   
2020-04-29 17:42   
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.
(0001091)
zs   
2020-05-01 17:33   
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.
(0001092)
juliensf   
2020-05-01 18:21   
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.
(0001093)
juliensf   
2020-06-09 11:37   
Implemented by commit 9528f32.

Issue History
Date ModifiedUsernameFieldChange
2020-04-28 23:25zsNew Issue
2020-04-29 17:42juliensfNote Added: 0001090
2020-05-01 17:33zsNote Added: 0001091
2020-05-01 18:21juliensfNote Added: 0001092
2020-05-22 14:27juliensfAssigned To => juliensf
2020-05-22 14:27juliensfStatusnew => assigned
2020-06-09 11:37juliensfStatusassigned => resolved
2020-06-09 11:37juliensfResolutionopen => fixed
2020-06-09 11:37juliensfNote Added: 0001093