liberal itypes for prototypes (with no def)

[mwhicks1]

Suppose we have the code

int *foo(int *a) {
 a = (int *)5;
 return a;
}
void bar(int x) {
  int *p = &x;
  int *q = foo(p);
}

Using liberalized itypes (the current 3c behavior), this translates to

int *foo(int *a : itype(_Ptr<int>)) : itype(_Ptr<int>) {
 a = (int *)5;
 return a;
}
void bar(int x) {
  _Ptr<int> p = &x;
  _Ptr<int> q = foo(p);
}

Now suppose that we didn’t have the definition of foo, but just the prototype.

int *foo(int *a);

void bar(int x) {
  int *p = &x;
  int *q = foo(p);
}

The result is that 3c makes no changes -- all pointers are left as WILD. This is because foo is not given a liberal itype, and its WILDness propagates to bar.

But this behavior seems incongruous. The reason that we treat the prototype pessimistically (i.e., all its parameters are WILD) is that we don’t have the definition to know what it does. But in the first example we do have the definition and know perfectly well what it does ---it’s unsafe! Despite that unsafety, we give it an itype anyway, since doing so facilitates more rapid conversion.

So I think that we should extend this principle to prototypes. If we have a prototype with no definition, but it is within a file that occurs within the base-dir, then we should convert it to have an itype.

[mwhicks1]

A follow-on problem that then arises is that we need to be able to properly convert code that looks like this:

int *foo(int *a : itype(_Ptr<int>)) : itype(_Ptr<int>);

int *foo(int *a) {
 a = (int *)5;
 return a;
}

That is, if we do as this issue suggests, we will then have to contend with converting the definition of foo when we get to it, and the situation will look like the above. Currently this doesn't work, so I've made it issue #403 .

[kyleheadley]

When the definition of foo is within code that the user is trying to convert, we give it a safe interface with the assumption that it will eventually be converted by the user. And 3c supports this with warnings/errors on code within foo. When it is outside the code being converted, we assume it is unsafe so that the user understands that bar is unsafe: it makes calls to unvetted external code. Even running within a checked scope, foo is allowed to have itypes, so there would be no warning about external unsafe code if your example were converted (3rd block in original post). Part of this probably comes from our alternative use of itypes in the liberal itypes update, and I've assumed full code conversion.

The rest of the issue deals with problems that come up in converting one file at a time, which we certainly need to handle.

[mwhicks1]

I am thinking of the case that the "external" code is within the base-dir of the code being converted. For the above example, the user has put the prototype in the code they are converting, so I am assuming it's not a system header. Likewise, if the prototype was in a header file, but that header was within the base-dir, I would again assume that it's code they are ultimately converting.

I see no benefit to erring on the side of caution and making things unsafe. If you don't convert to make it a _Ptr it's still in your code/program, and if you run it it will be unsafe. If you put the itype in, you at least propagate knowledge of safety further throughout the program, while still leaving open the conversion work to be done.

In sum, I don't see why this change will make things any less safe than what we have now, and it will accelerate the process of conversion.

[kyleheadley]

I see, so this is entirely about converting one (or a few) files at a time. Because when I convert all, all the prototypes are given itypes. So its a usage trade-off. And I doubt there's a simple check as to whether a function definition is within base-dir. Is it worth it to have an -partial command-line flag while we transition?

[mwhicks1]

I am saying that if the prototype is in a file that's in the base-dir, then we convert it to an itype. If it's outside the base dir, then it's a system header or in some other library we are not considering.

[mattmccutchen-cci]

Done in #691 (-infer-types-for-undefs), I think.