structs are not global : good or bad (relates to preprocessor, in part) ?

[mwhicks1]

The behavior of 3C on structs is odd when you run on preprocessed code. This issue investigates what might be going on.

struct defs are local ...

a.c:

struct foo { int *a; };
void bar(struct foo *p) { p->a = 0; }

b.c:

struct foo { int *a; };
void baz(struct foo *p) { p->a = (int *)1; }

If we call 3c -output-postfix=checked a.c b.c then the result will be that a.c's version of struct foo will have _Ptr<int> a whereas b.c's version will have int *a. This could be viewed as fine: These are two local struct defs that happen to have the same name.

... even if there is data flow

But, suppose I change b.c to be b2.c:

struct foo { int *a; };
extern void bar(struct foo *);
void baz(struct foo *p) { p->a = (int *)1; bar(p); }

Now we would prefer that a.c's version to be the same as b2.c's version, but it is not: the rewriting is the same as in the first example, where a.c's version has field _Ptr<int> a for the field, but the b2.c version does not.

So this is a bug.

a shared header unifies uses

If I change the original a.c and b.c to share a header, that also serves to unify them, even if there is no dataflow.
foo.h:

struct foo { int *a; };

a3.c:

#include "foo.h"
void bar(struct foo *p) { p->a = 0; }

b3.c:

#include "foo.h"
void baz(struct foo *p) { p->a = (int *)1; }

The result here will be int *a in foo.h (i.e., the original foo.h is not changed). The same would be true if we made b3.c like b2.c, calling external bar, too.

... unless it's preprocessed

If I run clang -E on a3.c and b3.c the included the struct def from foo.h is inlined in each, e.g., as follows:

# 1 "b3.c"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 366 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "b.c" 2
# 1 "./foo.h" 1
struct foo {
  int *a;
};
# 2 "b3.c" 2
void baz(struct foo *p) {
  p->a = (int *)1;
}

When I run 3c on these already-preprocessed files, it treats the struct definitions independently, just as was the case for a.c and b2.c, above. In other words, the presence of the #1 "b3.c" etc. in the file does not convince clang/3c that there is just a single definition in two places---it is treated as two definitions.

what to do?

There are a couple of ways I can imagine fixing the bug:

• The simplest way is to treat struct definitions as global. We could have a map like we do for functions from the type name to the constraint info. This will be safe, but potentially conservative.

• Another way is to look for dataflow, as in the a.c and b2.c case. This dataflow will signal that we should unify the two definitions. I think what's happening now is that statements like bar(p) in b2.c do not look inside p's type as a struct foo, essentially assuming that if it's a struct then it has global scope. Instead, perhaps the code is able to figure out that p in the above is referring to one struct foo definition while the callee is referring to a different struct foo, and these two should be unified. This unification could possibly take place at the same time we are unifying various prototypes for functions. Or it could happen when processing call expressions.

[mwhicks1]

It would be useful to check this behavior for typedefs, too, since they also can also be defined multiple times in a program, and may be allowed distinct interpretations so long as there is no dataflow between values having those distinct definitions.

[mattmccutchen-cci]

... unless there is data flow

In this example, I am getting struct foo { _Ptr<int> a; }; in a.checked.c, which matches my understanding of 3C's logic. Maybe we can set up a shared environment on gamera to try to track down whatever it is that is giving us different results?

Note that if we change b.c so that the assignment is p->a = 0, and thus a can be treated as checked, it is rewritten as checked in both files; this seems to contradict behavior that @mattmccutchen-cci saw in another context.

I don't think this contradicts anything that I said. Under my theory, the structs are still independent, but each a field can be made checked because it isn't used unsafely.

[mwhicks1]

I updated the example to show that there's a bug. In particular, the behavior of the second variation and the last variation differ, but syntactically the code in the two files is the same.

[mwhicks1]

Hm. I was not able to reproduce the behavior for the ... unless there is data flow variation so I've updated the issue appropriately, and laid out the question about how to fix the problem.