How can checked headers add itypes to struct already defined in original system headers?

[mattmccutchen-cci]

In some of our porting work, we're starting to use system functions that manipulate structs that have pointer members. For example, vsftpd calls getpwuid and looks at the pw_name field of the returned struct passwd, which has type char *. We're adding a checked declaration for getpwuid in #448, but in order to make the vsftpd code fully checked, we also need an itype for the pw_name field of struct passwd.

The general approach in the checked headers is to include the original system headers and then redeclare things with itypes. This works fine for functions but not for structs: C does not allow a struct to be defined multiple times in the same translation unit, and Checked C does not appear to have relaxed this restriction. For example, this code:

struct foo_struct {
  int *foo_field;
};

struct foo_struct {
  int *foo_field : itype(_Ptr<int>);
};

void myfunc() {
  struct foo_struct s;
  s.foo_field = 0;
}

gives the compile error:

double-struct.c:5:8: error: redefinition of 'foo_struct'
struct foo_struct {
       ^
double-struct.c:1:8: note: previous definition is here
struct foo_struct {
       ^

So how can we add itypes to existing structs?

To make matters more complicated, sometimes a standard says that a struct is guaranteed to have at least certain members but might have more on some systems (example: POSIX for struct passwd). So it seems that what we really want here is a way to attach an itype to a given member of an existing struct in a way that will work regardless of what other members may be present. This might have to be a new Checked C language construct. One crude possible syntax would be an attribute on a redeclaration of the struct:

struct foo_struct {
  int *foo_field;
};

struct __attribute__((itype(foo_field, _Ptr<int>))) foo_struct;

But if you're willing to introduce dedicated syntax, that would probably be better.

An argument could have been made for filing this issue in the checkedc-clang repository because that's where the change probably needs to be made and in principle it could apply to third-party libraries as well as the system headers, but I decided to start here. I'm happy to file another issue in checkedc-clang if warranted.

[sulekhark]

This is on our TODO list but we do not plan to prioritize this issue in the immediate future.