2024-04-20 08:08 AEST
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000502mercuryFeature Requestpublic2020-04-28 23:252020-06-09 11:37
Reporterzs 
Assigned Tojuliensf 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
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.
Attached Files

-Relationships
+Relationships

-Notes

~0001090

juliensf (administrator)

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 (developer)

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 (administrator)

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 (administrator)

2020-06-09 11:37

 Implemented by commit 9528f32.
+Notes

-Issue History
Date Modified Username Field Change
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
+Issue History