Date: Mon, 2 Aug 2021 16:13:48 +0000
On Sun, 1 Aug 2021, will wray via Liaison wrote:
> int f()[2] // *#0*
That needs ABI changes in architecture-specific psABI documents to
describe how arrays are returned by value. It might help if the proposers
(a) had general proposals for what those ABI changes would look like and
(b) expressed the intention to make those proposals to the corresponding
ABI working groups for various architectures if the language proposal is
accepted.
(Cf. _BitInt, where the proposers did (a) and expressed the intention in
(b). I don't know if (b) has yet been followed through on there for any
architectures, however; I haven't yet seen such proposals on the x86-64 or
ia32 groups at least.)
I would suggest that key questions to consider for C would include VLA
issues (note that initializers aren't allowed for VLAs at present), as
well as how to avoid incompatibilities if you change the existing rule
that decay of functions and arrays to pointers occurs very early in almost
all contexts.
> int f()[2] // *#0*
That needs ABI changes in architecture-specific psABI documents to
describe how arrays are returned by value. It might help if the proposers
(a) had general proposals for what those ABI changes would look like and
(b) expressed the intention to make those proposals to the corresponding
ABI working groups for various architectures if the language proposal is
accepted.
(Cf. _BitInt, where the proposers did (a) and expressed the intention in
(b). I don't know if (b) has yet been followed through on there for any
architectures, however; I haven't yet seen such proposals on the x86-64 or
ia32 groups at least.)
I would suggest that key questions to consider for C would include VLA
issues (note that initializers aren't allowed for VLAs at present), as
well as how to avoid incompatibilities if you change the existing rule
that decay of functions and arrays to pointers occurs very early in almost
all contexts.
-- Joseph S. Myers joseph_at_[hidden]
Received on 2021-08-02 11:14:00