On Wed, 9 Sep 2020, Martin Sebor via Gcc-patches wrote: > Joseph, do you have any concerns with or comments on the most > recent patch or is it okay as is? > > https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552266.html
I'm not yet convinced by the logic for extracting an array bound from a parameter declared using a typedef for an array type. Say you have typedef int A[3]; void f (A *x[*]); so an argument that is an array, using [*], of pointers to arrays, where those latter arrays are specified using the typedef. As I read the logic, first the pointer declarator is handled (ignored), then the array declarator results in [*] being stored in spec, then the "if (pd->kind == cdk_id)" handling comes into play - and because spec is "*" and vbchain is NULL_TREE, the upper bound of A gets extracted, but the upper bound of A should be irrelevant here because it's a type that's the target of a pointer. The information from parm->specs->type logically comes before, not after, the information from the declarator. As far as I can see, if one declaration gets part of the parameter type (involving VLAs) from a typedef and another declaration gets that part of the type directly in the declaration, the two spec strings constructed might differ in the number of VLA bounds mentioned in the spec strings. Is the code using those strings robust to handling the case where some of the VLA bounds are missing because they came from a typedef? -- Joseph S. Myers jos...@codesourcery.com
