Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Ticket #842 (closed defect: fixed)

Opened 10 months ago

Last modified 6 months ago

Negative numbers leads to hex formatting errors

Reported by: larsivi Assigned to: kris
Priority: major Milestone: 0.99.6
Component: IO Version: 0.99.4 Frank
Keywords: Cc: ilm

Description

import tango.io.Stdout;
import tango.text.convert.Integer;
import tango.stdc.stdint;

void
main()
{
        void *address = &main;
        int i = -1;

        auto t = format(new char[32], cast(uint32_t) address, Style.HexUpper, Flags.Zero);

        Stdout.formatln("A: 0x{0:X} 0x{1:X} {2}", address, cast(void*) 0xabc, t);
        Stdout.formatln("B: 0x{0:X8}", i);
}

Gives the output

A: 0x8049114 0xABC 00000000000000000000000008049114
B: 0x{output width too small}

Reported by hexpuem/ilm.

The reason is

if (uint.max >= cast(ulong) i) ...

in Integer as -1 becomes 16 1s as ulong. Thanks to Hxal for looking up the offending source.

Change History

01/02/08 05:07:38 changed by larsivi

  • owner changed from sean to kris.
  • component changed from Core Functionality to IO.

02/10/08 20:54:01 changed by kris

  • status changed from new to assigned.
  • milestone changed from 0.99.5 to 0.99.6.

Yeah, thought that's not the offending source. The API accepts a 64-bit long value, so you'll find that integers are promoted at the call-site. Hence, -1 is promoted to a 64-bit -1 value. From then on the original type is lost.

Not sure what to do about this - all suggestions are welcome

03/11/08 10:02:31 changed by svanleent

Perhaps create a Safe version of the hexadecimal formatting, which checks whether the given output length is indeed less than the given number, if not, accepts the number as valid.

Sjoerd

04/18/08 01:19:52 changed by kris

  • status changed from assigned to closed.
  • resolution set to fixed.

this should be fixed via [3444]