Another sizeof question

[Richard Tobin]

Please excuse me if this has already been covered.

Given

char x[42];

is

sizeof(x[999])

any kind of error? If so, since the expression is not evaluated, how
would such an error be detected? What if the declaration was

int n = 42;
char x[n];

?

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Kenneth Brody]

Keith Thompson wrote:
[...]

Determining the size of the object foo doesn't require evaluating
'foo' any more than determining the size of n requires evaluating it
to determine that its current value is 10. For a non-VLA type, the
size is known at compilation time. For a VLA type, the size is
associated with the type, not with some object of the type.

For example, given:

int n = 10;
typedef int vla[n];
vla foo, bar;

the size of the type "vla" will, in any sane implementation, be stored
once (probably in some anonymous object known to the compiler).

[...]

Consider:

size_t foo(int n)
{
int bar[n];
return sizeof bar;
}

Doesn't "bar" need to be evaluated, at least to the point of finding
out where its size has been stored?

(I don't use VLAs, as many [most?] of the compilers I use don't
support it, so this is mostly a thought experiment to me. But it
does make me wonder.)

What about:

#include <stdio.h>
int main(void)
{
int n=10;
int x=1,y=1;
char vla[n][n];
char non_vla[10][10];
size_t foo = sizeof vla[x++];
size_t bar = sizeof non_vla[y++];
printf("x is now %d\n",x);
printf("y is now %d\n",y);
return 0;
}

Since "vla[x++]" is a VLA, and therefore must be evaluated, does this
mean that side-effects are done as well? Will x be 2?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Keith Thompson]

Ben Bacarisse <be********@bsb .me.ukwrites:

Keith Thompson <ks***@mib.orgw rites:

[...]

I would favour going along with your argument above ("Determinin g the
size of the object foo doesn't require evaluating 'foo'") and altering
the standard to distinguish between sizeof applied to an expression
and sizeof applied to a type. The two cases are distinct in the
syntax, so I see no trouble with highlighting that they are different.
(In fact I think this would help; describing sizeof(int) as an
operator applied to an operand -- like all the other unary operators
-- is misleading.)

[...]

I was about to say that the sizeof operator applied to a parenthesized
type name isn't the only case of an operator that doesn't really act
like one (because its operand isn't any kind of expression). The left
operand of the "." or "->" operator is an expression, but the right
operand is an identifier that must be the name of a struct or union
member; that "operand" is not evaluated, at least not in the same way
that an expression is evaluated.

Fortunately, I took a look at the grammar, and it turns out that
they're defined as postfix operators, just as (IMHO) they should be:

postfix-expression:
primary-expression
...
postfix-expression . identifier
postfix-expression -identifier

In a sense, there's distinct postfix ".member" operator for each
member of each struct or union type, and likewise for "->". I'm not
sure why I thought they were defined as binary operators.

IMHO, it would have made more sense for 'sizeof expression' to be
treated as a unary-expression, but for 'sizeof ( type-name )' to be a
distinct kind of expression. Other symbols, such as "-" and "&",
denote two distinct operations, so the overloading wouldn't be a
problem.

But the current definition, though it introduces some special cases,
doesn't really cause any serious problems, so I don't think I'd
advocate changing the language.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"