What will happen when the size of a local variable length array turns out to be 0 (zero)?

[Xiangliang Meng]

Hi.

void setValue(int n)
{
int size = getValueLength( );
int buffer_p[size];

if (buffer_p)
{
....
}
}
When the local variable size is 0, will buffer_p be a null pointer? I doubt
it.

What will happen when the size of a local variable length array turns out to
be 0 (zero)? Is it an undefined behavior? Or an implementation-defined one?

Thank you.

Best Regards,

Xiangliang Meng

[Victor Bazarov]

"Xiangliang Meng" <xi************ *@hotmail.com> wrote...

void setValue(int n)
{
int size = getValueLength( );
int buffer_p[size];
This is not C++.

if (buffer_p)
{
....
}
}
When the local variable size is 0, will buffer_p be a null pointer? I doubt it.
It won't compile.
What will happen when the size of a local variable length array turns out to be 0 (zero)? Is it an undefined behavior? Or an implementation-defined

one?

It's a semantic error. The expression in brackets has to be
a compile-time constant.

Victor

[Barry Schwarz]

On Thu, 10 Jun 2004 04:11:54 GMT, "Victor Bazarov"
<v.********@com Acast.net> wrote:

"Xiangliang Meng" <xi************ *@hotmail.com> wrote...

void setValue(int n)
{
int size = getValueLength( );
int buffer_p[size];
This is not C++.

No, it's perfectly good C99.

if (buffer_p)
{
....
}
}
When the local variable size is 0, will buffer_p be a null pointer? I

doubt

it.

It won't compile.

What will happen when the size of a local variable length array turns out

to

be 0 (zero)? Is it an undefined behavior? Or an implementation-defined

one?

It's a semantic error. The expression in brackets has to be
a compile-time constant.

Not in C99.
<<Remove the del for email>>

[Jowtte]

Consider this code:

int testAlloc()
{
int size = 0;
int* buffer = new int [ size ];
int* buffer2 = new int [ 1 ];
...
}

It does allocate memory for buffer, yet I don't know how large it is.

Using my compiler, before "new" operating, buffer = buffer2 = 0xcccccccc
and after "new", buffer = 0x0x00430060, buffer2 = 0x00430030

I don't know why.

"Victor Bazarov" <v.********@com Acast.net> дÈëÏûÏ¢
news:ecRxc.1016 4$0y.743@attbi_ s03...

"Xiangliang Meng" <xi************ *@hotmail.com> wrote...

void setValue(int n)
{
int size = getValueLength( );
int buffer_p[size];
This is not C++.

if (buffer_p)
{
....
}
}
When the local variable size is 0, will buffer_p be a null pointer? I

doubt

it.

It won't compile.

What will happen when the size of a local variable length array turns

out to

be 0 (zero)? Is it an undefined behavior? Or an implementation-defined

one?

It's a semantic error. The expression in brackets has to be
a compile-time constant.

Victor

[Dave Townsend]

0xcccccc is just MSVC++ fill pattern for uninitialized variables
when you run in debug mode. If you look closely, you'll see size
has the same pattern before its initialized.
"Jowtte" <jo****@hotmail .com> wrote in message
news:ca******** ***@mail.cn99.c om...

Consider this code:

int testAlloc()
{
int size = 0;
int* buffer = new int [ size ];
int* buffer2 = new int [ 1 ];
...
}

It does allocate memory for buffer, yet I don't know how large it is.

Using my compiler, before "new" operating, buffer = buffer2 = 0xcccccccc
and after "new", buffer = 0x0x00430060, buffer2 = 0x00430030

I don't know why.

"Victor Bazarov" <v.********@com Acast.net> дÈëÏûÏ¢
news:ecRxc.1016 4$0y.743@attbi_ s03...

"Xiangliang Meng" <xi************ *@hotmail.com> wrote...

void setValue(int n)
{
int size = getValueLength( );
int buffer_p[size];

This is not C++.

if (buffer_p)
{
....
}
}
When the local variable size is 0, will buffer_p be a null pointer? I

doubt

it.

It won't compile.

What will happen when the size of a local variable length array turns

out

to

be 0 (zero)? Is it an undefined behavior? Or an implementation-defined

one?

It's a semantic error. The expression in brackets has to be
a compile-time constant.

Victor

[those who know me have no need of my name]

[fu-t set]

in comp.lang.c i read:

Hi.
hello. please do not cross-post between comp.lang.c and comp.lang.c++
unless you are reasonably certain the question and/or answer can or will
apply equally well to both languages -- not the case here.
int size = getValueLength( );
int buffer_p[size];
this is not valid c++. as such the remainder of this response is c
oriented, and is the reason behind the followup-to header i've used.

in c you would have a vla with no usable elements.
if (buffer_p) When the local variable size is 0, will buffer_p be a null pointer? I doubt
it.
buffer_p is not a pointer, ever, in any way. when you use buffer_p the
value it yields is a pointer (to the first element), but buffer_p itself
remains an array. when the vla is zero sized buffer_p will not yield a
null pointer value, it will have a distinct non-null address.
What will happen when the size of a local variable length array turns out to
be 0 (zero)? Is it an undefined behavior? Or an implementation-defined one?

declaring an array with a constant expression that evaluates to zero is a
constraint violation, but it is valid and well defined for a vla. of
course none of the elements may be accessed -- attempting to do so has
undefined behavior -- so, about the only things you can do involve the &
and sizeof operators.

--
a signature

[David Harmon]

On 10 Jun 2004 04:54:05 GMT in comp.lang.c++, Barry Schwarz
<sc******@deloz .net> wrote,

On Thu, 10 Jun 2004 04:11:54 GMT, "Victor Bazarov"
<v.********@co mAcast.net> wrote:

"Xiangliang Meng" <xi************ *@hotmail.com> wrote...

void setValue(int n)
{
int size = getValueLength( );
int buffer_p[size];

This is not C++.

No, it's perfectly good C99.

What part of "This is not C++" do you not understand.
As long as you are crossposting your answers to comp.lang.c++,
please confine yourself to standard conforming C++ code.

[Richard Bos]

"Xiangliang Meng" <xi************ *@hotmail.com> wrote:

void setValue(int n)
{
int size = getValueLength( );
int buffer_p[size];

if (buffer_p)
{
....
}
}
When the local variable size is 0, will buffer_p be a null pointer? I doubt
it.

Please do not cross-post questions like these to comp.lang.c and
comp.lang.c++. C and C++ are different languages, and some of the most
fundamental differences can be found in the area of memory allocation
and the type system. Therefore, the answer may well be different
depending on whether you're writing C or C++. I'll answer this question
presuming you want a C answer, and have set follow-ups accordingly.
Paragraph 6.7.5.2 of the C99 Standard says, amongst other things,

# If the size expression is not a constant expression, and it is
# evaluated at program execution time, it shall evaluate to a
# value greater than zero.

Since this appears outside the "constraint s" part of that paragraph,
violating it causes undefined behaviour. IOW, if, in your code, size
turns out to be 0, the array declaration is allowed to result in
anything at all. A null pointer is allowed; an array of one member is
allowed; crashing the program is allowed, too.

Richard

[Richard Bos]

David Harmon <so****@netcom. com.invalid> wrote:

<sc******@deloz .net> wrote,

<v.********@co mAcast.net> wrote:

"Xiangliang Meng" <xi************ *@hotmail.com> wrote...
int size = getValueLength( );
int buffer_p[size];

This is not C++.

No, it's perfectly good C99.

What part of "This is not C++" do you not understand.
As long as you are crossposting your answers to comp.lang.c++,
please confine yourself to standard conforming C++ code.

Since it is also cross-posted to comp.lang.c, please confine yourself to
Standard-conforming C code.

The moral of this post? Don't cross-post between c.l.c and c.l.c++;
you'll only make posters cross.

Richard

[Grumble]

David Harmon wrote:

On 10 Jun 2004 04:54:05 GMT in comp.lang.c++, Barry Schwarz
<sc******@deloz .net> wrote,

On Thu, 10 Jun 2004 04:11:54 GMT, "Victor Bazarov"
<v.********@com Acast.net> wrote:

"Xiangliang Meng" <xi************ *@hotmail.com> wrote...

void setValue(int n)
{
int size = getValueLength( );
int buffer_p[size];

This is not C++.

No, it's perfectly good C99.

What part of "This is not C++" do you not understand. As long as you
are crossposting your answers to comp.lang.c++, please confine
yourself to standard conforming C++ code.

I think Barry meant:

"No [it is not C++ indeed], [however] it's perfectly good C99."