Skip to content
This repository was archived by the owner on Sep 18, 2024. It is now read-only.
This repository was archived by the owner on Sep 18, 2024. It is now read-only.

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

Description

@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);
}

Activity

tkoeppe commented on Nov 11, 2017

@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 commented on Nov 14, 2017

@hcedwar
Contributor

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions