Array has incomplete element type. GCC bug?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • arcadio

    Array has incomplete element type. GCC bug?

    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_ou tsquare(unsigne d char [][], const int, const int,
    const int, const int y);

    /* From the source: ERROR: Array type has incomplete element type */
    void grphcs_enhnc_ou tsquare(unsigne d 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_MIN UTIAE ],
    int ycol[ MAX_BOZORTH_MIN UTIAE ],
    int thetacol[ MAX_BOZORTH_MIN UTIAE ],

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


    Can anyone shed some light?

    Thanks in advance


    - Arcadio
  • Lew Pitcher

    #2
    Re: Array has incomplete element type. GCC bug?

    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_MIN UTIAE ],
    int ycol[ MAX_BOZORTH_MIN UTIAE ],
    int thetacol[ MAX_BOZORTH_MIN UTIAE ],
    >
    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. ------


    Comment

    • Richard Heathfield

      #3
      Re: Array has incomplete element type. GCC bug?

      arcadio said:

      <snip>
      However, I cannot see
      where the array types are incomplete here:
      >
      /* From the header */
      void grphcs_enhnc_ou tsquare(unsigne d 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.

      [1]...and the second instance, and the third...

      --
      Richard Heathfield <http://www.cpax.org.uk >
      Email: -http://www. +rjh@
      Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
      "Usenet is a strange place" - dmr 29 July 1999

      Comment

      • pete

        #4
        Re: Array has incomplete element type. GCC bug?

        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.
        >
        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_ou tsquare(unsigne d char [][], const int, const int,
        const int, const int y);
        >
        /* From the source: ERROR: Array type has incomplete element type */
        void grphcs_enhnc_ou tsquare(unsigne d 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_MIN UTIAE ],
        int ycol[ MAX_BOZORTH_MIN UTIAE ],
        int thetacol[ MAX_BOZORTH_MIN UTIAE ],
        >
        int * ncomparisons,
        int cols[][ COLS_SIZE_2 ],
        int * colptrs[]
        )
        { /* ... */ }
        >
        >
        Can anyone shed some light?
        >
        Thanks in advance

        extern void
        bz_comp(int, int [], int [], int [], int *,
        int [][COLS_SIZE_2], int *[]);

        --
        pete

        Comment

        • arcadio

          #5
          Re: Array has incomplete element type. GCC bug?

          On 23 jun, 17:59, Lew Pitcher <lpitc...@teksa vvy.comwrote:
          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_MIN UTIAE ],
          int ycol[     MAX_BOZORTH_MIN UTIAE ],
          int thetacol[ MAX_BOZORTH_MIN UTIAE ],
          >
          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.digital freehold.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_ou tsquare(unsigne d 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_ou tsquare(unsigne d 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_MIN UTIAE ],
          int ycol[ MAX_BOZORTH_MIN UTIAE ],
          int thetacol[ MAX_BOZORTH_MIN UTIAE ],

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

          Comment

          • Kenny McCormack

            #6
            Re: Array has incomplete element type. GCC bug?

            In article <6didnVOmF44UVc LVnZ2dnUVZ8qvin Z2d@bt.com>,
            Richard Heathfield <rjh@see.sig.in validwrote:
            >arcadio said:
            >
            ><snip>
            >
            >However, I cannot see
            >where the array types are incomplete here:
            >>
            >/* From the header */
            >void grphcs_enhnc_ou tsquare(unsigne d 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?

            Comment

            • Harald van =?UTF-8?b?RMSzaw==?=

              #7
              Re: Array has incomplete element type. GCC bug?

              On Mon, 23 Jun 2008 19:17:17 +0000, Kenny McCormack wrote:
              In article <6didnVOmF44UVc LVnZ2dnUVZ8qvin Z2d@bt.com>, Richard Heathfield
              <rjh@see.sig.in validwrote:
              >>arcadio said:
              >>
              >><snip>
              >>
              >>However, I cannot see
              >>where the array types are incomplete here:
              >>>
              >>/* From the header */
              >>void grphcs_enhnc_ou tsquare(unsigne d 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_ou tsquare(unsigne d char (*)[], ...);
              void grphcs_enhnc_ou tsquare(unsigne d 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.

              Comment

              • Walter Roberson

                #8
                Re: [semi-OT] obfuscation (was Re: Array has incomplete element type. GCC bug?)

                In article <6cff5dF3fdpsdU 1@mid.individua l.net>,
                blmblm@myrealbo x.com <blmblm@myrealb ox.comwrote:
                >In article <8653b075-7dd9-4bc5-bbd1-e6b899691874@k3 7g2000hsf.googl egroups.com>,
                >arcadio <arcadiorubioga rcia@gmail.comw rote:
                >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

                Comment

                • blmblm@myrealbox.com

                  #9
                  Re: [semi-OT] obfuscation (was Re: Array has incomplete element type. GCC bug?)

                  In article <g3u17t$d4f$1@c anopus.cc.umani toba.ca>,
                  Walter Roberson <roberson@ibd.n rc-cnrc.gc.cawrote :
                  In article <6cff5dF3fdpsdU 1@mid.individua l.net>,
                  blmblm@myrealbo x.com <blmblm@myrealb ox.comwrote:
                  In article <8653b075-7dd9-4bc5-bbd1-e6b899691874@k3 7g2000hsf.googl egroups.com>,
                  arcadio <arcadiorubioga rcia@gmail.comw rote:
                  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
                  Huh! The entry in the online Merriam-Webster

                  to throw into shadow : darken; to make obscure : hide; to make more difficult to understand… See the full definition


                  doesn't seem to give this meaning. But okay, I've learned
                  something!

                  (If it matters, my post was meant to be possibly-useful information
                  for someone for whom English might not be a first language. But
                  maybe he(?) knows it better than I do. Sort of a :-). )

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

                  Comment

                  • Richard Heathfield

                    #10
                    Re: [semi-OT] obfuscation (was Re: Array has incomplete element type. GCC bug?)

                    blmblm@myrealbo x.com said:
                    In article <g3u17t$d4f$1@c anopus.cc.umani toba.ca>,
                    Walter Roberson <roberson@ibd.n rc-cnrc.gc.cawrote :
                    >In article <6cff5dF3fdpsdU 1@mid.individua l.net>,
                    >blmblm@myrealbo x.com <blmblm@myrealb ox.comwrote:
                    <snip>
                    >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:
                    >>
                    [...]
                    >
                    Huh! The entry in the online Merriam-Webster
                    >
                    to throw into shadow : darken; to make obscure : hide; to make more difficult to understand… See the full definition

                    >
                    doesn't seem to give this meaning. But okay, I've learned
                    something!
                    Yes, you've learned that you get the dictionary you pay for. :-)

                    --
                    Richard Heathfield <http://www.cpax.org.uk >
                    Email: -http://www. +rjh@
                    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
                    "Usenet is a strange place" - dmr 29 July 1999

                    Comment

                    • blmblm@myrealbox.com

                      #11
                      Re: [OT] obfuscation (was Re: Array has incomplete element type. GCC bug?)

                      In article <4YidnUmxqKoWLP _VnZ2dnUVZ8sbin Z2d@bt.com>,
                      Richard Heathfield <rjh@see.sig.in validwrote:
                      blmblm@myrealbo x.com said:
                      >
                      In article <g3u17t$d4f$1@c anopus.cc.umani toba.ca>,
                      Walter Roberson <roberson@ibd.n rc-cnrc.gc.cawrote :
                      In article <6cff5dF3fdpsdU 1@mid.individua l.net>,
                      blmblm@myrealbo x.com <blmblm@myrealb ox.comwrote:
                      >
                      <snip>
                      >
                      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:
                      [ .... ]
                      Huh! The entry in the online Merriam-Webster

                      to throw into shadow : darken; to make obscure : hide; to make more difficult to understand… See the full definition


                      doesn't seem to give this meaning. But okay, I've learned
                      something!
                      >
                      Yes, you've learned that you get the dictionary you pay for. :-)
                      :-), yes, but --

                      It might also have to do with the two dictionaries just
                      having different slants in general. I haven't done a thorough
                      comparison, but my impression based on a few other experiences
                      using both dictionaries is that the OED is somewhat more
                      traditional/prescriptivist than Merriam-Webster, and that there
                      also may be {left/right}-pondian differences.

                      I believe it's time to change the subject line from "semi-OT"
                      to "OT", as well as just letting this go ....

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

                      Comment

                      Working...