Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!mintaka!ogicse!milton!merritt
From: merritt@milton.u.washington.edu (Ethan Merritt)
Newsgroups: comp.unix.ultrix
Subject: Re: auto-increment bug in Ultrix(4.1) C (DS3100)
Message-ID: <1991Apr16.003642.21319@milton.u.washington.edu>
Date: 16 Apr 91 00:36:42 GMT
References: <1991Mar31.214127.5224@pslu1.psl.wisc.edu> <1991Apr15.161123.16353@watcgl.waterloo.edu>
Followup-To: comp.unix.ultrix
Organization: University of Washington, Seattle
Lines: 29

In article <1991Apr15.161123.16353@watcgl.waterloo.edu>  idallen@watcgl.waterloo.edu (Ian! D. Allen [CGL]) writes (quoting others):

>  [ discussion of why failing to increment pc in the expression below before
>    completing function call is "not a bug" ]
>  So what can we conclude?  Only that the increment has to have taken effect
>  by the end of the expression.  Hence within the function call
>  
>                  (*(*pc++))()
>  
>  the value of pc is implementation-defined.  Congratulations, Ian!, you
>  can pick up your prize at....
>  
	All right, I'm willing to play the straight man here.  What is
the ANSI-provided definition of "expression"?  As I see it the lexical element
(*pc++) is already an expression, and the original complaint is perfectly
valid.  To make the point clearer, what would your ruling be on a statement
of the form:
		extern (void *)xxx;
		...
		(*(xxx = *pc++))();

What do you conclude about the value of xxx during the execution of the
function invoked?
						Ethan A Merritt
--------------------------------------------------------------------
Dept of Biological Structure                H510 Health Sciences
University of Washington SM-20              (206)543-8865
Seattle, WA 98195                           merritt@u.washington.edu
--------------------------------------------------------------------