Open mattmccutchen-cci opened 3 years ago
Is this still an issue? I searched the "Build converted Icecast" report and it had no instances of "malloc". I know there's been a lot of itype improvements since this was posted.
The specific error we saw in icecast seems to be fixed, but a related issues persists. For two files foo.c
and bar.c
converted with 3c -output-dir=checked
:
foo.c:
#include <stdlib.h>
void a() {
int *b = malloc(sizeof(int));
}
bar.c:
void c() {
int *d = malloc(sizeof(int));
}
3C doesn't add the type argument to malloc in bar.c
, but it still treats the call as checked. This is an error, because a checked prototype for malloc doesn't exist in the translation unit for bar.c
. Compiling the following converted bar.c
gives an error.
void c() {
_Ptr<int> d = malloc(sizeof(int));
}
bar.c:2:17: error: expression has unknown bounds, cast to ptr<T> expects source to have bounds
_Ptr<int> d = malloc(sizeof(int));
^~~~~~~~~~~~~~~~~~~
More generally, we can trigger this error without using implicit declarations and special cased allocator functions.
foo.c:
int *test(void) : itype(_Ptr<int>);
void a() {
int *b = test();
}
bar.c:
int *test();
void c() {
int *d = test();
}
Assuming we reuse this GitHub issue to refer to the issue John mentioned, if it isn't causing a benchmark error as far as we know, I think we should remove the label now. We can always add the label back if we rediscover the issue during error triage.
To the merits of the issue: I presume the cause is just that 3C links the test
extern function across translation units and introduces a single atom for its return type, and in this case, for whatever reason, the "checked" status is taking priority and being used in bar.c
? As long as 3C links global definitions, I don't think we can expect it to cope with arbitrary differences in declarations across translation units, and I'd be opposed to adding workarounds in narrower cases unless we have evidence that it's important in real-world code. Of course, we have a proposal in #341 to change the linking. John, what do you think? Is this issue worth keeping open?
I think this can be closed. I see two ways this might get fixed, and both are covered by existing issues.
test
refer to the same function, then this error could be fixed by rewriting the unchecked declaration to use an itype. This is discussed in #678.I see: this is not an arbitrary difference in declarations, but rather one in which the declarations would be compatible if they appeared in the same translation unit. Yes, it would be nice if 3C supported that. At this point, I can't rule out that there might be similar cases not covered by #678, but I think we can wait until we run into them to file an issue. Thanks.
Actually, I thought of at least one case that #678 (as currently stated) wouldn't fix: if the declaration without the itype is #include
d from unwritable code. So I think we should keep this issue for all cases not covered by #678, though it may be low priority and we may decide that there isn't any solution whose benefit would justify the implementation effort. I doubt we'd want 3C to automatically add a redeclaration with the itype to the user's file, but perhaps 3C could issue a warning to help the user understand the root cause of the compile error.
A similar problem with environ
came up in #725, so I'm updating the title of this issue to cover all program elements that can have itypes, not just functions.
A problem affecting the icecast benchmark, from https://github.com/correctcomputation/actions/pull/13#pullrequestreview-618756386: