J William Piggott wrote, on 05 Jul 2020:
>
> > I disagree. The standard defines what each of the conversion
> > specifiers is converted to. So the Denmark example demonstrates a
> > typical result of a %a conversion, a %d conversion, ..., and a %Z
> > conversion for a da_DK locale.
>
> "what
The following issue has been set as RELATED TO issue 0001364.
==
https://austingroupbugs.net/view.php?id=1016
==
Reported By:izabera
The following issue has been SUBMITTED.
==
https://austingroupbugs.net/view.php?id=1363
==
Reported By:geoffclare
Assigned To:
The following issue has been SUBMITTED.
==
https://austingroupbugs.net/view.php?id=1364
==
Reported By:geoffclare
Assigned To:
Yes, but the same logic (0 being unambiguous in all radices) equally applies to
1.
From: shwaresyst
Sent: Monday, July 6, 2020 18:35
To: Schwarz, Konrad (CT RDA IOT SES-DE) ;
austin-group-l@opengroup.org
Subject: RE: Why does %#x omit the 0x prefix for a zero value?
The necessity for "0x" is
Sorry, this isn't really a POSIX or a standards question, but does anyone know
why this was defined this way? Was it just codification of "historical
practice" (i.e., a non-fatal bug)?
While we're at it: when print formatting integers, are there any disadvantages
of using a precision
The necessity for "0x" is to disambiguate from octal numbers with their leading
'0', or decimal for a context allowing leading zeroes, but since a 0 is the
same in all radices I suspect the decision was not to require it to keep field
width minimal for delimited formats like CSV.
As to 2nd,
The following issue has been set as RELATED TO issue 0001016.
==
https://austingroupbugs.net/view.php?id=1364
==
Reported By:geoffclare
