same struct, but different size.

Discussion in 'C Programming' started by Control Freq, Apr 10, 2010.

  1. Control Freq

    Control Freq Guest

    Hi,

    I have inheritted a large project, and its quite old, with quite a lot
    of work over the last few years.

    I see that a struct is defined a the top of two files, unit1.c and
    unit2.c .
    But, the struct has the same name, but the struct in unit2.c has more
    elements.

    A function in unit2.c takes a pointer to the struct as an arg, and the
    function is called from unit1.c .

    Now, I think that this is a bug, because the struct is in two places,
    and of two different sizes, and when the function is called, the
    program crashes.

    But, why didn't the compiler warn me about this problem? I presume
    it's a linker issue rather than a compiler issue. But, is there any
    way of getting the compiler to throw an error when this happens?

    There are many code files to check through, it's going to take ages to
    check them all!

    Help appreciated.

    Nick
    Control Freq, Apr 10, 2010
    #1
    1. Advertising

  2. Control Freq

    Seebs Guest

    On 2010-04-10, Control Freq <> wrote:
    > I see that a struct is defined a the top of two files, unit1.c and
    > unit2.c .
    > But, the struct has the same name, but the struct in unit2.c has more
    > elements.


    > A function in unit2.c takes a pointer to the struct as an arg, and the
    > function is called from unit1.c .


    Sounds bad.

    > But, why didn't the compiler warn me about this problem? I presume
    > it's a linker issue rather than a compiler issue. But, is there any
    > way of getting the compiler to throw an error when this happens?


    Yes! You declare the structure, once, in a single header, and every file
    includes that header.

    > There are many code files to check through, it's going to take ages to
    > check them all!


    Move the declaration into a header, add the header to everything, and you'll
    get errors.

    Also, warn the people in charge (management or whatever) *NOW*. Warn them
    that the program is dangerously badly written at a level that implies
    massive failure to understand C, and that any estimates they have for how
    long things will take are going to be too short. They may not like hearing
    it, but you might as well tell them in advance.

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, Apr 10, 2010
    #2
    1. Advertising

  3. Control Freq

    Eric Sosman Guest

    On 4/10/2010 1:25 PM, Seebs wrote:
    > On 2010-04-10, Control Freq<> wrote:
    >> I see that a struct is defined a the top of two files, unit1.c and
    >> unit2.c .
    >> But, the struct has the same name, but the struct in unit2.c has more
    >> elements.

    >
    >> A function in unit2.c takes a pointer to the struct as an arg, and the
    >> function is called from unit1.c .

    >[...]
    >
    > Also, warn the people in charge (management or whatever) *NOW*. Warn them
    > that the program is dangerously badly written at a level that implies
    > massive failure to understand C, and that any estimates they have for how
    > long things will take are going to be too short. They may not like hearing
    > it, but you might as well tell them in advance.


    In defense of the original implementors, the program may
    not have been "badly written" to start with. Large code bodies
    frequently contain pieces from independent agencies, and C does
    almost nothing to help separate colliding names. You've got a
    big batch of code that defines and uses a `struct jabberwock',
    and you decide to incorporate a spell-check library licensed
    from Spelitrite and a Pantone color-management library from
    Puceworks, and lo! each of these libraries also happens to define
    a `struct jabberwock' for *its* own use. So now you've got three
    incompatible `struct jabberwock' definitions floating around in
    the code, and you're faced with the problem of making sure no two
    of them ever bump into each other ...

    ... and someday, inevitably, some programmer says "I've got
    a `struct jabberwock' and I need to gyre it, and -- Hey, look!
    There's a `void gyre(struct jabberwock*)' function right here,
    already written, and all I need to do is call it!" Things slithe
    downhill right rapidly after that -- but it's no one's fault,
    really.

    --
    Eric Sosman
    lid
    Eric Sosman, Apr 10, 2010
    #3
  4. Control Freq

    Control Freq Guest

    >
    >      In defense of the original implementors, the program may
    > not have been "badly written" to start with.  Large code bodies
    > frequently contain pieces from independent agencies, and C does
    > almost nothing to help separate colliding names.  You've got a
    > big batch of code that defines and uses a `struct jabberwock',
    > and you decide to incorporate a spell-check library licensed
    > from Spelitrite and a Pantone color-management library from
    > Puceworks, and lo! each of these libraries also happens to define
    > a `struct jabberwock' for *its* own use.  So now you've got three
    > incompatible `struct jabberwock' definitions floating around in
    > the code, and you're faced with the problem of making sure no two
    > of them ever bump into each other ...
    >


    Hi Eric, you described it just right.
    Perhaps you were one of the original developers? There is actually a
    pantone colour management library in there! But not by the same name.

    Regards

    Nick
    Control Freq, Apr 10, 2010
    #4
  5. Control Freq

    Eric Sosman Guest

    On 4/10/2010 2:59 PM, Control Freq wrote:
    >>
    >> In defense of the original implementors, the program may
    >> not have been "badly written" to start with. Large code bodies
    >> frequently contain pieces from independent agencies, and C does
    >> almost nothing to help separate colliding names. You've got a
    >> big batch of code that defines and uses a `struct jabberwock',
    >> and you decide to incorporate a spell-check library licensed
    >> from Spelitrite and a Pantone color-management library from
    >> Puceworks, and lo! each of these libraries also happens to define
    >> a `struct jabberwock' for *its* own use. So now you've got three
    >> incompatible `struct jabberwock' definitions floating around in
    >> the code, and you're faced with the problem of making sure no two
    >> of them ever bump into each other ...

    >
    > Hi Eric, you described it just right.
    > Perhaps you were one of the original developers? There is actually a
    > pantone colour management library in there! But not by the same name.


    No way to know for sure whether I was one of the developers
    of the unnamed piece of software you're dealing with -- but most
    likely I wasn't, because there's a huge amount of software and
    I've written "less than" ten percent of it ... It's a familiar
    problem in C, though, when pieces from disparate sources are glued
    together.

    As for the Pantone stuff, I just chose that as an example of
    the sort of thing one might very well license from a specialist
    vendor rather than try to develop from scratch. I *did* once work
    for a company that licensed both a Pantone library and a spell-
    checker (and a few other things) from outside sources -- and had
    exactly this sort of "integration problem" with them.

    --
    Eric Sosman
    lid
    Eric Sosman, Apr 10, 2010
    #5
  6. Control Freq

    Liviu Guest

    "Control Freq" <> wrote...
    >
    > I see that a struct is defined a the top of two files, unit1.c and
    > unit2.c. But, the struct has the same name, but the struct in unit2.c
    > has more elements.
    >
    > A function in unit2.c takes a pointer to the struct as an arg, and the
    > function is called from unit1.c .


    What's been already said is correct - this is bad and dangerous.

    > Now, I think that this is a bug, because the struct is in two places,
    > and of two different sizes, and when the function is called, the
    > program crashes.


    As for the "crash" or not part, it somewhat depends on what
    exactly you meant by "has more elements" (in particular whether
    the leading elements in both structures match) and the internals
    of the function being called. It is technically possible to have...

    struct A { int b; }; // unit1.c

    struct A { int b, c; }; // unit2.c
    void setAb(struct A *a, int n) { a->b = n; }

    ....and call setAb from unit1 with an A pointer without ill side effects.
    It would even be legit if the pointer was originally obtained from some
    other function in unit2, albeit terribly poor design. But then I've seen
    stranger things with C code trying to mimic C++ inheritance ;-)

    Liviu
    Liviu, Apr 10, 2010
    #6
  7. Control Freq

    Seebs Guest

    On 2010-04-10, Eric Sosman <> wrote:
    > On 4/10/2010 1:25 PM, Seebs wrote:
    >> Also, warn the people in charge (management or whatever) *NOW*. Warn them
    >> that the program is dangerously badly written at a level that implies
    >> massive failure to understand C, and that any estimates they have for how
    >> long things will take are going to be too short. They may not like hearing
    >> it, but you might as well tell them in advance.


    > In defense of the original implementors, the program may
    > not have been "badly written" to start with. Large code bodies
    > frequently contain pieces from independent agencies, and C does
    > almost nothing to help separate colliding names. You've got a
    > big batch of code that defines and uses a `struct jabberwock',
    > and you decide to incorporate a spell-check library licensed
    > from Spelitrite and a Pantone color-management library from
    > Puceworks, and lo! each of these libraries also happens to define
    > a `struct jabberwock' for *its* own use. So now you've got three
    > incompatible `struct jabberwock' definitions floating around in
    > the code, and you're faced with the problem of making sure no two
    > of them ever bump into each other ...


    You have a point here, although I think that the structs were declared in
    those two files, rather than in headers, certainly makes the job a lot
    harder...

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, Apr 10, 2010
    #7
  8. On Sat, 10 Apr 2010 08:42:38 -0700 (PDT), Control Freq
    <> wrote:

    >Hi,
    >
    >I have inheritted a large project, and its quite old, with quite a lot
    >of work over the last few years.
    >
    >I see that a struct is defined a the top of two files, unit1.c and
    >unit2.c .
    >But, the struct has the same name, but the struct in unit2.c has more
    >elements.


    Do you mean the two structure declarations have the same tag or do you
    mean that a structure object in each file has the same name? When you
    say at the top of the file, do you mean prior to (and therefore
    outside) the definition of any function?
    >
    >A function in unit2.c takes a pointer to the struct as an arg, and the
    >function is called from unit1.c .


    Where is the prototype for the function in unit2 that is called from
    unit 1?

    But something is strange. If the function in unit2 takes a pointer
    and actually uses that pointer to access the structure, then it is
    never accessing the structure defined in unit2. Or did you mean that
    only the structure type is declared in both .c files? If you cannot
    post sections of the code, you need to be very specific in your
    description.

    >
    >Now, I think that this is a bug, because the struct is in two places,
    >and of two different sizes, and when the function is called, the
    >program crashes.


    Crashing immediately is the best kind of undefined behavior.

    >
    >But, why didn't the compiler warn me about this problem? I presume


    The compiler cannot warn you because the two .c files are separate
    translation units and information gathered while compiling one is
    discarded prior to compiling the other.

    >it's a linker issue rather than a compiler issue. But, is there any
    >way of getting the compiler to throw an error when this happens?


    The linker only deals with things that have external linkage. The
    concept of linkage does not apply to structure tags. The linker could
    warn you only if you defined objects in each of the .c files with the
    same name and external linkage. In that case you should get a
    diagnostic regarding duplicate definition.

    >
    >There are many code files to check through, it's going to take ages to
    >check them all!


    It's called job security.

    The problem need not be limited to structure objects. You could have
    the same situation with arrays where the name is the same but the
    dimensions are different.

    --
    Remove del for email
    Barry Schwarz, Apr 10, 2010
    #8
    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. Alexander N. Spitzer
    Replies:
    21
    Views:
    1,768
    Randolf Richardson
    Aug 16, 2004
  2. pradeep
    Replies:
    3
    Views:
    802
    cwdjrxyz
    Jun 7, 2007
  3. Christopher Brewster
    Replies:
    5
    Views:
    339
    John Machin
    Nov 14, 2008
  4. bluebaron
    Replies:
    3
    Views:
    739
    Jonathan N. Little
    Nov 4, 2009
  5. Guest
    Replies:
    2
    Views:
    179
    Foo Man Chew
    Dec 29, 2003
Loading...

Share This Page