I was testing out the samples that come with the D compiler. The output of pi.d was something I didn't expect to see:

C:\dl\dmd\dmd\samples\d>pi 3
pi = 51203.124492912449321244928
0 seconds to compute 3 digits of pi

As you can see, this is all wrong. The cause of the bug was simple, there was:

printf("pi = %d.",p[0]);
for (i = 1; i <= q; i++)
printf("%d",p[i]);

while this should have been:

printf("pi = %d.",cast(int)(p[0]));
for (i = 1; i <= q; i++)
printf("%d",cast(int)(p[i]));

This is because the p is byte[], not int[]. printf expects 4-byte long dwords, and as parameters to the printf are passed as bytes, the other 3 bytes are mangled.

I believe that c-compilers do work with the former code, but it is just luck I don't know (compiler might be "optimizing" or aligning the stack and passing bytes in dwords).

Whatever the case, I think that at least the example code should be working. It doesn't look good if even the samples do not work :)

Sampsa Lehtonen

Sampsa Lehtonen wrote:

> I was testing out the samples that come with the D compiler. The output of pi.d
> was something I didn't expect to see:
> 
> C:\dl\dmd\dmd\samples\d>pi 3
> pi = 51203.124492912449321244928
> 0 seconds to compute 3 digits of pi
> 
> As you can see, this is all wrong. The cause of the bug was simple, there was:
> 
> printf("pi = %d.",p[0]);
> for (i = 1; i <= q; i++)
> printf("%d",p[i]);
> 
> while this should have been:
> 
> printf("pi = %d.",cast(int)(p[0]));
> for (i = 1; i <= q; i++)
> printf("%d",cast(int)(p[i]));
> 
> This is because the p is byte[], not int[]. printf expects 4-byte long dwords,
> and as parameters to the printf are passed as bytes, the other 3 bytes are
> mangled.

Hmm.  Wouldn't it be considered a bug if the implicit conversion did not clear the rest of the int?  I.e. any variable should always be initialized to 0 or null (including implicit casts) with the new value copied in?

It would be one of those things that I would expect from a modern language.  That is what I am used to with most languages I use.

> 
> I believe that c-compilers do work with the former code, but it is just luck I
> don't know (compiler might be "optimizing" or aligning the stack and passing
> bytes in dwords).
> 
> Whatever the case, I think that at least the example code should be working. It
> doesn't look good if even the samples do not work :)

I agree.  I thought that maybe the algorithm was bad--making the math of D look completely inacurate.  Now I know its a display bug.

Another "bug" in pi.d:

Doesn't this seem odd to anyone?

$ ./pi 4000
Precision exceeds maximum of 4000

In order to fix this, the arrays need to be initialized with MAXINT + 1:

byte p[MAXPRC + 1];
byte t[MAXPRC + 1];

and the comparison should be changed from >= to >:

	if (q > MAXPRC)
	{
		printf("Precision exceeds maximum of %d\n", MAXPRC);
		exit(66);
	}


Just another question:

if all the printf() calls where changed to writef(), would the display issues of the cast(int)(p[i]) go away?  Or does it need to be there?