🚀 go-pugleaf

In article <133@daitc.ARPA> jkrueger@daitc.ARPA (Jonathan Krueger) writes:
>My prediction, based on K&R, was the output:
>	count is 800, now 839
>Indeed, the Pyramid 98x produces exactly this output.
>But your mileage may vary.  4.2BSD VAX, Gould, and Sun-3 produce output:
>	count is 800, now 800

There is no ambiguity; the Pyramid has produced the correct answer
and the other three compilers are wrong.  The SVR2 VAX PCC also gets
this right, so presumably all recent 3B CCSes do also.

The code is "portable" to correct compilers.  Obviously it is not
"portable" to ALL compilers, as you have shown.  Nag your system
vendors to fix their compilers.

In article <133@daitc.ARPA> jkrueger@daitc.ARPA (Jonathan Krueger) writes:
[only the following three lines are needed]
>#define	DEFCONST	1.05
>	int	count = 800;
>	count *= DEFCONST;

The correct result is 840 (or something nearby, such as 839, depending
on roundoff error).

>Indeed, the Pyramid 98x produces exactly this output.
>But your mileage may vary.  4.2BSD VAX, Gould, and Sun-3 produce output:
>	count is 800, now 800
>Which brings me to the question: is this code non-portable, or do
>three out of four compilers surveyed fail to correctly implement K&R?

Three out of four compilers surveyed failed to correctly implement K&R.

The bug is an easy one to commit in PCC.  It was fixed some time ago
(I think it was fixed in 4.3BSD).  Try also

	f() {
		unsigned *a();
		int b();

		*a() %= b();
	}

and see whether the code generated is correct.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

In article <133@daitc.ARPA>, jkrueger@daitc.ARPA (Jonathan Krueger) writes:
> Here's a question of portability and language standards that came up in
> a real life program.  According to K&R or ANSI, predict the output of
> the following code:
> 
> #define	DEFCONST	1.05
> main()
> {
> 	int	count = 800;
> 
> 	printf("count is %d, ", count);
> 	count *= DEFCONST;
> 	printf("now %d\n", count);
> }
> 
> My prediction, based on K&R, was the output:
> 	count is 800, now 839
> Indeed, the Pyramid 98x produces exactly this output.
> But your mileage may vary.  4.2BSD VAX, Gould, and Sun-3 produce output:
> 	count is 800, now 800
> Which brings me to the question: is this code non-portable, or do
> three out of four compilers surveyed fail to correctly implement K&R?

	Just to stir things up a little, under VAX/VMS, I get an answer
of 839; Turbo C gives an answer of 840!

In article <430@uwovax.uwo.ca> 16012_3045@uwovax.uwo.ca (Paul Gomme) writes:
>In article <133@daitc.ARPA>, jkrueger@daitc.ARPA (Jonathan Krueger) writes:
>> Here's a question of portability and language standards that came up in
>> a real life program.  According to K&R or ANSI, predict the output of
>> the following code:
>> 
>> #define	DEFCONST	1.05
>> main()
>> {
>> 	int	count = 800;
>> 
>> 	printf("count is %d, ", count);
>> 	count *= DEFCONST;
>> 	printf("now %d\n", count);
>> }
>> 
>> My prediction, based on K&R, was the output:
>> 	count is 800, now 839
>> Indeed, the Pyramid 98x produces exactly this output.
>> But your mileage may vary.  4.2BSD VAX, Gould, and Sun-3 produce output:
                               ^^^^^^^^^^
>> 	count is 800, now 800

I don't get this at all! I am running on a VAX 8650 under Ultrix 2.0.
My results are:

cc non-optimized	count is 800, now 839
cc optimized		count is 800, now 839
gcc non-optimized	count is 800, now 839
gcc optimized		count is 800, now 839
vcc non-optimized	count is 800, now 839
vcc optimized		count is 800, now 839

HOWEVER, my sun 3/50 under Sun O/S 3.2 gives the following:

cc non-optimized	count is 800, now 800
cc optimized		count is 800, now 800

As mentioned in the  original article.
yechhh!

>> Which brings me to the question: is this code non-portable, or do
>> three out of four compilers surveyed fail to correctly implement K&R?
>
>	Just to stir things up a little, under VAX/VMS, I get an answer
>of 839; Turbo C gives an answer of 840!


Now, if on the sun, I s/count *= DEFCONST/count = count * DEFCONST/
I get the following:

cc non-optimized	count is 800, now 840
cc optimized		count is 800, now 840

This is even more interesting!

-david-

In article <133@daitc.ARPA>, jkrueger@daitc.ARPA (Jonathan Krueger) writes:
> [...] predict the output of the following code:
> #define	DEFCONST	1.05
> main(){
> 	int	count = 800;
> 	printf("count is %d, ", count);
> 	count *= DEFCONST;
> 	printf("now %d\n", count);
> }
> My prediction, based on K&R, was the output: count is 800, now 839
K&R says that ``a*=b'' is eqv to ``a=a*b'' *except* that ``a'' is
evaluated only once.  Sounds like the type cast is not going to be
done => 800 is right.

I don't know about ANSI, I *hope* they changed this; it's horribly
counterintuitive.

Yes, I'm biased; this is what my favorite compiler (Mark Williams C) says.
Rob Carriere

In article <374@accelerator.eng.ohio-state.edu> rob@raksha.eng.ohio-state.edu (Rob Carriere) writes:
>K&R says that ``a*=b'' is eqv to ``a=a*b'' *except* that ``a'' is
>evaluated only once.

Yes.

>Sounds like the type cast is not going to be done => 800 is right.

I didn't see any cast operator.  If you mean type conversion,
one IS supposed to be done in order to evaluate a*b where a is
an int and b is a double.  Then the assignment to a should
truncate the double expression value back to an int.

The correct answer is 839 or 840, depending on how precise your
floating-point architecture is.  800 is definitely incorrect.

In article <8228@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) 
writes:
>In article <374@accelerator.eng.ohio-state.edu> rob@raksha.eng.ohio-state.edu
>(Rob Carriere) writes: [...]
>>Sounds like the type cast is not going to be done => 800 is right.
>I didn't see any cast operator.  If you mean type conversion,
>one IS supposed to be done in order to evaluate a*b where a is
>an int and b is a double.  Then the assignment to a should
>truncate the double expression value back to an int.

Whoops.  You didn't see it because it isn't there, I *did* mean
conversion.  However, the conversion rule says that a is to be
converted to double; this seems to contradict the idea that a is to be
computed *once*.

Rob Carriere

In article <376@accelerator.eng.ohio-state.edu> 
rob@kaa.eng.ohio-state.edu (Rob Carriere) writes:

>Whoops.  You didn't see it because it isn't there, I *did* mean
>conversion.  However, the conversion rule says that a is to be
>converted to double; this seems to contradict the idea that a is to be
>computed *once*.

I thought the purpose of the definition was so that things like subscripts
and function calls needed to compute the lhs would not be repeated:

 a[f(x++) + --y] += 43;

has different results than

 a[f(x++) + --y]  =  a[f(x++) + --y] + 43;

To make this consistent with the standard, distinguish between "evaluation"
and the type conversions required in computation.

   John Carr             "When they turn the pages of history,
   jfc@Athena.mit.edu     When these days have passed long ago,
                          Will they read of us with sadness
                          For the seeds that we let grow?"  --Neil Peart

In article <376@accelerator.eng.ohio-state.edu> rob@kaa.eng.ohio-state.edu
(Rob Carriere) writes:
[re int a; ... a *= 1.05;]
>... the conversion rule says that a is to be converted to double; this
>seems to contradict the idea that a is to be computed *once*.

Right idea, wrong expansion: a's *address* (if it has one) is to be
computed once.  (a itself is indeed computed only once: if a is 800 it
is computed/evaluated as 800.  That value, now in a temporary
somewhere, is converted to double, multipled, and stored back in a's
address.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

> >> But your mileage may vary.  4.2BSD VAX, Gould, and Sun-3 produce output:
>                                ^^^^^^^^^^
> >> 	count is 800, now 800
> 
> I don't get this at all! I am running on a VAX 8650 under Ultrix 2.0.

So?  He said "4.2BSD", not "Ultrix 2.0".  4.2BSD and Ultrix 2.0 are different
systems; there's certainly no guarantee that any particular bugs in the 4.2BSD
compiler are also in the Ultrix 2.0 compiler.  One would hope, in fact, that
this would *not* be the case....

I see no reason not to take him at his word here; I presume that he, at least,
is actually *running* 4.2BSD.

> HOWEVER, my sun 3/50 under Sun O/S 3.2 gives the following:
> 
> cc non-optimized	count is 800, now 800
> cc optimized		count is 800, now 800

I believe this is an old PCC bug; the 4.2BSD VAX and Sun compilers are
PCC-based, and the Gould one may be PCC-based as well.  I would not be
surprised if the Pyramid compiler were *not* PCC-based.

My Sun-4/260, and a Sun-3/180 nearby, both running SunOS 4.0, as well as a
not-so-nearby Sun386i running SunOS 4.0RRBETA2, all give

	cc non-optimized	count is 800, now 840
	cc optimized		count is 800, now 840

A 4.3BSD VAX gives

	cc non-optimized	count is 800, now 839
	cc optimized		count is 800, now 839

Presumably the DEC compiler (if it's not the VAX C compiler, in which case you
should get the same results as on VAX/VMS) has had this bug fixed, as have the
4.3BSD compiler and the SunOS compilers.

In article <59649@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) writes:
> I would not be surprised if the Pyramid compiler were *not* PCC-based.

You're right.  When we got our first Pyramid system here at JHH (January,
1985), OSx cc was was pretty much just vanilla PCC.  This changed in about
mid-1985 as I recall.  Does anyone from Pyramid (Carl?  Sylvan?  Eric?)
want to confirm the date for me?


Phil Kos
A Pretty Happy Pyramid (and soon Sun) User

david@geac.UUCP (David Haynes) says:
	.
	.
	.

>>> Which brings me to the question: is this code non-portable, or do
>>> three out of four compilers surveyed fail to correctly implement K&R?
>>
>>	Just to stir things up a little, under VAX/VMS, I get an answer
>>of 839; Turbo C gives an answer of 840!
>
>
>Now, if on the sun, I s/count *= DEFCONST/count = count * DEFCONST/
>I get the following:
>
>cc non-optimized	count is 800, now 840
>cc optimized		count is 800, now 840
>

Microsoft C also produces the 840 result, suggesting that it's indeed
a rounding issue whether you get 839 or 840, but from the above
substitution, it sure looks like the sun compiler has a bug.  Let's
see now, compiled on my sun (SunOS 3.5 standard distribution), I get:

cc non-optimized	count is 800, now 840
cc optimized		count is 800, now 840

Funny thing, but it's not happening here...

I wonder when this was fixed...

Incidentally, I got the same results on an IS68K bsd unix running very
old software...
	-i

In article <376@accelerator.eng.ohio-state.edu> rob@kaa.eng.ohio-state.edu (Rob Carriere) writes:
>However, the conversion rule says that a is to be
>converted to double; this seems to contradict the idea that a is to be
>computed *once*.

That's not the rule.

	a op= b

(where a and b are expressions) is equivalent to

	a = a op b

EXCEPT that the expression a is EVALUATED only once.
I.e. if evaluation of the expression a has side-effects,
they will occur only once.
Once the expression is evaluated, it is used in the context

	a = a op b

and other stuff happens at that point.