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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Keith Thompson]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

Please excuse me if this has already been covered.

Given

char x[42];

is

sizeof(x[999])

any kind of error?

[...]

I believe it's perfectly valid, and must yield 1.

x[999] is equivalent to *(x+999). The addition would invoke undefined
behavior, but only if it were evaluated.

I see no more reason for
sizeof(x[999])
to invoke UB than for
if (0) {
x[999];
}
to do so.

--
Keith Thompson (The_Other_Keith) 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"

[christian.bau]

On Sep 19, 3:09 am, Keith Thompson <[e-mail]:

I believe it's perfectly valid, and must yield 1.

x[999] is equivalent to *(x+999). The addition would invoke undefined
behavior, but only if it were evaluated.

I see no more reason for
sizeof(x[999])
to invoke UB than for
if (0) {
x[999];
}
to do so.

It really must be fine. A similar situation is this one, which can be
found gazillion times in everyone's code::

something* p;
p = malloc (sizeof (*p));

This is the recommended idiom to allocate memory, and the expression
*p on its own would invoke undefined behaviour just like x[999]. It's
fine because *p is not evaluated.

[Army1987]

On Wed, 19 Sep 2007 00:16:49 +0000, Richard Tobin wrote:

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];

Even in this case, x's type is a VLA, but x[999]'s type is char,
so it is not evaluated by sizeof.

--
Army1987 (Replace "NOSPAM" with "email")
If you're sending e-mail from a Windows machine, turn off Microsoft's
stupid “Smart Quotes� feature. This is so you'll avoid sprinkling garbage
characters through your mail. -- Eric S. Raymond and Rick Moen

[Richard Tobin]

In article <11**********************@50g2000hsm.googlegroups. com>,
christian.bau <ch***********@cbau.wanadoo.co.ukwrote:

>It really must be fine. A similar situation is this one, which can be
found gazillion times in everyone's code::

something* p;
p = malloc (sizeof (*p));

Yes, that's a convincing argument.

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

[Richard Tobin]

In article <pa****************************@NOSPAM.it>,
Army1987 <ar******@NOSPAM.itwrote:

> int n = 42;
char x[n];

>Even in this case, x's type is a VLA, but x[999]'s type is char,
so it is not evaluated by sizeof.

Oops, yes. Then what about

int n = 42;
char x[n][n];

sizeof(x[999]);

I can't see how it could cause a problem in practice, because what would
the compiler do with the result of computing x[999] anyway?

I haven't looked at how compilers handle this sort of thing, but I assume
they perform a kind of abstract interpretation in which expressions are
evaluated for their type rather than their value.

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

[Charlie Gordon]

"Richard Tobin" <ri*****@cogsci.ed.ac.uka écrit dans le message de news:
fc***********@pc-news.cogsci.ed.ac.uk...

In article <pa****************************@NOSPAM.it>,
Army1987 <ar******@NOSPAM.itwrote:

>> int n = 42;
char x[n];

>>Even in this case, x's type is a VLA, but x[999]'s type is char,
so it is not evaluated by sizeof.

Oops, yes. Then what about

int n = 42;
char x[n][n];

sizeof(x[999]);

I can't see how it could cause a problem in practice, because what would
the compiler do with the result of computing x[999] anyway?

I haven't looked at how compilers handle this sort of thing, but I assume
they perform a kind of abstract interpretation in which expressions are
evaluated for their type rather than their value.

This is a good example of the problem with the wording of the Standard
regarding VLA-typed arguments to sizeof. There is no reason to evaluate
x[999] to determine its size. It looks like a defect in C99 IMHO.

--
Chqrlie.

[Kenneth Brody]

Charlie Gordon wrote:

>
"Richard Tobin" <ri*****@cogsci.ed.ac.uka écrit dans le message de news:
fc***********@pc-news.cogsci.ed.ac.uk...

[...]

Oops, yes. Then what about

int n = 42;
char x[n][n];

sizeof(x[999]);

I can't see how it could cause a problem in practice, because what would
the compiler do with the result of computing x[999] anyway?

[...]

This is a good example of the problem with the wording of the Standard
regarding VLA-typed arguments to sizeof. There is no reason to evaluate
x[999] to determine its size. It looks like a defect in C99 IMHO.

I assume you are referring to 6.5.3.4p2:

If the type of the operand is a variable length array type, the
operand is evaluated; otherwise, the operand is not evaluated and
the result is an integer constant.

Note that it says the operand is evaluated if it is a VLA, not if it
is a member of a VLA. In the above example, "sizeof(x[999])" would
not, IMO, evaluate the operand, because "x[999]" is not a VLA. Only
if you did "sizeof(x)" would it need to evaluate the operand "x".

Okay, hold on... (Isn't stream of consciousness writing fun?) I see
that x is a two-dimensional VLA in this new example. I guess that
that would mean that "x[999]" is a VLA.

Is it possible to have a VLA of different-sized VLAs? For example,
can the VLA "foo" have foo[1] point to a 3-element VLA while foo[2]
points to a 4-element VLA? If that can be done, then I can see why
it may be necessary to evaluate the operand of "sizeof(foo[x])".

--
+-------------------------+--------------------+-----------------------+
| 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>

[Richard Tobin]

In article <46***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.netwrote:

>Okay, hold on... (Isn't stream of consciousness writing fun?) I see
that x is a two-dimensional VLA in this new example. I guess that
that would mean that "x[999]" is a VLA.

Yes.

>Is it possible to have a VLA of different-sized VLAs?

No. There's no syntax for declaring such a thing, and it doesn't
make much sense implementationally: how would you represent it?
And if you come up with a way to represent it, it's unlikely to
be better than an array of pointers to different-sized arrays.

>For example,
can the VLA "foo" have foo[1] point to a 3-element VLA while foo[2]
points to a 4-element VLA?

Point to, but not be.

-- Richard

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

[Keith Thompson]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <pa****************************@NOSPAM.it>,
Army1987 <ar******@NOSPAM.itwrote:

>> int n = 42;
char x[n];

>>Even in this case, x's type is a VLA, but x[999]'s type is char,
so it is not evaluated by sizeof.

Oops, yes. Then what about

int n = 42;
char x[n][n];

sizeof(x[999]);

I can't see how it could cause a problem in practice, because what would
the compiler do with the result of computing x[999] anyway?

I haven't looked at how compilers handle this sort of thing, but I assume
they perform a kind of abstract interpretation in which expressions are
evaluated for their type rather than their value.

Since x[999] is a VLA, it's evaluated even when it's an argument to
sizeof, so this invokes undefined behavior.

In practice, since the evaluation isn't going to do anything, I would
expect an implementation to just compute the size and not try to read
the out-of-bounds array element.

My guess is that there's some case involving VLAs (or at least the
committee thought there was some case) where the evaluation is
actually necessary. The committee needed to define when arguments to
sizeof are evaluated and when they aren't; it was easier to say that
VLAs are evaluated than to define exactly when evaluation is
necessary.

--
Keith Thompson (The_Other_Keith) 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"

[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.orgwrites:

[...]

I would favour going along with your argument above ("Determining 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_Keith) 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"