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.

[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_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"

[christian.bau]

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

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************ **********@50g2 000hsm.googlegr oups.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
--
"Considerat ion 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******@NOSPA M.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
--
"Considerat ion 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***********@p c-news.cogsci.ed. ac.uk...

In article <pa************ *************** *@NOSPAM.it>,
Army1987 <ar******@NOSPA M.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***********@p c-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******@spamc op.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 implementationa lly: 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

--
"Considerat ion 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******@NOSPA M.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_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"