Re: Why does %#x omit the 0x prefix for a zero value?
I have always assumed it was intentional, as just 0 simply looks nicer, and is more obvious than 0x0 - and if you want to always have a leading "0x" you can always just write "0x%x" or "0x%.2x" (it gets slightly more complex if you want to also specify a field width, but is manageable). I have always assumed that the very point of %#x is so the 0x can be omitted when the value is 0. But I know nothing about the intentions of its inventors - but it is really hard to see how it could just be a programming bug, leaving the 0x there all the time is much easier to do than suppressing it when the value is 0. This is similar to how %#o with a value of 0 produces just 0, not 00. kre
RE: Why does %#x omit the 0x prefix for a zero value?
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 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, "#.8x" forces a 10 char output for non-zero values, the "0x" followed by the 8 digits for the explicit precision; for zero values and the other format it stays at 8, as the "0x" considered part of the width, I would think. This could be more explicit, but I think matches existing practice for how many spaces get inserted to do a right justify in a field width. On Monday, July 6, 2020 Schwarz, Konrad mailto:konrad.schw...@siemens.com>> wrote: 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 specification over a zero flag followed with a field width, i.e., “%#.8x” vs. “%#08x”?
RE: Why does %#x omit the 0x prefix for a zero value?
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, "#.8x" forces a 10 char output for non-zero values, the "0x" followed by the 8 digits for the explicit precision; for zero values and the other format it stays at 8, as the "0x" considered part of the width, I would think. This could be more explicit, but I think matches existing practice for how many spaces get inserted to do a right justify in a field width. On Monday, July 6, 2020 Schwarz, Konrad wrote: 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 specification over a zero flag followed with a field width, i.e., “%#.8x” vs. “%#08x”?
