"one-line" change to clang still causes acceptance of incorrect code

[dhollman]

The "one-line" change to clang (as far as I can tell) that we referenced in the [][] paper is this one (in commit b7b9efb) on the clang github). There are still substantial things that don't work even with that change, though; for instance:

#include <cstdlib>
#include <iostream>

// This *SHOULDN'T* work
void test(int[][][5][][]) {
  cout << "called foo(int[][][5][][])" << endl;
}

int main(int argc, char** argv)
{
  test(*(int(*)[][][5][][])&i);
}

[tkoeppe]

On that note, I would also recommend striking the "trivial, non-breaking" language from the introduction. The issue is more complex than such wording would suggest (as has repeatedly emerged in EWG discussions). It might make a better impression if you make clear that this proposal requires some thought and care and that you think it's worth it, than if it looks like the proposal underestimates its own complexity.

[hcedwar]

@tkoeppe : We are systematically identifying the issues that must be addressed. At this point the complexity appears to be a breadth issue, not a depth issue. Primarily identifying those places where it is assumed (and sometimes stated) that the decay of an incomplete array type is a complete type. For this proposal the decay may or may not be complete.