Questions on incomplete structure type

Discussion in 'C Programming' started by Luca Forlizzi, Nov 5, 2010.

  1. Hello,

    while studying incomplete types, I wrote the below example
    containing, I think,
    several undef. behaviors. Trying it with two different compilers I
    find out
    that expressions that, in my opinion, are all undef. b. for the same
    reason,
    produce non uniform translations (I used -std=c99 -pedantic-errors -
    Wall for gcc).

    I have the following questions:
    1)Am I right that all the 8 expressions casted to void are undef.b.
    per 6.3.2.1 p.2
    2) gcc prints "error: dereferencing pointer to incomplete type"
    while trying
    to translate
    (void) *ps;
    Does the standard forbids to dereference a pointer to an
    incomplete type?
    I was unable to find such a prohibition, moreover gcc silently
    accepts
    dereferencing a pointer to an incomplete array type. In my
    opinion the
    error message is misleading regading the nature of the error.

    /*------------------ EXAMPLE --------------------*/

    /* declaration of an external variabile of incomplete type; later
    type is completed and variable defined */
    struct S external_s;

    /* tentative definition of a variable with incomplete type;
    later type is completed and the tentative def becomes a definition
    (the variable is implicitly initialized to {0}) */
    struct S tentative_s;

    int main(void) {

    /* pointers to the incomplete structure type */
    struct S *ps, *qs;

    /* declaration of functions returning an incomplete structure type */
    struct S hht(void);
    struct S hhe(void);


    ps = &tentative_s;
    qs = &external_s;

    /* all following statements are (discarded) computation of an
    expression
    having an incomplete structure type.
    Are they all undef.b. per 6.3.2.1 p.2 ?
    */

    /* gcc emits diagnostics, vbcc silently accepts them */
    (void) hht();
    (void) hhe();

    /* both gcc and vbcc emit diagnostics */
    (void) *ps;
    (void) *qs;

    /* gcc silently accepts them, vbcc emits diagnostics */
    (void) * &tentative_s;
    (void) * &external_s;

    /* both gcc and vbcc silently accept them */
    (void) tentative_s;
    (void) external_s;

    return 0;
    }

    /* declaration that completes the structure type and defines
    external_s */
    struct S { float a; int b, c; } external_s = { 1.1, 2, 3, };

    /* functions returning the here-complete structure type */
    struct S hht(void) {

    return tentative_s;
    }

    struct S hhe(void) {

    return external_s;
    }
     
    Luca Forlizzi, Nov 5, 2010
    #1
    1. Advertising

  2. On Fri, 5 Nov 2010 08:41:24 -0700 (PDT), Luca Forlizzi
    <> wrote:

    >Hello,
    >
    > while studying incomplete types, I wrote the below example
    >containing, I think,
    > several undef. behaviors. Trying it with two different compilers I
    >find out
    > that expressions that, in my opinion, are all undef. b. for the same
    >reason,
    > produce non uniform translations (I used -std=c99 -pedantic-errors -
    >Wall for gcc).
    >
    > I have the following questions:
    > 1)Am I right that all the 8 expressions casted to void are undef.b.
    >per 6.3.2.1 p.2


    There is a slight difference between constraint violations and
    undefined behavior. The former leads to the latter but there are
    other causes of undefined behavior.

    > 2) gcc prints "error: dereferencing pointer to incomplete type"
    >while trying
    > to translate
    > (void) *ps;
    > Does the standard forbids to dereference a pointer to an
    >incomplete type?


    There is footnote 36 which says an incomplete type is not an object.
    6.5.3.2-4 defines the result of * operator only if it points to a
    function or to an object. Your code seems to be a constraint
    violation.

    > I was unable to find such a prohibition, moreover gcc silently
    >accepts
    > dereferencing a pointer to an incomplete array type. In my
    >opinion the


    Show the code. Even if gcc is wrong, it doesn't change the language
    spec.

    > error message is misleading regading the nature of the error.


    Based on 6.5.3.2-4, it seems almost letter perfect, if a little terse.

    >
    > /*------------------ EXAMPLE --------------------*/
    >
    > /* declaration of an external variabile of incomplete type; later
    > type is completed and variable defined */
    >struct S external_s;
    >
    >/* tentative definition of a variable with incomplete type;
    > later type is completed and the tentative def becomes a definition
    > (the variable is implicitly initialized to {0}) */
    >struct S tentative_s;
    >
    >int main(void) {
    >
    > /* pointers to the incomplete structure type */
    > struct S *ps, *qs;
    >
    > /* declaration of functions returning an incomplete structure type */
    > struct S hht(void);
    > struct S hhe(void);


    6.9.1-3 says the return type must be void or an object type. Footnote
    36 says incomplete types are not objects. This is a constraint
    violation.

    >
    >
    > ps = &tentative_s;
    > qs = &external_s;
    >
    > /* all following statements are (discarded) computation of an
    >expression
    > having an incomplete structure type.
    > Are they all undef.b. per 6.3.2.1 p.2 ?
    > */
    >
    > /* gcc emits diagnostics, vbcc silently accepts them */
    > (void) hht();
    > (void) hhe();
    >
    > /* both gcc and vbcc emit diagnostics */
    > (void) *ps;
    > (void) *qs;
    >
    > /* gcc silently accepts them, vbcc emits diagnostics */
    > (void) * &tentative_s;
    > (void) * &external_s;
    >
    > /* both gcc and vbcc silently accept them */
    > (void) tentative_s;
    > (void) external_s;
    >
    > return 0;
    >}
    >
    >/* declaration that completes the structure type and defines
    >external_s */
    >struct S { float a; int b, c; } external_s = { 1.1, 2, 3, };
    >
    >/* functions returning the here-complete structure type */
    >struct S hht(void) {
    >
    > return tentative_s;
    >}
    >
    >struct S hhe(void) {
    >
    > return external_s;
    >}


    --
    Remove del for email
     
    Barry Schwarz, Nov 5, 2010
    #2
    1. Advertising

  3. Hi Barry

    On 5 Nov, 18:05, Barry Schwarz <> wrote:
    > On Fri, 5 Nov 2010 08:41:24 -0700 (PDT), Luca Forlizzi


    > >Wall for gcc).

    >
    > >  I have the following questions:
    > >  1)Am I right that all the 8 expressions casted to void are undef.b.
    > >per 6.3.2.1 p.2

    >
    > There is a slight difference between constraint violations and
    > undefined behavior.  The former leads to the latter but there are
    > other causes of undefined behavior.


    yes, but I don't understand how this answer my question.

    > >    Does the standard forbids to dereference a pointer to an
    > >incomplete type?

    >
    > There is footnote 36 which says an incomplete type is not an object.
    > 6.5.3.2-4 defines the result of * operator only if it points to a
    > function or to an object.  Your code seems to be a constraint
    > violation.


    mmmhhh... footnote 36 says that an object *type* is not an incomplete
    type.
    In my code * is applied to pointers which actually refer to objects.
    It's only that the objects have an incomplete type


    > Show the code.  Even if gcc is wrong, it doesn't change the language
    > spec.


    extern int x, a[];

    int main(void) { x=*a; return x; }

    int a[] = { 0, 2}; /* completes the type */

    isn't this strictly conforming?
     
    Luca Forlizzi, Nov 5, 2010
    #3
  4. On 5 Nov, 18:41, Luca Forlizzi <> wrote:

    oopps! :-}
    my answer to your second answer is obviously wrong, I am in a
    hurry. :-}
    But I think it is allowed to dereference a pointer to an incomplete
    array type. The following should be ok (I hope):

    int (*p)[];
    int a[5], b[4];

    int main(void) { p = &a; return (*p)[2]; }


    > > Show the code.  Even if gcc is wrong, it doesn't change the language
    > > spec.

    >
    > extern int x, a[];
    >
    > int main(void) { x=*a; return x; }
    >
    > int a[] = { 0, 2}; /* completes the type */
    >
    > isn't this strictly conforming?
     
    Luca Forlizzi, Nov 5, 2010
    #4
  5. Barry Schwarz wrote:
    > On Fri, 5 Nov 2010 08:41:24 -0700 (PDT), Luca Forlizzi
    > <> wrote:

    [...]
    >> 2) gcc prints "error: dereferencing pointer to incomplete type"
    >> while trying
    >> to translate
    >> (void) *ps;
    >> Does the standard forbids to dereference a pointer to an
    >> incomplete type?

    >
    > There is footnote 36 which says an incomplete type is not an object.


    Note that this has changed in C1X. It has been agreed that completeness
    is a scoped property of an object type, so instead of "object type" vs.
    "incomplete type" there is now "complete object type" vs. "incomplete
    object type". The former footnote 36 is gone; instead, there is a new
    sentence (not a footnote): "The element type shall be complete whenever
    the array type is specified".

    > 6.5.3.2-4 defines the result of * operator only if it points to a
    > function or to an object. Your code seems to be a constraint
    > violation.


    6.5.3.2p4 is in the Semantics section, not Constraints.

    [...]
    >> /* declaration of functions returning an incomplete structure type */
    >> struct S hht(void);
    >> struct S hhe(void);

    >
    > 6.9.1-3 says the return type must be void or an object type. Footnote
    > 36 says incomplete types are not objects. This is a constraint
    > violation.


    6.9.1 is about definitions, not declarations.
    --
    Marcin Grzegorczyk
     
    Marcin Grzegorczyk, Nov 5, 2010
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrew Ward
    Replies:
    7
    Views:
    506
    tom_usenet
    Feb 25, 2004
  2. Eric Smith

    structure containing incomplete array type

    Eric Smith, Apr 9, 2004, in forum: C Programming
    Replies:
    6
    Views:
    3,447
    Kevin Bracey
    Apr 13, 2004
  3. gk245
    Replies:
    2
    Views:
    1,211
    Christopher Benson-Manica
    May 6, 2006
  4. xuthee

    tree data structure: incomplete type error

    xuthee, Jul 18, 2007, in forum: C Programming
    Replies:
    2
    Views:
    709
    xuthee
    Jul 19, 2007
  5. Replies:
    1
    Views:
    964
    Richard Bos
    Jan 17, 2008
Loading...

Share This Page