I can't give a number which is < 10 a precision. Is there a good reason for this or is this a bug?

eg.

writefln("number = %.8x", cast(ulong)10);

will display

0000000a

but

writefln("number = %.8x", cast(ulong)9);

will display

9

Why is the precision ignored in this case?

printf does not work this way. It will correctly display 00000009

On Fri, 17 Mar 2006 23:59:45 +0000 (UTC), pmoore <pmoore_member@pathlink.com> wrote:
> I can't give a number which is < 10 a precision. Is there a good reason for this
> or is this a bug?
>
> eg.
>
> writefln("number = %.8x", cast(ulong)10);
>
> will display
>
> 0000000a
>
> but
>
> writefln("number = %.8x", cast(ulong)9);
>
> will display
>
> 9
>
> Why is the precision ignored in this case?
>
> printf does not work this way. It will correctly display 00000009

Odd. Either it's treating it like a string instead of a number (from the printf docs):

For numbers - "The precision specifies the minimum number of digits to be printed. If the number of digits in the argument is less than precision, the output value is padded on the left with zeros. The value is not truncated when the number of digits exceeds precision."

For strings - "The precision specifies the maximum number of characters to be printed. Characters in excess of precision are not printed."

Or perhaps, and this is a complete guess, it's related to the way toString handles numbers smaller than 10, eg:

if (u < 10)
  // Avoid storage allocation for simple stuff
  result = digits[u .. u + 1];

it takes a slice of a const array:
  const char[10] digits    = "0123456789";			/// 0..9


FYI, you can use:
  writefln("number = %.8x", cast(ulong)9);

to get the result you want. This is how I typically pad my hex numbers.

Regan

In article <ops6k3babk23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>FYI, you can use:
>   writefln("number = %.8x", cast(ulong)9);
>
>to get the result you want. This is how I typically pad my hex numbers.

That's exactly what he does already :-)

This is a bug in format.d. Starting at line 839, it reads:
839   if (vnumber < 10)
840   {

This should really compare against base, not 10.

841     if (vnumber == 0 && precision == 0 && flags & FLprecision &&
842        !(fc == 'o' && flags & FLhash))
843     {
844       putstr(null);
845       return;
846     }

Ok.

847     if (vnumber < base)
848     {   vchar = '0' + vnumber;
849         goto L2;
850     }

The compare against base is redundant (if the above test is fixed), and wrong. It should instead check if precision is 0.

851   }

Nick

On Sat, 18 Mar 2006 09:05:17 +0000 (UTC), Nick <Nick_member@pathlink.com> wrote:
> In article <ops6k3babk23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>
>> FYI, you can use:
>>   writefln("number = %.8x", cast(ulong)9);
>>
>> to get the result you want. This is how I typically pad my hex numbers.
>
> That's exactly what he does already :-)

Damn copy+paste making me look silly again. I meant to paste in:

writefln("number = %08x", cast(ulong)9);

Regan

Thanks,

I get up this morning and not only is my question answered but someone has put in the bug report for me :)


In article <ops6lshu0623k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Sat, 18 Mar 2006 09:05:17 +0000 (UTC), Nick <Nick_member@pathlink.com> wrote:
>> In article <ops6k3babk23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>>>
>>> FYI, you can use:
>>>   writefln("number = %.8x", cast(ulong)9);
>>>
>>> to get the result you want. This is how I typically pad my hex numbers.
>>
>> That's exactly what he does already :-)
>
>Damn copy+paste making me look silly again. I meant to paste in:
>
>writefln("number = %08x", cast(ulong)9);
>
>Regan