The canonical clc malloc idiom

[Keith Thompson]

The comp.lang.c-recommended way to invoke malloc() is, of course:

some_type *ptr;
ptr = malloc(count * sizeof *ptr);

But what if (in C99 only) ptr is a pointer to a VLA (variable-length
array) type? Consider this:

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int n = 10;
typedef char VLA[n];
VLA *ptr = NULL;
ptr = malloc(3 * sizeof *ptr);
printf("sizeof *ptr = %d\n", (int)sizeof *ptr);
return 0;
}

As far as I can tell, this is legal in C99. The operand of sizeof in
the malloc call is *ptr, which is of a variable-length array type,
which means, according to C99 6.5.3.4p2, that it's evaluated. Since
ptr is a null pointer at that point, evaluating *ptr invokes undefined
behavior.

I'm not suggesting that we should drop the clc-approved method for the
normal case; I suspect that malloc calls involving VLA types are going
to be vanishingly rare. It's just an interesting quirk of the
language.

Incidentally, the above program compiles and executes without error
under gcc in its C99ish mode. That doesn't prove anything, since it's
one possible consequence of UB.

I think I'll post in comp.std.c asking just what C99 6.5.3.4p2 really
means and why the operand is evaluated.

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

[Duncan Muirhead]

On Wed, 19 Sep 2007 21:20:17 -0700, Keith Thompson wrote:

The comp.lang.c-recommended way to invoke malloc() is, of course:

some_type *ptr;
ptr = malloc(count * sizeof *ptr);

But what if (in C99 only) ptr is a pointer to a VLA (variable-length
array) type? Consider this:

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int n = 10;
typedef char VLA[n];
VLA *ptr = NULL;
ptr = malloc(3 * sizeof *ptr);
printf("sizeof *ptr = %d\n", (int)sizeof *ptr);
return 0;
}

As far as I can tell, this is legal in C99. The operand of sizeof in
the malloc call is *ptr, which is of a variable-length array type,
which means, according to C99 6.5.3.4p2, that it's evaluated. Since
ptr is a null pointer at that point, evaluating *ptr invokes undefined
behavior.

I'm not suggesting that we should drop the clc-approved method for the
normal case; I suspect that malloc calls involving VLA types are going
to be vanishingly rare. It's just an interesting quirk of the
language.

Incidentally, the above program compiles and executes without error
under gcc in its C99ish mode. That doesn't prove anything, since it's
one possible consequence of UB.

I think I'll post in comp.std.c asking just what C99 6.5.3.4p2 really
means and why the operand is evaluated.

And why the restriction to variable length array types?
Again with c99ish gcc this compiles and appears to run correctly:
#include <stdlib.h>
#include <stdio.h>
int main( int argc, char** argv)
{
struct odd
{ int b;
int a[argc];
};
struct odd* p;
printf( "sizeof odd %d\n", sizeof *p);
return EXIT_SUCCESS;
}
I'd have thought that if "evaluation" was required for your ptr, it would
be required for my p too.

[Army1987]

On Wed, 19 Sep 2007 21:20:17 -0700, Keith Thompson wrote:

The comp.lang.c-recommended way to invoke malloc() is, of course:

some_type *ptr;
ptr = malloc(count * sizeof *ptr);

But what if (in C99 only) ptr is a pointer to a VLA (variable-length
array) type? Consider this:

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int n = 10;
typedef char VLA[n];
VLA *ptr = NULL;
ptr = malloc(3 * sizeof *ptr);
printf("sizeof *ptr = %d\n", (int)sizeof *ptr);
return 0;
}

As far as I can tell, this is legal in C99. The operand of sizeof in
the malloc call is *ptr, which is of a variable-length array type,
which means, according to C99 6.5.3.4p2, that it's evaluated. Since
ptr is a null pointer at that point, evaluating *ptr invokes undefined
behavior.

I'm not suggesting that we should drop the clc-approved method for the
normal case; I suspect that malloc calls involving VLA types are going
to be vanishingly rare. It's just an interesting quirk of the
language.

Incidentally, the above program compiles and executes without error
under gcc in its C99ish mode. That doesn't prove anything, since it's
one possible consequence of UB.

But it is a strong clue that it doesn't actually read from *ptr,
since that would be likely to cause a SIGSEGV. I tried declaring
ptr as volatile VLA *, but it still doesn't crash. Whereas the UB
allows it not to actually read from there, the compiler would need
to do a serious amount of language lawyering to behave like that.
A more likely explanation is in http://gcc.gnu.org/c99status.html,
where the support for VLAs is marked as "Broken".

In the C99 rationale I can read:
Side effects in variable length array size expressions are guaranteed to be produced, except in
one context. If a size expression is part of the operand of a sizeof operator, and the result of
that sizeof operator does not depend on the value of the size expression, then it is unspecified
10 whether side effects are produced. In the following example:
{
int n = 5;
int m = 7;
size_t sz = sizeof(int (*)[n++]);
15 }
the value of the result of the sizeof operator is the same as in:
{
int n = 5;
int m = 7;
20 size_t sz = sizeof(int (*)[m++]);
}
Since the value stored in sz does not depend on the size expression, the side effect in n++ is
not guaranteed to occur. Requiring the side effect introduced a burden on some
implementations. Since side effects in this context seemed to have limited utility and are not
25 perceived to be a desired coding style, the Committee decided to make it unspecified whether
these size expressions are actually evaluated.

IOW, "don't do that".
--
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

[Keith Thompson]

Duncan Muirhead <dm***@csl.co.ukwrites:

On Wed, 19 Sep 2007 21:20:17 -0700, Keith Thompson wrote:

[...]

>I think I'll post in comp.std.c asking just what C99 6.5.3.4p2 really
means and why the operand is evaluated.

And why the restriction to variable length array types?
Again with c99ish gcc this compiles and appears to run correctly:
#include <stdlib.h>
#include <stdio.h>
int main( int argc, char** argv)
{
struct odd
{ int b;
int a[argc];
};
struct odd* p;
printf( "sizeof odd %d\n", sizeof *p);
return EXIT_SUCCESS;
}
I'd have thought that if "evaluation" was required for your ptr, it would
be required for my p too.

Yes, that looks like another flaw. I'll post to comp.std.c again.

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

[=?iso-2022-kr?q?Harald_van_D=0E=29=26=0Fk?=]

On Thu, 20 Sep 2007 11:18:25 -0700, Keith Thompson wrote:

Duncan Muirhead <dm***@csl.co.ukwrites:

>On Wed, 19 Sep 2007 21:20:17 -0700, Keith Thompson wrote:

[...]

>>I think I'll post in comp.std.c asking just what C99 6.5.3.4p2 really
means and why the operand is evaluated.

And why the restriction to variable length array types? Again with
c99ish gcc this compiles and appears to run correctly: #include
<stdlib.h>
#include <stdio.h>
int main( int argc, char** argv)
{
struct odd
{ int b;
int a[argc];
};
struct odd* p;
printf( "sizeof odd %d\n", sizeof *p); return EXIT_SUCCESS;
}
I'd have thought that if "evaluation" was required for your ptr, it
would be required for my p too.

Yes, that looks like another flaw. I'll post to comp.std.c again.

You're not allowed to have VLA structure members, so there doesn't have
to be any way for sizeof to deal with VLA structure members. If an
implementation supports them as an extension, the implementation is also
allowed to evaluate them as an operand to sizeof, because it won't affect
any correct program.

[Keith Thompson]

Army1987 <ar******@NOSPAM.itwrites:
[...]

In the C99 rationale I can read:
Side effects in variable length array size expressions are
guaranteed to be produced, except in one context. If a size
expression is part of the operand of a sizeof operator, and the
result of that sizeof operator does not depend on the value of
the size expression, then it is unspecified 10 whether side
effects are produced. In the following example:
{
int n = 5;
int m = 7;
size_t sz = sizeof(int (*)[n++]); 15 }
the value of the result of the sizeof operator is the same as in:
{
int n = 5;
int m = 7; 20 size_t sz = sizeof(int (*)[m++]);
}
Since the value stored in sz does not depend on the size
expression, the side effect in n++ is not guaranteed to
occur. Requiring the side effect introduced a burden on some
implementations. Since side effects in this context seemed to have
limited utility and are not 25 perceived to be a desired coding
style, the Committee decided to make it unspecified whether these
size expressions are actually evaluated.

IOW, "don't do that".

I think this is an inconsistency between the Rationale and the
Standard. According to the standard, it's *not*
implementation-defined whether the side effect occurs. C99 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.

In the case of

sizeof(int (*)[m++])

the operand is a pointer type, not a VLA type, so it's not evaluated
(assuming that evaluating a type makes sense).

I don't see anything in the standard that makes evaluation of a sizeof
operand implementation-defined; either it's evaluated or it isn't.

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

[Keith Thompson]

Duncan Muirhead <dm***@csl.co.ukwrites:
[...]

And why the restriction to variable length array types?
Again with c99ish gcc this compiles and appears to run correctly:
#include <stdlib.h>
#include <stdio.h>
int main( int argc, char** argv)
{
struct odd
{ int b;
int a[argc];
};
struct odd* p;
printf( "sizeof odd %d\n", sizeof *p);
return EXIT_SUCCESS;
}
I'd have thought that if "evaluation" was required for your ptr, it would
be required for my p too.

Your program contains a constraint violation that gcc is failing to
diagnose.

C99 6.7.2.1p8:

A member of a structure or union may have any object type other
than a variably modified type.

(I was almost finished with my comp.std.c post before I noticed this.)

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

[Flash Gordon]

Keith Thompson wrote, On 20/09/07 20:12:

Army1987 <ar******@NOSPAM.itwrites:
[...]

>In the C99 rationale I can read:
Side effects in variable length array size expressions are
guaranteed to be produced, except in one context. If a size
expression is part of the operand of a sizeof operator, and the
result of that sizeof operator does not depend on the value of
the size expression, then it is unspecified 10 whether side
effects are produced. In the following example:
{
int n = 5;
int m = 7;
size_t sz = sizeof(int (*)[n++]); 15 }
the value of the result of the sizeof operator is the same as in:
{
int n = 5;
int m = 7; 20 size_t sz = sizeof(int (*)[m++]);
}
Since the value stored in sz does not depend on the size
expression, the side effect in n++ is not guaranteed to
occur. Requiring the side effect introduced a burden on some
implementations. Since side effects in this context seemed to have
limited utility and are not 25 perceived to be a desired coding
style, the Committee decided to make it unspecified whether these
size expressions are actually evaluated.

IOW, "don't do that".

I think this is an inconsistency between the Rationale and the
Standard. According to the standard, it's *not*
implementation-defined whether the side effect occurs. C99 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.

In the case of

sizeof(int (*)[m++])

the operand is a pointer type, not a VLA type, so it's not evaluated
(assuming that evaluating a type makes sense).

I don't see anything in the standard that makes evaluation of a sizeof
operand implementation-defined; either it's evaluated or it isn't.

In N1124 and N1256 you have in 6.7.5.2 para 5:
If the size is an expression that is not an integer constant
expression: if it occurs in a declaration at function prototype
scope, it is treated as if it were replaced by *; otherwise,
each time it is evaluated it shall have a value greater than zero.
The size of each instance of a variable length array type does not
change during its lifetime. Where a size expression is part of the
operand of a sizeof operator and changing the value of the size
expression would not affect the result of the operator, it is
unspecified whether or not the size expression is evaluated.

which I believe is inconsistent with the paragraph you quoted. So I
think it is a defect in the standard.

Since my comment is about the standard itself I've cross-posted to
comp.std.c
--
Flash Gordon