digitalmars.D - "bug" in pi.d of samples
- Sampsa Lehtonen (22/22) Jul 23 2004 I was testing out the samples that come with the D compiler. The output ...
 - Berin Loritsch (9/38) Jul 23 2004 Hmm. Wouldn't it be considered a bug if the implicit conversion did not...
 - Berin Loritsch (16/16) Jul 23 2004 Another "bug" in pi.d:
 
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
 Jul 23 2004
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.
 Jul 23 2004
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?
 Jul 23 2004








 
 
 
 Berin Loritsch <bloritsch d-haven.org> 