Re: storage for temporaries

On Thu, 21 Jul 2005 09:30:04 +0000, S.Tobias wrote:

> I'm examining the existence of temporary objects by looking at
> their addresses. The trick is to create a structure that contains
> an array as its first member. In an expression the array rvalue
> is converted to a pointer to its first member. Since this address
> is also the address of the array, and that is the address of the
> structure, I conclude that this is also the address of the temporary
> storage for the structure (r)value.
>
> I'm aware of "Heisenberg effect", ie. in absence of an observer
> (".a" operator) the actual behaviour of the operand expressions
> might be different. Some behaviours are impossible to measure,
> eg. in expression `x = f()' it's impossible to check if `f()'
> returns directly into `x', or into a temporary (or other) object,
> which is then copied into `x' (I could of course analyze the assembly
> listing, but I want to rely only on visible behaviour).
> I don't attempt to modify anything.
>
> I would like you to answer my questions and review my conclusions.
> The code is at the end, together with the output for como and gcc.
> This code compiles only in C99 mode.
>
> 1. It is obvious that for some large temporary data a compiler
> must sometimes reserve some memory. What does the Standard
> say about storage for temporary values?

Very little. However 6.5.2.2p5 says:

"... 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."

Which means that this "temporary storage" doesn't have to last beyond the
next sequence point. That implies that a pointer to it becomes
indeterminate after the next sequence point.

> Is it defined (C&V), undefined or unspecified?

The implication is that it can be accessed up to the next sequence point.
C never says how memory is allocated, the concepts of undefined behaviour
etc. relate to specific code and constructs not allocation techniques.

> What does the Standard say about
> the output from my program?

There is a squence point after the evaluation of printf()'s argumets just
before it is called. So the value of the pointer you pass is indeterminate
within printf() so the behaviour is undefined.

> 2. Is the expression `f().a[0]' valid? Value of the result of
> function call (or any other operator that yields an rvalue) is
> accessed, but there's no sequence point, so there doesn't seem to
> be an explicit UB in that area. OTOH it is undefined behaviour if
> the pointer (f().a + 0) has invalid value (6.5.3.2p4). Even if for
> some reason it is valid and there's no object, then it is undefined
> behaviour if the lvalue `f().a[0]' does not designate an object when
> evaluated (6.3.2.1p1). Anyway, it seems like the answer depends
> on whether the temporary thingy for the rvalue is an object or not.

6.3.2.1p3 certainly suggests that the f().a part of f().a[0] evaluates to
a pointer to the first element of an array object.

> 3. In case of sfunc_static() (below) the address of the temporary
> could be the same as the static object, because modifying the result
> of a fn call raises UB, therefore there is nothing to "protect".

The first question is whether they have to be distinct objects in the
abstract machine. That isn't entirely clear but lets assume yes. Then if
the caller had a way of testing the address of the temporary object
against the address of the static object then they would have to be
unequal. However as written that doesn't seem to be possible so you're
right they could be the same object. If the static object had external
linkage they would need to be different, or at least behave as if they are.

> 4. Similar argument applies to "=" operator (address "val" could
> be the same as that of "s1"). (Conditional and comma operators
> in gcc output reuse the operand object storage for the value.)

Other sources of non-lvalue structs are much less clear as 6.5.2.2p5
doesn't apply to them. It is also less clear that this temporary object
has to be different to s1 in the abstract machine.

> 5. Const object storage can always be reused as storage for its
> value, because it is UB if that object is modified.

There is still the issue of testing the address of the const object
against the address of the temporary object.

....

Lawrence
.

Relevant Pages

  • Re: The code of co-workers
    ... -all of the pointers have to be valid (dereferencing an invalid pointer ... -*i+1 and *j+1 must be valid indices into the array that a points into ... these are modified between the same pair of sequence points (modifying ... To avoid burying any useful diagnostics in useless ones, ...
    (comp.programming)
  • Re: Difference between Char* ptr and char arrCh []
    ... I have a few queries regarding array of characters using array ... notation and pointer notation. ... Is there a difference in storage of global char* and char* inside ...
    (comp.lang.c)
  • Re: Returning an array using based pointers
    ... The challenge here is that the procedure uses %alloc and %realloc ... to extend the size of the array real-time. ... back the pointer to the memory, but then it sounds like I would have to ... Since you can't deallocate the storage in the procedure since the ...
    (comp.sys.ibm.as400.misc)
  • Re: A newbie question on out parameter
    ... > I'm trying to understand the relation between array and pointer. ... An Array is basically a linear sequence of variables in your PC's ... A Pointer is stored as a single variable in Memory. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: When to use automatic variables and when to use malloc
    ... that; an array. ... I fail to see how any danger is removed. ... A pointer *ITSELF* is storage, ...
    (comp.lang.c)