gcc: pointer to array

[Alexei A. Frounze]

Hi all,

I have a question regarding the gcc behavior (gcc version 3.3.4).

On the following test program it emits a warning:
#include <stdio.h>

int aInt2[6] = {0,1,2,4,9,16};
int aInt3[5] = {0,1,2,4,9};

void print1 (const int* p, size_t cnt)
{
while (cnt--)
printf ("%d\n", *p++);
}

void print2 (const int (*p)[5])
{
size_t cnt;
#if 0
// prohibited:
(*p)[0]=0;
#endif
for (cnt=0; cnt<5; cnt++)
printf ("%d\n", (*p)[cnt]);
}

int main()
{
printf ("test begin\n");

print1 (aInt2, sizeof(aInt2)/sizeof(aInt2[0]));
print2 (&aInt3); // <-- warns here

printf ("test end\n");
return 0;
}

The warning is:
MOD.c: In function `main':
MOD.c:: warning: passing arg 1 of `print2' from incompatible pointer type

Why is that? How is this different from using print1 (aInt2, ...)? All I
want to do is to explicitly show that the pointer is to an array of 5
entries and ensure that it's not modified in anyway inside print2(). However
the #if 0'd assignment operator inside print2() is correctly handled by
gcc -- an error is generated:
MOD.c: In function `print2':
MOD.c:: error: assignment of read-only location
What's wrong with gcc?

There's another thing about the pointer to the array is... The compiler
doesn't generate a warning if I change in print2()
for (cnt=0; cnt<5; cnt++)
to
for (cnt=0; cnt<6; cnt++)
and lets me access (*p)[5], though I think at least a warning should be
generated here.
It doesn't warn me if I put
aInt3[6] = 0;
into main(). But in both cases the compiler "knows" the real size of the
array, still no warning...
Is this OK???

Thanks,
Alex
P.S. I compile it as gcc MOD.c -Wall -oMOD.exe

[Netocrat]

Tim Rentsch wrote:

"Dik T. Winter" <Di********@cwi .nl> writes:

In article <kf************ *@alumnus.calte ch.edu>
Tim Rentsch <tx*@alumnus.ca ltech.edu> writes: <snip> Back to your comments:

> The definition of
> lvalue (given in 6.3.2.1 p1) says that an lvalue is (defined to
> be) an expression with an object type or an incomplete type
> other than void; whereas, as many or most regular readers of
> CLC know, an lvalue is *supposed* to be something else (roughly
> speaking, an expression that forms an address, which address
> needs to be implicitly dereferenced to get a value, or which in
> certain cases may be used to store a value into an object at
> that address).
I do not know whether this comment is indeed true.

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

<snip>
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.
<snip>
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]

Dik T. Winter wrote:

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 */

--
pete

[Tim Rentsch]

Tim Rentsch <tx*@alumnus.ca ltech.edu> writes:

"Dik T. Winter" <Di********@cwi .nl> writes:

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]

la************@ ugs.com writes:

Simon Biber <ne**@ralmin.cc > wrote:

Nobody expects the definitions in general-purpose dictionary to provide
an absolutely accurate treatise on what can be considered a "flower" and
what cannot, let alone more abstract concepts like "love". A reasonable
description of the concept, that allows you to tell it apart from other
similar concepts, is enough.

On the other hand, the C Standard is expected to be used to create a
family of computer programs, called "implementation s", which can all
accept exactly the same input and (produce programs that) have exactly
the same behaviour. The Standard is expected to be the final arbiter of
whether an implementation is correct or incorrect. For this reason, any
definitions in the Standard should be held to a higher standard.

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]

On Fri, 09 Jun 2006 04:59:42 GMT, "S.Tobias"
<si***@FamOuS.B edBuG.pAlS.INVA LID> wrote:

In comp.lang.c Netocrat <ne******@dodo. com.au> wrote:

On Thu, 14 Jul 2005 02:47:13 -0700, Andrey Tarasevich wrote:

Netocrat wrote: ...
Neither of these examples removes a const attribute from an lvalue, which
is impossible by definition. An lvalue can be assigned to.

Huh? No. By definition, lvalue is something that has address in storage. In
general case lvalue cannot be assigned to. Only _modifyable_ lvalue can be
assigned to, but there are also non-modifyable lvalues.

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