«

Hi, I need your help.

----------
struct SvrList{
unsigned int uNum;
GameSvr svr[0]; //line A
};
---------

Once I declared a struct like this to store server list info.
It's supposed to be used like this.

----------
SvrList* pList = (SvrList*)malloc(sizeof(
SvrList) + svrNum*sizeof(GameSvr));
pList->uNum, pList->svr[0], pList->svr[1].... blabla..
---------

The vs2005 compiler gives me the "nonstandard extension used : zero-
sized array in struct/union" warning though.

I may keep my eye closed to the warning since everything looks fine.
But I don't know whether anything bad may happen to me some day due to
running environment changes(porting to different platforms, or any
other conditions).

One work-around way is to declare a one-sized array as struct member,
but I didn't see any substantial changes except no warning in this
case.

Any body give some suggestions?

El 18/08/2010 13:30, thomas escribió:
> Hi, I need your help.
>
> ----------
> struct SvrList{
> unsigned int uNum;
> GameSvr svr[0]; //line A
> };
> ---------
>
> Once I declared a struct like this to store server list info.
> It's supposed to be used like this.
>
> ----------
> SvrList* pList = (SvrList*)malloc(sizeof(
> SvrList) + svrNum*sizeof(GameSvr));
> pList->uNum, pList->svr[0], pList->svr[1].... blabla..
> ---------
>
> The vs2005 compiler gives me the "nonstandard extension used : zero-
> sized array in struct/union" warning though.
>
> I may keep my eye closed to the warning since everything looks fine.
> But I don't know whether anything bad may happen to me some day due to
> running environment changes(porting to different platforms, or any
> other conditions).
>
> One work-around way is to declare a one-sized array as struct member,
> but I didn't see any substantial changes except no warning in this
> case.
>
> Any body give some suggestions?

You can change to

struct SvrList{
unsigned int uNum;
GameSvr *svr; //line A
};

and still use array indexes.

On Aug 18, 7:33*pm, Julián Rodríguez Bajo <jrodrig...@amper.es> wrote:
> El 18/08/2010 13:30, thomas escribió:
>
>
>
> > Hi, I need your help.
>
> > ----------
> > struct SvrList{
> > * * *unsigned int uNum;
> > * * *GameSvr *svr[0]; * * * * * *//line A
> > };
> > ---------
>
> > Once I declared a struct like this to store server list info.
> > It's supposed to be used like this.
>
> > ----------
> > SvrList* pList = (SvrList*)malloc(sizeof(
> > SvrList) + svrNum*sizeof(GameSvr));
> > pList->uNum, pList->svr[0], pList->svr[1].... blabla..
> > ---------
>
> > The vs2005 compiler gives me the "nonstandard extension used : zero-
> > sized array in struct/union" warning though.
>
> > I may keep my eye closed to the warning since everything looks fine.
> > But I don't know whether anything bad may happen to me some day due to
> > running environment changes(porting to different platforms, or any
> > other conditions).
>
> > One work-around way is to declare a one-sized array as struct member,
> > but I didn't see any substantial changes except no warning in this
> > case.
>
> > Any body give some suggestions?
>
> You can change to
>
> struct SvrList{
> * * * unsigned int uNum;
> * * * GameSvr **svr; * * * * * *//line A
>
> };
>
> and still use array indexes.

Thanks, that works.
But I will call "new" two times: one to allocate memory for struct
SvrList, one for "*svr".

I really want to know whether there's any side effect if I use zero-
sized member.

thomas wrote:
> Hi, I need your help.
>
> ----------
> struct SvrList{
> unsigned int uNum;
> GameSvr svr[0]; //line A
> };
> ---------
>
> Once I declared a struct like this to store server list info.
> It's supposed to be used like this.
>
> ----------
> SvrList* pList = (SvrList*)malloc(sizeof(
> SvrList) + svrNum*sizeof(GameSvr));
> pList->uNum, pList->svr[0], pList->svr[1].... blabla..

I wouldn't call this fine. Even
pList->svr[0]
is accessing the element that is out of array's bounds, and that is UB.
How come your program is not crashing, or at least going crazy? Maybe
you are just unlucky to have a bug hidden.

> ---------
>
> The vs2005 compiler gives me the "nonstandard extension used : zero-
> sized array in struct/union" warning though.
>
> I may keep my eye closed to the warning since everything looks fine.
> But I don't know whether anything bad may happen to me some day due to
> running environment changes(porting to different platforms, or any
> other conditions).
>
> One work-around way is to declare a one-sized array as struct member,
> but I didn't see any substantial changes except no warning in this
> case.
>
> Any body give some suggestions?

Vladimir Jovic wrote:
> thomas wrote:
>> Hi, I need your help.
>>
>> ----------
>> struct SvrList{
>> unsigned int uNum;
>> GameSvr svr[0]; //line A
>> };
>> ---------
>>
>> Once I declared a struct like this to store server list info.
>> It's supposed to be used like this.
>>
>> ----------
>> SvrList* pList = (SvrList*)malloc(sizeof(
>> SvrList) + svrNum*sizeof(GameSvr));
>> pList->uNum, pList->svr[0], pList->svr[1].... blabla..
>
> I wouldn't call this fine. Even
> pList->svr[0]
> is accessing the element that is out of array's bounds, and that is UB.
> How come your program is not crashing, or at least going crazy? Maybe
> you are just unlucky to have a bug hidden.

It's an old C programmers hack. I've come across this idiom in lot's old
C code, particularly driver and os code. Microsoft Win32 is rife with it.

Jeff

Vladimir Jovic <> wrote:
> thomas wrote:
>> Hi, I need your help.
>>
>> ----------
>> struct SvrList{
>> unsigned int uNum;
>> GameSvr svr[0]; //line A
>> };
>> ---------
>>
>> Once I declared a struct like this to store server list info.
>> It's supposed to be used like this.
>>
>> ----------
>> SvrList* pList = (SvrList*)malloc(sizeof(
>> SvrList) + svrNum*sizeof(GameSvr));
>> pList->uNum, pList->svr[0], pList->svr[1].... blabla..
>
> I wouldn't call this fine. Even
> pList->svr[0]
> is accessing the element that is out of array's bounds, and that is UB.
> How come your program is not crashing, or at least going crazy?

pList->svr[0] is accessing memory allocated by the malloc() call,
hence it can't crash (well, at least if 'GameSvr' is a POD type).

Fred Zwarts <> wrote:
> You can use std::vector. A vector can have 0 or more elements.
> It also removes the need for malloc and free.

And also makes the struct something like 10 times slower to allocate
and deallocate, as well as consuming more memory.

Juha Nieminen wrote:
> Vladimir Jovic <> wrote:
>> thomas wrote:
>>> Hi, I need your help.
>>>
>>> ----------
>>> struct SvrList{
>>> unsigned int uNum;
>>> GameSvr svr[0]; //line A
>>> };
>>> ---------
>>>
>>> Once I declared a struct like this to store server list info.
>>> It's supposed to be used like this.
>>>
>>> ----------
>>> SvrList* pList = (SvrList*)malloc(sizeof(
>>> SvrList) + svrNum*sizeof(GameSvr));
>>> pList->uNum, pList->svr[0], pList->svr[1].... blabla..
>> I wouldn't call this fine. Even
>> pList->svr[0]
>> is accessing the element that is out of array's bounds, and that is UB.
>> How come your program is not crashing, or at least going crazy?
>
> pList->svr[0] is accessing memory allocated by the malloc() call,
> hence it can't crash (well, at least if 'GameSvr' is a POD type).

If the array's size is zero, how can you access even one element?
The example similar to the original example, except this one compiles :

#include <iostream>
using namespace std;
struct A
{
int a;
int b[0];
};
int main()
{
A *p = new A;

p->a = 5;
p->b[0] = 6;
p->b[1] = 7;
p->b[2] = 8;

std::cout << "p->a="<<p->a << std::endl
<< "p->b[0]="<<p->b[0] << std::endl
<< "p->b[1]="<<p->b[1] << std::endl
<< "p->b[2]="<<p->b[2] << std::endl;

delete( p );
}



And the output :

../a.out
p->a=5

p->b[0]=6

p->b[1]=7

p->b[2]=8
*** glibc detected *** ./a.out: free(): invalid next size (fast):
0x087b8008 ***
======= Backtrace: =========
/lib/libc.so.6[0x260874]
/lib/libc.so.6(cfree+0x96)[0x2628d6]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x1ba461]
../a.out(__gxx_personality_v0+0x24a)[0x8048886]
/lib/libc.so.6(__libc_start_main+0xe6)[0x2095d6]
../a.out(__gxx_personality_v0+0x35)[0x8048671]
======= Memory map: ========
00101000-001e8000 r-xp 00000000 fd:07 442834
/usr/lib/libstdc++.so.6.0.10
001e8000-001ec000 r--p 000e6000 fd:07 442834
/usr/lib/libstdc++.so.6.0.10
001ec000-001ee000 rw-p 000ea000 fd:07 442834
/usr/lib/libstdc++.so.6.0.10
001ee000-001f3000 rw-p 001ee000 00:00 0
001f3000-00356000 r-xp 00000000 fd:00 58475 /lib/libc-2.8.so
00356000-00358000 r--p 00163000 fd:00 58475 /lib/libc-2.8.so
00358000-00359000 rw-p 00165000 fd:00 58475 /lib/libc-2.8.so
00359000-0035c000 rw-p 00359000 00:00 0
00821000-0083d000 r-xp 00000000 fd:00 58474 /lib/ld-2.8.so
0083d000-0083e000 r--p 0001c000 fd:00 58474 /lib/ld-2.8.so
0083e000-0083f000 rw-p 0001d000 fd:00 58474 /lib/ld-2.8.so
00848000-00849000 r-xp 00848000 00:00 0 [vdso]
009ac000-009d3000 r-xp 00000000 fd:00 58481 /lib/libm-2.8.so
009d3000-009d4000 r--p 00026000 fd:00 58481 /lib/libm-2.8.so
009d4000-009d5000 rw-p 00027000 fd:00 58481 /lib/libm-2.8.so
00db3000-00dc0000 r-xp 00000000 fd:00 58490
/lib/libgcc_s-4.3.0-20080428.so.1
00dc0000-00dc1000 rw-p 0000c000 fd:00 58490
/lib/libgcc_s-4.3.0-20080428.so.1
08048000-08049000 r-xp 00000000 fd:09 4555963
/sandbox/vladimir/data_create/a.out
08049000-0804a000 rw-p 00000000 fd:09 4555963
/sandbox/vladimir/data_create/a.out
087b8000-087d9000 rw-p 087b8000 00:00 0 [heap]
b7f00000-b7f21000 rw-p b7f00000 00:00 0
b7f21000-b8000000 ---p b7f21000 00:00 0
b80a5000-b80a8000 rw-p b80a5000 00:00 0
b80c7000-b80c8000 rw-p b80c7000 00:00 0
bfe96000-bfeab000 rw-p bffeb000 00:00 0 [stack]
Aborted

Juha Nieminen wrote:
> Fred Zwarts <> wrote:
>> You can use std::vector. A vector can have 0 or more elements.
>> It also removes the need for malloc and free.
>
> And also makes the struct something like 10 times slower to
> allocate and deallocate, as well as consuming more memory.

Yes, but you get rid of the SvrList (which keeps size and buffer) if
you let the std::vector do the job. You don't have to dynamically
allocate the vector itself.


Bo Persson

Vladimir Jovic <> wrote in news:i4gueb$vqv$1
@news.albasani.net:

>
> If the array's size is zero, how can you access even one element?

What's your point? Why would you do that? If b were a vector, you would
get similar behavior. That is, it is just as undefined if you don't
bother to check the size of the vector before assigning data. This is a
idiom used by device drivers to return information requiring a minimum
number of allocations and a minimum number of frees. It is always used
with malloc and the size of the array is always embedded in the struct
somewhere so that you don't go out of bounds. So, to fix up your code
below.

> The example similar to the original example, except this one compiles :
>
> #include <iostream>
> using namespace std;
> struct A
> {
> int a;
int b_len;
> int b[0];
> };

A * AFactory(int sz)
{
A * p = (A *)malloc(sizeof(A) + sz * sizeof(b[0]));
p->b_len = sz;
return p
}

> int main()
> {
> A *p = new A;
A *p = AFactory(0);

>
> p->a = 5;

// We know we didn't allocate space so we wouldn't bother with
this, but...
if (p->b_len >= 3)
{
> p->b[0] = 6;
> p->b[1] = 7;
> p->b[2] = 8;
}
>
> std::cout << "p->a="<<p->a << std::endl;
for (int ix = 0; ix < p->b_len; ++ix)
std::cout << "p->b[" << ix << "] = " << p->b[ix] << std::endl;
>
free(p); // you could also have function for this, but
deallocation doesn't require additional info.

> }
>
>

I would never advocate the above as a C++ application pattern, but if you
are messing in drivers and kernel, then every clock cycle counts and
multiple heap hits can kill performance.

This is one of the places I would really like to see some sort of VLA
available (at least if it allocated memory in this fashion). The nice
thing is that it is one heap allocation and free. Rolling your own as
above is a bit of a pain. Fortunately, I haven't had to do stuff like
that in years.

joe