«

Hi everyone,

I'm currently struggling to compile a large piece of legacy code. GCC
3.3 compiles it without complaining, but GCC 4.2.3 (the default in
Debian) refuses it and signals "several array has incomplete element
type" errors.

I know that since 4.0 or so, GCC is less forgiving and does not accept
any arrays of incomplete type (see http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html).
However, I cannot see where the array types are incomplete here:

/* From the header */
void grphcs_enhnc_outsquare(unsigned char [][], const int, const int,
const int, const int y);

/* From the source: ERROR: Array type has incomplete element type */
void grphcs_enhnc_outsquare(unsigned char outsquare[][], const int w,
const int h, const int x, const int y)
{ /* ... */ }

/* From another header */
extern void bz_comp(int, int [], int [], int [], int *, int [][], int
*[]);

/* From the corresponding source: ERROR: Array type has incomplete
element type */
void bz_comp(
int npoints,
int xcol[ MAX_BOZORTH_MINUTIAE ],
int ycol[ MAX_BOZORTH_MINUTIAE ],
int thetacol[ MAX_BOZORTH_MINUTIAE ],

int * ncomparisons,
int cols[][ COLS_SIZE_2 ],
int * colptrs[]
)
{ /* ... */ }


Can anyone shed some light?

Thanks in advance


- Arcadio

In comp.lang.c, arcadio wrote:

> Hi everyone,
>
> I'm currently struggling to compile a large piece of legacy code. GCC
> 3.3 compiles it without complaining, but GCC 4.2.3 (the default in
> Debian) refuses it and signals "several array has incomplete element
> type" errors.
[snip]
> /* From the corresponding source: ERROR: Array type has incomplete
> element type */
> void bz_comp(
> int npoints,
> int xcol[ MAX_BOZORTH_MINUTIAE ],
> int ycol[ MAX_BOZORTH_MINUTIAE ],
> int thetacol[ MAX_BOZORTH_MINUTIAE ],
>
> int * ncomparisons,
> int cols[][ COLS_SIZE_2 ],

How many cols elements are in this array? How can the compiler determine
that number?

> int * colptrs[]
> )
> { /* ... */ }
>
>
> Can anyone shed some light?
>
> Thanks in advance
>
>
> - Arcadio

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

Thanks, I was quite obfuscated with the example shown in the GCC
forum, and didn't realize that an two-dimensional array needs the
column size in order to be considered a complete type.

In relation to the subject, I recognize that it was a bit hard to
blame GCC, especially because the code smelled wrong. The code i'm
showing isn't mine, it's from a Federal Agency, so I don't have any
problem in recognizing it's wrong.

And I've already reported 2 bugs to two different compilers (AspectJ
and ScalaC), so it's not that rare.

Thanks, I was quite obfuscated with the example shown in the GCC
forum, and didn't realize that an two-dimensional array needs the
column size in order to be considered a complete type.

In relation to the subject, I recognize that it was a bit hard to
blame GCC, especially because the code smelled wrong. The code i'm
showing isn't mine, it's from a Federal Agency, so I don't have any
problem in recognizing it's wrong.

And I've already reported 2 bugs to two different compilers (AspectJ
and ScalaC), so it's not that rare.

On 23 jun, 17:59, Lew Pitcher <lpitc...@teksavvy.com> wrote:
> In comp.lang.c, arcadio wrote:
> > Hi everyone,
>
> > I'm currently struggling to compile a large piece of legacy code. GCC
> > 3.3 compiles it without complaining, but GCC 4.2.3 (the default in
> > Debian) refuses it and signals "several array has incomplete element
> > type" errors.
> [snip]
> > /* From the corresponding source: ERROR: Array type has incomplete
> > element type */
> > void bz_comp(
> > int npoints,
> > int xcol[ * * MAX_BOZORTH_MINUTIAE ],
> > int ycol[ * * MAX_BOZORTH_MINUTIAE ],
> > int thetacol[ MAX_BOZORTH_MINUTIAE ],
>
> > int * ncomparisons,
> > int cols[][ COLS_SIZE_2 ],
>
> How many cols elements are in this array? How can the compiler determine
> that number?
>
> > int * colptrs[]
> > )
> > { /* ... */ }
>
> > Can anyone shed some light?
>
> > Thanks in advance
>
> > - Arcadio
>
> --
> Lew Pitcher
>
> Master Codewright & JOAT-in-training | Registered Linux User #112576http://pitcher.digitalfreehold.ca/* | GPG public key available by request
> ---------- * * *Slackware - Because I know what I'm doing. * * * * *------

The error is not there, it's:

/* From the header */
void grphcs_enhnc_outsquare(unsigned char **, const int, const int,
<-- transform into pointers
const int, const int y);

/* From the source: ERROR: Array type has incomplete element type */
void grphcs_enhnc_outsquare(unsigned char **outsquare, const int w,
<-- transform into pointers
const int h, const int x, const int y)
{ /* ... */ }

/* From another header */
extern void bz_comp(int, int [], int [], int [], int *, int []
[COLS_SIZE_2], int <- constant needed
*[]);

/* From the corresponding source: ERROR: Array type has incomplete
element type */
void bz_comp(
int npoints,
int xcol[ MAX_BOZORTH_MINUTIAE ],
int ycol[ MAX_BOZORTH_MINUTIAE ],
int thetacol[ MAX_BOZORTH_MINUTIAE ],

int * ncomparisons,
int cols[][ COLS_SIZE_2 ],
int * colptrs[]
)
{ /* ... */ }

On Jun 23, 9:28*am, arcadio <arcadiorubiogar...@gmail.com> wrote:
> Thanks, I was quite obfuscated with the example shown in the GCC
> forum, and didn't realize that an two-dimensional array needs the
> column size in order to be considered a complete type.

C has only one-dimensional arrays; two-dimensional arrays are
simulated by declaring an array whose elements are arrays. The element
type of an array must be a complete type, because the pointer
arithmetic needed for addressing the elements is impossible without
knowing the element size, whereas the size of an incomplete type is
unknown. An array declaration which doesn't specify a number of
elements is an incomplete type. Hence, you cannot declare an array of
such arrays.

In article <>,
Richard Heathfield <> wrote:
>arcadio said:
>
><snip>
>
>> However, I cannot see
>> where the array types are incomplete here:
>>
>> /* From the header */
>> void grphcs_enhnc_outsquare(unsigned char [][]
> ^^^^
>Right here.
>
>Regarding your subject line, "Array has incomplete element type. GCC bug?",
>it is generally wisest in the first instance[1] to assume that the bug is
>in your code unless you can demonstrate from the Standard that your code
>is correct.

While I agree with the sentiment here (including the footnote(s)), the
salient fact here is that OP says it worked (compiled) with the earlier
versions of GCC. Now, assuming he isn't mistaken about that, the fact
is that you can standards-jockey it all you want, it ain't gonna mean
much. Believe me, if TPTB (the ones who are paying the bills) know that
it worked before and it doesn't work now, then, for all practical
purposes, it is a bug (in the new version) - and no amount of
standards-jockeying is going to change that fact.

Or, to put it a little bit more charitably, OP's post can (and should)
be interpreted as: It worked before; it doesn't work now; is there a
workaround?

On Mon, 23 Jun 2008 19:17:17 +0000, Kenny McCormack wrote:
> In article <>, Richard Heathfield
> <> wrote:
>>arcadio said:
>>
>><snip>
>>
>>> However, I cannot see
>>> where the array types are incomplete here:
>>>
>>> /* From the header */
>>> void grphcs_enhnc_outsquare(unsigned char [][]
>> ^^^^
>>Right here.
> [...]
> Or, to put it a little bit more charitably, OP's post can (and should)
> be interpreted as: It worked before; it doesn't work now; is there a
> workaround?

Sure: declare a pointer to an array of unsigned char of unknown length.

void grphcs_enhnc_outsquare(unsigned char (*)[], ...);
void grphcs_enhnc_outsquare(unsigned char (*outsquare)[], ...) {
...
}

This is what the declaration meant with those older versions of GCC, and
what it would mean in standard C if it weren't specifically disallowed,
anyway.

I'd be surprised to find a sensible use for this type of declaration,
though. It's valid and compiles, but all the other problems of
unsigned char [][] remain, so it would still be good to find a better type
to use.

In article <8653b075-7dd9-4bc5-bbd1->,
arcadio <> wrote:
> Thanks, I was quite obfuscated

Point of English usage: Can one speak of a person being
obfuscated, or is it the code that's (possibly) obfuscated,
and the person confused by it?

> with the example shown in the GCC
> forum, and didn't realize that an two-dimensional array needs the
> column size in order to be considered a complete type.

[ snip ]

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.

In article <>,
<> wrote:
>In article <8653b075-7dd9-4bc5-bbd1->,
>arcadio <> wrote:
>> Thanks, I was quite obfuscated

>Point of English usage: Can one speak of a person being
>obfuscated,

Yes. OED has a secondary meaning that makes it clear that it can
apply to a person:

2. Of a person or his or her faculties: confused, bewildered;
amazed, flabbergasted (obs.); (U.S. slang) spec. befuddled with
alcohol, intoxicated (now rare).

There are a few examples given, such as

1860 `G. ELIOT' Mill on Floss I. I. vii. 125 As for uncle Pullet, he
could hardly have been more thoroughly obfuscated if Mr Tulliver had
said that he was going to send Tom to the Lord Chancellor.
--
"[I]t lacks context, and may or may not make sense."
-- Walter J. Phillips