Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Joseph,

On 11/14/22 19:13, Joseph Myers wrote:
On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:

SYNOPSIS:

unary-operator:  . identifier

That's not what you mean.  See the standard syntax.

Yup; typo there.


unary-expression:
   [other alternatives]
   unary-operator cast-expression

unary-operator: one of
   & * + - ~ !

-  It is not an lvalue.

    -  This means sizeof() and _Lengthof() cannot be applied to them.

sizeof can be applied to non-lvalues.

thinko there.  I fixed it in a subsequent email.


    -  This prevents ambiguity with a designator in an initializer-list within
a nested braced-initializer.

No, it doesn't.  See my previous points about syntactic disambiguation
being a separate matter from "one parse would result in a constraint
violation, so choose another parse that doesn't" (necessarily, because the
constraint violation that results could in general be at an arbitrary
distance from the point where a choice of parse has to be made).  Or see
e.g. the disambiguation rule about enum type specifiers: there is an
explicit rule "If an enum type specifier is present, then the longest
possible sequence of tokens that can be interpreted as a specifier
qualifier list is interpreted as part of the enum type specifier." that
ensures that "enum e : long int;" interprets "long int" as the enum type
specifier, rather than "long" as the enum type specifier and "int" as
another type specifier in the sequence of declaration specifiers, even
though the latter parse would result in a constraint violation later.

I get it.  It's only unambiguous if there's lookahead.


Also, requiring unbounded lookahead to determine what kind of construct is
being parsed may be considered questionable for C.  (If you have an
initializer starting .a.b.c.d.e, possibly with array element access as
well, those could all be designators or .a might be a reference to a
parameter of struct or union type and .b.c.d.e a sequence of references to
members within it and disambiguation under your rule would depend on
whether an '=' follows such an unbounded sequence.)

I'm thinking of an idea for this.


-  The type of a .identifier is always an incomplete type.

    -  This prevents circular dependencies involving sizeof() or _Lengthof().

We have typeof as well, which can be applied to expressions with
incomplete type.

Yes, but it would not be problematic in the two-pass parsing I have in mind.


-  Shadowing rules apply.

    -  This prevents ambiguity.

"Shadowing rules apply" isn't much of a specification.  You need detailed
wording that would be added to 6.2.1 Scopes of identifiers (or equivalent
elsewhere) to make it clear exactly what scopes apply for identifiers
looked up using this construct.

Yeah, I guess. I'm being easy for this draft. I'll try to be more precise for future revisions.


    -
        void foo(struct bar { int x; char c[.x] } a, int x);

        Explanation:
        -  Because of shadowing rules, [.x] refers to the struct member.

I really don't think standardizing VLAs-in-structures would be a good
idea.  Certainly it would be a massive pain to specify meaningful
semantics for them and this outline doesn't even attempt to work through
the consequences of removing the rule that "If an identifier is declared
as having a variably modified type, it shall be an ordinary identifier (as
defined in 6.2.3), have no linkage, and have either block scope or
function prototype scope.".

Maybe. I didn't have them in mind until Martin mentioned them. Now that he mentioned them, I'd like at least to be careful so that any new syntax doesn't do something that impedes adding them in the future, if it is ever considered desirable.


The idea that .x as an expression might refer to either a member or a
parameter is also a massive change to the namespace rules, where at
present those are in completely different namespaces and so in any given
context a name only needs looking up as one or the other.

Again, proposals should be *minimal*.

Yes. I only want to have a rough discussion about how the entire feature in an ideal future where everything is added would look like. Otherwise, adding a minimal feature without considering this future, might do something that prevents some part of it being implemented due to backwards compatibility.

So I'd like to discuss the whole idea before then going to a minimal proposal that will be *much* smaller than this idea that I'm discussing.

I'm happy with the Linux man-pages implementing the whole idea (even if it's impossible to implement it in C ever), and letting ISO C / GCC implement initially (and possibly ever) only the minimal stuff.


 And even when they are, many issues
may well arise in practice (see the long list of constexpr issues in my
commit message for that C2x feature, for example, which I expect to turn
into multiple NB comments and at least two accompanying documents).

Sure; I expect that.


Cheers,

Alex



--
<http://www.alejandro-colomar.es/>

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux