same struct, but different size.

C

Control Freq

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
 
S

Seebs

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
 
E

Eric Sosman

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.
 
C

Control Freq

     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
 
E

Eric Sosman

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.
 
L

Liviu

Control Freq said:
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
 
S

Seebs

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
 
B

Barry Schwarz

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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top