In message <200610310851.DAA23180@Sparkle.Rodents.Montreal.QC.CA>, der Mouse wr
ites:
>Even when that member is an array, which is "used" by decaying it to a
>pointer to its [0] element?  Is the return-value object guaranteed to
>exist long enough for printf to access it, or does it go "out of
>scope" (except "scope" isn't really the right word, "storage duration"
>would be closer) before that?

>> Try it, or read section 6.5.2.3 of the C99 standard.

>Where can I find it?  I thought it was a pay-for-play "standard".

It mostly is, although it can be had fairly cheap (I think US$20).

That said, I don't see anything on the function return semantics in 6.5.2.3;
that's just the semantics of . and ->.

6.5.2.2 seems to be the relevant bit:

(5)	If the expression that denotes the called function has type pointer
	to function returning an object type, the function call expression
	has the same type as that object type, and has the value determined
	as specified in 6.8.6.4. Otherwise, the function call has type
	void. If an attempt is made to modify the result of a function call
	or to access it after the next sequence point, the behavior is
	undefined.

	...

(10)	The order of evaluation of the function designator, the actual
	arguments, and subexpressions within the actual arguments is
	unspecified, but there is a sequence point before the actual call.

It seems to me, then, that the sequence point between the evaluation of the
arguments to printf, and the execution of printf, invalidates the value
returned from the previous call.  Normally, pass-by-value saves you (if you
return an int, you can obviously pass it to another function), but in this
particular case, the actual argument to printf isn't the object, but just
its address, and the object in question ceases to have existence when the
next sequence point occurs.

So I say it's undefined behavior.

-s