Assuming there are not many of these, the
easiest thing to do is fix the nhc98 code.
Figure out what the field after the label is
and take that address instead.
Alternately, you can use a Plan 9 extension
to defeat the gcc extension. Wherever it says
struct Foo{
...
uchar startLabel[];
Hi all
both option did not solve my lost pointer problem. I am still
verifying if it is due to something unrelated to zero length arrays
option1
unsigned foo[1];
#define startLabel (&foo[1])
option 2
static unsigned startLabel0;
static unsigned startLabel[] = &startLabel0
thanks
fernan
--
h
On Wed, 23 Sep 2009 02:49:44 +0800 Fernan Bolando
wrote:
> Hi all
>
> nhc98 uses a few of
>
> static unsigned startLabel[]={};
>
> which is a zero length array. It appears that it uses this as
> reference to calculate the correct pointer for a bytecode.
>
> pcc does not allow this since zero
> pcc does not allow this since zero lenth array is another gcc
> extension. I tried declaring it as
>
> static unsigned startLabel[];
>
> The resulting bytecode can then be compiled however it will only
> crash. I traced it a pointer that tries to read an unallocated section
> in memory.
the on
Hi all
nhc98 uses a few of
static unsigned startLabel[]={};
which is a zero length array. It appears that it uses this as
reference to calculate the correct pointer for a bytecode.
pcc does not allow this since zero lenth array is another gcc
extension. I tried declaring it as
static unsigned
