dmd2\src\phobos\std\format.d(4573): Error: cannot implicitly convert expression (fbuf.length) of type ulong to uint
dmd2\src\phobos\std\format.d(4575): Error: cannot implicitly convert expression (& sl) of type uint* to ulong*
dmd2\src\phobos\std\format.d(4578): Error: cannot implicitly convert expression (fbuf.length * 2LU) of type ulong to uint
Comment #1 by yebblies — 2012-11-16T05:59:29Z
A minimal test case to go with those errors would be helpful.
Comment #2 by js.mdnq — 2012-11-27T03:25:25Z
(In reply to comment #1)
> A minimal test case to go with those errors would be helpful.
Use a rather bare bones d example and trying to compile for x64 in windows by adding the -m64 switch gave the same results. Seems like it is a conversion issue due the fact that length depends on the architecture.
Changing the line in format.d "uint sl;" to "size_t sl;" solves the errors but then gives
------ Build started: Project: CTest1, Configuration: Release Win64 ------
Building Release\CTest1.exe...
Internal error: ..\ztc\cgobj.c 1479
Building Release\CTest1.exe failed!
Using casts instead of size_t also gives the same error.
The code is
" else // 16 bit segment
{
#if MARS
assert(0); // line 1479
#else
if (size & ~0xFFFFL)
{ if (size == 0x10000) // if exactly 64Kb
sd[0] |= 2; // set "B" bit
else
synerr(EM_seg_gt_64k,size); // segment exceeds 64Kb
}
//printf("attr = %x\n", attr);
#endif
}"
Which seems to be how the compiler is dealing with object files and the 64-bit object segments are treated as 16-bit. (A guess as I'm new to D but jives with what was said about the 64-bit issues DMD had)
In any case the uint seems to be a bug as much of the code surrounding it uses size_t's.