gcc: pointer to array

[Netocrat]

If you'd been along for the ride on this thread from the beginning you
wouldn't doubt it.

I'm pretty sure this list isn't complete; I haven't
attempted to do any kind of exhaustive search.

Whereas in the pedantry this thread has caused me to adopt I have
attempted an exhaustive search, the results of which are posted in my
reply to Keith's response.

Actually I think the expression '&(a+b)' is nonsense no matter
what the types of a and b are.

Consider this expression:

sizeof &(a+b)

Assuming no variable length arrays, there is no evaluation of
the address operator; however, the expression is still
illegal:

Right, because whilst C99 arguably defines it as an lvalue (as I noted
in my response to Keith it's possible - but IMO not preferable - to
argue that whether or not such an expression is an lvalue is
unspecified), it certainly doesn't define it as an object, and it
violates a constraint (again, we've covered this ground already in this
thread):

6.5.3.2 Address and indirection operators
Constraints

#1

The operand of the unary & operator shall be either a function
designator, the result of a [] or unary * operator, or an lvalue that
designates an object that is not a bit- field and is not declared with
the register storage-class specifier.

 

[pete]

But the address
operator requires evaluation, and there you are.

/* BEGIN new.c */

#include <stdio.h>

int main(void)
{
int c;

if (&c != NULL) {
puts("That depends on what you mean by evaluation.\n"
"The value of c, is indeterminate.");
}
return 0;
}

/* END new.c */

 

[Tim Rentsch]

Pray provide a reference. I have looked through the draft and did
not find any such statements. [...also for footnotes...]

[snip] The footnotes include numbers 95, 92 and 94; [snip]

Typo correction: those should have been 85, 92 and 94.

 

[Tim Rentsch]

I disagree. The *definitions* in the standard, like the definitions in
a dictionary, are just intended to be reasonable descriptions of the
concepts. The rest of the standard is the accurate treatise describing
them in detail.

I find this opinion rather appalling, especially coming from
someone so closely associated with the writing process for
the C standards documents.

A statement labelled as a definition in the C standard
should *by itself* be as complete and precise a definition
as is reasonably possible for a definition to be. That
isn't to say definitions must be written in formal language;
informal prose can still be complete and precise. But
something labelled a definition should be a definition, not
an approximate description or a statement of some properties
that might hold for the term in question.

Of course, other statements in the standard may very well
supply additional constraints that are required to hold
between defined elements. But there should be a clear
demarcation between where definitions end, and where
statements of constraints begin.

The idea that definitions and statements about the defined
terms be kept separate isn't a new idea; it goes back over
2000 years, to Euclid.

 

[av]

Right, my concept of lvalue was slightly out. Non-modifiable being for
example arrays and structs.

I'm not sure it's that simple with storage for lvalues. Take `register'
variables for an example, or pointers to objects whose lifetime has
finished (dereferencing such a pointer is an lvalue, whether
the object exists or not).

Consider also this example:

struct s { int a[1]; };
struct s f(void);

f().a[0] = 7; //UB

The expression on the left is clearly a modifiable lvalue.
But does it take any storage? I think C++ is more verbose about
temporaries; they can be optimized out, which is unspecified.
I don't think C even has an idea of a temporary.

OTOH, f().a decays into a pointer to its first element, therefore
the array the pointer points to must be an object, therefore it
must (temporarily) take some storage. Is that a right conclusion?

<code>
#include <stdio.h>
struct s { int a[1]; };
struct s *f(void){static struct s a; return &a;}

int main(void)
{(*f()).a[0] = 0xFFFFFFF0; //NOT_UB
printf("value of s.a[0] is: %x\n", (*f()).a[0]);
return 0;
}
<code>
this above seems has not UB in the C language

<code>
#include <stdio.h>

struct s { int a[1]; };

struct s *f(void){static struct s a; return &a;}

int main(void)
{f()->a[0] = 0xFFFFFFF0; //NOT_UB
printf("value of s.a[0] is: %x\n", f()->a[0]);
return 0;
}
<code>
the same for this in the C language



// the cpp version
#include <stdio.h>

struct s { int a[1]; };

struct s& f(void){static struct s a; return a;}

int main(void)
{f().a[0] = 0xFFFFFFF0;
printf("value of s.a[0] is: %x\n", f().a[0]);
return 0;
}

and this for cpp.
in cpp if you want to use the result of function like lvalue
have to return an address of allocated memory