zero length array in nocommon

[Ruud Vlaming]

Hi,

I noticed a strange behaviour when you place a zero length array in
'nocommon'. For example, if you use something like

  const unsigned char TEST_C[0];

it compiles (assuming NO settings like -ffunction-sections -Wl,--gc-sections -Wl,--relax) to

  *(COMMON)
   COMMON    0x000000000080007e    0x23 ./src/femtoos_shared.o
             0x000000000080007e             TEST_C
             0x000000000080007e             tcb00

so indeed it takes no space. However, if you use:

  const unsigned char TEST_C[0] __attribute__ ((nocommon));

you get

   .bss      0x0000000000800062    0x1d ./src/femtoos_shared.o
             0x0000000000800076             TEST_C
             0x0000000000800077             Stack00

and now it starts taking one byte of space. It looks like it is
somehow switching back to "old C" behaviour. (I know these
listings are not entirely conclusive, but i verified it is indeed
one byte extra)

Does anybody understands this?

Ruud


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Joerg Wunsch]

Ruud Vlaming <ruud@...> wrote:

> I noticed a strange behaviour when you place a zero length array in
> 'nocommon'.

No idea why the behaviour changes, but as a note of warning: a
zero-length array is not allowed by the C standard.  No idea what you
are trying to achieve here though.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Ruud Vlaming]

On Wednesday 23 September 2009 21:14, Joerg Wunsch wrote:
> Ruud Vlaming <ruud@...> wrote:
>
> > I noticed a strange behaviour when you place a zero length array in
> > 'nocommon'.
>
> No idea why the behaviour changes, but as a note of warning: a
> zero-length array is not allowed by the C standard.  
Well, mayby not in ISO C, but certainly in GNU C:
  http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
thus at least the gcc compiler should be able to handle it :-)

> No idea what you are trying to achieve here though.
Although the link gives an example how this could be usefull,
i found a different application. I configure my projects using
preprop defines, and if a don't need an array internally, the size
calculation simply produces a zero. That way no space is taken,
and it is much easier than having if-defs around all arrays to see
if they accedently have size zero. But it seems it does not work
when they are not in the common space.

This 'quirk' of gcc does not seem to be specifically avr related
but probably we are the only one's left to care about the
spoilled byte.

Ruud.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Dave Hylands]

> This 'quirk' of gcc does not seem to be specifically avr related
> but probably we are the only one's left to care about the
> spoilled byte.

I seem to recall something (not sure if it's a language requirement or
not) about stuff needing to allocate at least one byte. This ensures
that when you take the address of one object it doesn't equal the
address of another object (which could happen if the object in fact
takes up zero bytes).

I also seem to recall that in C++ the new operator needs to allocate 1
byte, even when passed a length of zero to allocate.

--
Dave Hylands
Shuswap, BC, Canada
http://www.DaveHylands.com/


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

I used this for the exact same reason.  I really don't like seeing a lot of #if's in the code, and the zero-length array solved this problem beautifully.

That is, until I had to port the code to IAR.  That compiler does not honor zero-length arrays, so I had to add some #if's.  I came up with some macros that were helpful, but they made the code much harder to understand.  So we're back to lots of #if's in the code.

Blake

-------------- Original message from Ruud Vlaming <ruud@...>: --------------

> On Wednesday 23 September 2009 21:14, Joerg Wunsch wrote:
> > Ruud Vlaming wrote:
> >
> > > I noticed a strange behaviour when you place a zero length array in
> > > 'nocommon'.
> >
> > No idea why the behaviour changes, but as a note of warning: a
> > zero-length array is not allowed by the C standard.
> Well, mayby not in ISO C, but certainly in GNU C:
> http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> thus at least the gcc compiler should be able to handle it :-)
>
> > No idea what you are trying to achieve here though.
> Although the link gives an example how this could be usefull,
> i found a different application. I configure my projects using
> preprop defines, and if a don't need an array internally, the size
> calculation simply produces a zero. That way no space is taken,
> and it is much easier than having if-defs around all arrays to see
> if they accedently have size zero. But it seems it does not work
> when they are not in the common space.
>
> This 'quirk' of gcc does not seem to be specifically avr related
> but probably we are the only one's left to care about the
> spoilled byte.
>
> Ruud.
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> AVR-GCC-list@...
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of bleverett@...
> Sent: Wednesday, September 23, 2009 6:05 PM
> To: Ruud Vlaming
> Cc: avr-gcc-list@...
> Subject: Re: [avr-gcc-list] zero length array in nocommon
>
> I used this for the exact same reason.  I really don't like
> seeing a lot of #if's in the code, and the zero-length array
> solved this problem beautifully.
>
> That is, until I had to port the code to IAR.  That compiler
> does not honor zero-length arrays, so I had to add some
> #if's.  I came up with some macros that were helpful, but
> they made the code much harder to understand.  So we're back
> to lots of #if's in the code.

So it may be easier, but it's not standard C. This sounds a lot like the CodeVision compiler's way of setting a bit on a port: completely non-standard.

Best to stick with what is portable and just learn to read code with #ifdefs. A bit of indentation usually helps. ;-)


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Joerg Wunsch]

Ruud Vlaming <ruud@...> wrote:

>> No idea why the behaviour changes, but as a note of warning: a
>> zero-length array is not allowed by the C standard.

> Well, mayby not in ISO C, but certainly in GNU C:

I know, but I've only used it as a flexible array member in the past,
where I'd prefer the C99 way now.

In your case, I'd revert the code to the portable #ifdef.

Anyway, you're right, as long as GCC claims support for it, it ought
to work, so you might consider filing a bug report (unless there's
already one).

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[David Brown-4]

Ruud Vlaming wrote:

> On Wednesday 23 September 2009 21:14, Joerg Wunsch wrote:
>> Ruud Vlaming <ruud@...> wrote:
>>
>>> I noticed a strange behaviour when you place a zero length array in
>>> 'nocommon'.
>> No idea why the behaviour changes, but as a note of warning: a
>> zero-length array is not allowed by the C standard.  
> Well, mayby not in ISO C, but certainly in GNU C:
>   http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> thus at least the gcc compiler should be able to handle it :-)
>
>> No idea what you are trying to achieve here though.
> Although the link gives an example how this could be usefull,
> i found a different application. I configure my projects using
> preprop defines, and if a don't need an array internally, the size
> calculation simply produces a zero. That way no space is taken,
> and it is much easier than having if-defs around all arrays to see
> if they accedently have size zero. But it seems it does not work
> when they are not in the common space.
>
> This 'quirk' of gcc does not seem to be specifically avr related
> but probably we are the only one's left to care about the
> spoilled byte.
>
> Ruud.

As shown by the link you gave, zero-length arrays are only really valid
when they are the last element in a struct (they can be very useful there).

The problem boils down to that C requires every declared object to have
a unique address.  Theoretically, the compiler/linker could do this by
aliasing the zero-length array into the middle of something else that is
otherwise not addressed by the program.  But in practice, it is done by
allocating at least 1 byte to zero-length data.

The same issue occurs with C++ classes with no non-static data, which
can sometimes be useful.



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Ruud Vlaming]

On Thursday 24 September 2009 04:14, you wrote:
> ... and just learn to read code with #ifdefs. A bit of indentation usually helps. ;-)

Surely you're joking right? ;-) My work on Femto OS was subject of a research
paper [1] which discussed that heavy use of preproccessor directives is
not necessarily bad for the quality of the code.

Ruud

[1] Kaestner & Apel, Journal of Object Technology, Vol 8, No 6, 2009


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Ruud Vlaming]

On Thursday 24 September 2009 06:20, Joerg Wunsch wrote:
> Ruud Vlaming <ruud@...> wrote:

> In your case, I'd revert the code to the portable #ifdef.
I did. No choice right :-(
>
> Anyway, you're right, as long as GCC claims support for it, it ought
> to work, so you might consider filing a bug report (unless there's
> already one).
I think about it. But this will be a very low priority issue i guess. Not
only for them (who is using this anyway?), but also for me (it does
not pay my bills, which is becomming an urgent matter for an
entrepeneur like me in these difficult times ... )

R.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Ruud Vlaming]

On Thursday 24 September 2009 10:51, David Brown wrote:

> As shown by the link you gave, zero-length arrays are only really valid
> when they are the last element in a struct (they can be very useful there).
I cannot read any restrictions on the use of zero-length arrays. It states
"Zero-length arrays are allowed in GNU C" Period. And then an example
is discussed about how it can be usefull.
 
> The problem boils down to that C requires every declared object to have
> a unique address.  Theoretically, the compiler/linker could do this by
> aliasing the zero-length array into the middle of something else that is
> otherwise not addressed by the program.  But in practice, it is done by
> allocating at least 1 byte to zero-length data.
Maybe true, but contraditory to my findings with gcc. When i keep it
in the common (as is done automatically) gcc has no problems
whatsoever with the zero length array, and indeed it address may
overlap with other variables. It is up to the programmer i guess not
to misuse this 'feature'.

My question was, why is there a difference in behaviour, and i
hoped somebody could shine some light on this. But maybe
it is like J"org says, just a bug.

R.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[David Brown-4]

Ruud Vlaming wrote:
> On Thursday 24 September 2009 10:51, David Brown wrote:
>
>> As shown by the link you gave, zero-length arrays are only really valid
>> when they are the last element in a struct (they can be very useful there).
> I cannot read any restrictions on the use of zero-length arrays. It states
> "Zero-length arrays are allowed in GNU C" Period. And then an example
> is discussed about how it can be usefull.
>  

You are right - it is only flexible arrays (no length at all) that need
to be at the end of a struct.  However, zero-length arrays are close to
the same thing as far as the compiler is concerned - they are only
actually /useful/ at the end of a struct.

>> The problem boils down to that C requires every declared object to have
>> a unique address.  Theoretically, the compiler/linker could do this by
>> aliasing the zero-length array into the middle of something else that is
>> otherwise not addressed by the program.  But in practice, it is done by
>> allocating at least 1 byte to zero-length data.
> Maybe true, but contraditory to my findings with gcc. When i keep it
> in the common (as is done automatically) gcc has no problems
> whatsoever with the zero length array, and indeed it address may
> overlap with other variables. It is up to the programmer i guess not
> to misuse this 'feature'.
>
> My question was, why is there a difference in behaviour, and i
> hoped somebody could shine some light on this. But maybe
> it is like J"org says, just a bug.
>
> R.

I think it is more likely that the bug is that the zero-length arrays
take no space when allocated in "common", rather than that they /do/
take space when allocated elsewhere.  So perhaps you should not protest
too loudly :-)

I suppose that since the standards don't allow zero-length arrays, I
their semantics are not very well defined.



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of Ruud Vlaming
> Sent: Thursday, September 24, 2009 3:45 AM
> To: avr-gcc-list@...
> Subject: Re: [avr-gcc-list] Re: zero length array in nocommon
>
> My question was, why is there a difference in behaviour, and i
> hoped somebody could shine some light on this. But maybe
> it is like J"org says, just a bug.

You're probably the first to discover such a difference. At least on the AVR toolchain anyway.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of Ruud Vlaming
> Sent: Thursday, September 24, 2009 3:45 AM
> To: avr-gcc-list@...
> Subject: Re: [avr-gcc-list] zero length array in nocommon
>
> On Thursday 24 September 2009 04:14, you wrote:
> > ... and just learn to read code with #ifdefs. A bit of
> indentation usually helps. ;-)
>
> Surely you're joking right? ;-) My work on Femto OS was
> subject of a research
> paper [1] which discussed that heavy use of preproccessor
> directives is
> not necessarily bad for the quality of the code.
>
> Ruud
>
> [1] Kaestner & Apel, Journal of Object Technology, Vol 8, No 6, 2009

Sorry, I haven't seen that paper before.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[David Brown-4]

Weddington, Eric wrote:

>
>
>> -----Original Message----- From:
>> avr-gcc-list-bounces+eric.weddington=atmel.com@...
>> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu. org]
>> On Behalf Of Ruud Vlaming Sent: Thursday, September 24, 2009 3:45
>> AM To: avr-gcc-list@... Subject: Re: [avr-gcc-list] Re: zero
>> length array in nocommon
>>
>> My question was, why is there a difference in behaviour, and i
>> hoped somebody could shine some light on this. But maybe it is like
>> J"org says, just a bug.
>
> You're probably the first to discover such a difference. At least on
> the AVR toolchain anyway.

A brief test shows that the same difference exists when compiling with
gcc for the ColdFire (I don't remember the gcc version off-hand).  It is
therefore not an avr-gcc specific feature.



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of David Brown
> Sent: Thursday, September 24, 2009 8:47 AM
> To: avr-gcc-list@...
> Subject: [avr-gcc-list] Re: zero length array in nocommon
>
> Weddington, Eric wrote:
> >
> >
> >> -----Original Message----- From:
> >> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> >> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu. org]
> >> On Behalf Of Ruud Vlaming Sent: Thursday, September 24, 2009 3:45
> >> AM To: avr-gcc-list@... Subject: Re: [avr-gcc-list] Re: zero
> >> length array in nocommon
> >>
> >> My question was, why is there a difference in behaviour, and i
> >> hoped somebody could shine some light on this. But maybe it is like
> >> J"org says, just a bug.
> >
> > You're probably the first to discover such a difference. At least on
> > the AVR toolchain anyway.
>
> A brief test shows that the same difference exists when
> compiling with
> gcc for the ColdFire (I don't remember the gcc version
> off-hand).  It is
> therefore not an avr-gcc specific feature.

Then I would hazard a guess and say that it's probably NOT a bug. I know that the Coldfire port is very well maintained these days, and if it were a bug, then it probably would've been fixed already.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Joerg Wunsch]

David Brown <david@...> wrote:

> A brief test shows that the same difference exists when compiling
> with gcc for the ColdFire (I don't remember the gcc version
> off-hand).

It can also be seen when compiling for the i386.  It's really within
the generic part of GCC, no doubt.

I guess it's just nobody really noticed it before.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[David Brown-40]

Weddington, Eric wrote:

>
>> Weddington, Eric wrote:
>>>
>>>> -----Original Message----- From:
>>>> avr-gcc-list-bounces+eric.weddington=atmel.com@...
>>>> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
>>>> org] On Behalf Of Ruud Vlaming Sent: Thursday, September 24,
>>>> 2009 3:45 AM To: avr-gcc-list@... Subject: Re:
>>>> [avr-gcc-list] Re: zero length array in nocommon
>>>>
>>>> My question was, why is there a difference in behaviour, and i
>>>>  hoped somebody could shine some light on this. But maybe it is
>>>> like J"org says, just a bug.
>>> You're probably the first to discover such a difference. At least
>>> on the AVR toolchain anyway.
>> A brief test shows that the same difference exists when compiling
>> with gcc for the ColdFire (I don't remember the gcc version
>> off-hand).  It is therefore not an avr-gcc specific feature.
>
> Then I would hazard a guess and say that it's probably NOT a bug. I
> know that the Coldfire port is very well maintained these days, and
> if it were a bug, then it probably would've been fixed already.

My ColdFire gcc is from CodeSourcery - it is not the latest version, but
it is from the right people.

It might not count strictly as a bug, since I don't think there is any
clear definition of how much space a stand-alone zero length array
should take.  Since there is nothing you can actually /do/ with such
arrays, they are not going to be used much - it is quite easy to believe
that no one has noticed this behaviour in any version of gcc for any target.



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of David Brown
> Sent: Thursday, September 24, 2009 3:02 PM
> To: avr-gcc-list@...
> Subject: [avr-gcc-list] Re: zero length array in nocommon
>
>
> My ColdFire gcc is from CodeSourcery - it is not the latest
> version, but
> it is from the right people.
>
> It might not count strictly as a bug, since I don't think
> there is any
> clear definition of how much space a stand-alone zero length array
> should take.  Since there is nothing you can actually /do/ with such
> arrays, they are not going to be used much - it is quite easy
> to believe
> that no one has noticed this behaviour in any version of gcc
> for any target.

I'm on the gcc list. I would be very surprised if no one has noticed this behaviour, especially the CodeSourcery folks. Since it hasn't been brought up before, this is why I figure it is not a bug.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Joerg Wunsch]

"Weddington, Eric" <Eric.Weddington@...> wrote:

> I'm on the gcc list. I would be very surprised if no one has noticed
> this behaviour, especially the CodeSourcery folks. Since it hasn't
> been brought up before, this is why I figure it is not a bug.

I don't accept that reasoning :), just because nobody notices
something doesn't mean it isn't a bug.  Remember, this is a
combination of two rarely used options: zero-length arrays outside
their main purpose (to emulate a variable-length array at the end of a
struct before C99 standardized them), and global uninitialized data
outside a common section.  Even then, someone would have to really
notice that the supposed to be zero-length variable has been assigned
a length of > 0.

Anyway, I tried to follow the code path in GCC, but cannot really make
my way through all of the variable allocation stuff.  common and
nocommon variables go a very different path beyond a certain point
when generating the assembly code.  It seems likely to me that it is
purely intentional that there is some kind of minimal variable size
emitted in nocommon mode.  In order to really know, the question would
have to be asked on the GCC developers list, in the hope to find
someone more acquainted with how all the variable allocation does
work.

I still think even if it's not a bug but an artifact of the way
variable allocation is done, at the very least it lacks a clear
statement in the documentation.  That alone might warrant a bug
report.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list