Should wild ptrs lose array bounds?

[kyleheadley]

#define A 2

int b[A];

// make b unchecked
// void* unc(void) { return b; }

int* foo(void) {
  return b;
}

converts to

#define A 2

int b _Checked[2];

// make b unchecked
// void* unc(void) { return b; }

_Array_ptr<int> foo(void) : count(2) {
  return b;
}

remove the comment to make b wild and we get

#define A 2

int b[A];

// make b unchecked
void* unc(void) { return b; }

int *foo(void) : itype(_Array_ptr<int>) count(2) {
  return b;
}

In-lining a macro and using it as a bounds is unfortunate, but at least in the first conversion it is consistent. b becomes an array of 2 elements and so foo returns an array of 2 elements. In the second conversion, b is not rewritten, but internally bound to 2 elements. This bound shows up later when foo still returns (tries to? will eventually? what is the interpretation of a return itype?) an array of 2 elements.

Perhaps this bound should be removed? It may be very confusing to people to see, or miss, a number showing up like this in the conversion. And it could cause bugs if they don't remove it before changing A, which could be anywhere in the project.

[mwhicks1]

I think this is a limitation of the rewriter. There are other places in the code where we endeavor to leave the old text in the code in place; you could look there for inspiration for a fix. @john-h-kastner -- pointers?

[john-h-kastner]

The in-lining of the macro in the length of b is the same as issue #173. This could be fixed with something analogous to what I did for pointer base types in PR #254. The basic idea would be to figure out the source range of the bounds expression for constant sized arrays and to store the source string for that range on the PVConstraint (handling arbitrarily deep nested arrays will complicate this a bit, but not too much). Then, in rewriting, use the stored string when printing the bounds instead of re-generating the bounds string from the stored bounds expression.

Fixing this in a way that also applies to the inferred bounds for foo might complicate things a lot. The string representation of the bounds will need to be passed through the array bounds inference code. That might not actually be too bad; I think bounds expressions are already just stored as strings in the ProgramVar class.