Re: How can Autoconf help with the transition to stricter compilation defaults?

[Paul Eggert]

On 2022-11-11 07:11, Aaron Ballman wrote:

Clang doesn't require such a linker (we work with various system linkers).


As long as the system linkers continue to work as they have 
traditionally worked, we're fine.



the frontend perspective, we can't tell the difference between
"trust me this is safe because it never gets executed" and "this is a
CVE"


If some system linker ever attempts to reject links with mismatched 
signatures, Autoconf-generated code will need to have a way to shut that 
off. I hope Clang maintainers can be cajoled into supporting that, if 
the time comes. Perhaps there can be a #pragma, or a compile-time 
option, to do that.

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Paul Eggert]

On 2022-11-11 07:11, Aaron Ballman wrote:

We believe the runtime behavior is sufficiently dangerous to
warrant a conservative view that any call to a function will be a call
that gets executed at runtime, hence a definitive signature mismatch
is something we feel comfortable diagnosing (in some form) by default.


As long as these diagnostics by default do not cause the compiler to 
exit with nonzero status, we should be OK with Autoconf-generated 
'configure' scripts. Although there will be problems with people who run 
"./configure CFLAGS='-Werror'", that sort of usage has always been 
problematic and unsupported by Autoconf, so we can simply continue to 
tell people "don't do that".

gcc-12-20221112 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20221112 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20221112/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision d4d628c0080aaf09983b0b1c4eb6c0d9b1cb92c8

You'll find:

 gcc-12-20221112.tar.xz   Complete GCC

  SHA256=74b0dcf8b4856a8420d0610407533f59a8b523b9afe121d4b867ba25ad2ec2b7
  SHA1=8618a10c6e93b1cb17c6dd4d29cf39d3b5d9e8ae

Diffs from 12-20221105 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

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

[Alejandro Colomar via Gcc]

On 11/12/22 18:02, Joseph Myers wrote:

On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:


No, assigning to a function parameter from within another parameter
declaration wouldn't make sense.  They should be readonly.  Side effects
should be forbidden, I think.


Such assignments are already allowed.  In a function definition, the side
effects (including in size expressions for array parameters adjusted to
pointers) take place before entry to the function body.


Then, I'm guessing that rules need to change in a way that .initializer cannot
appear as the left operand of an assignment-expression.


I think needing such a very special case rule tends to indicate that some
alternative syntax, not needing such a rule, would be better.


Well, by not being an lvalue, it can't be assigned to.  That would be somewhat 
like sizeof(identifier), which is also a unary-expression, so it's not so much 
of a special case, is it?


void f(size_t s, int a[sizeof(1) = 1]);  // constraint violation
void g(size_t s, int a[.s = 1]); // Also constraint violation
void h(size_t s, int a[s = 1]);  // This is fine



--



OpenPGP_signature
Description: OpenPGP digital signature

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

[Joseph Myers]

On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:

> > > No, assigning to a function parameter from within another parameter
> > > declaration wouldn't make sense.  They should be readonly.  Side effects
> > > should be forbidden, I think.
> > 
> > Such assignments are already allowed.  In a function definition, the side
> > effects (including in size expressions for array parameters adjusted to
> > pointers) take place before entry to the function body.
> 
> Then, I'm guessing that rules need to change in a way that .initializer cannot
> appear as the left operand of an assignment-expression.

I think needing such a very special case rule tends to indicate that some 
alternative syntax, not needing such a rule, would be better.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Zack Weinberg via Gcc]

Wookey  writes:
> On 2022-11-10 19:08 +0100, Florian Weimer wrote:
>> based on a limited attempt to get this fixed about three years
>> ago, I expect that many of the problematic packages have not had their
>> configure scripts regenerated using autoconf for a decade or more.  This
>> means that as an autoconf maintainer, you unfortunately won't be able to
>> help us much.
>
> We changed the default in debian to re-autoconf on build a few years
> ago precisely so that changes in the tools (particularly new arch
> support) were picked up even by code that was not being re-released or
> released without autofoo updates.  This has worked remarkably well.
>
> So changes in the tools will get used, at least in that context, which
> includes a fairly hefty pile of crufty old code. I have no feeling for
> how many packages are actually affected by this. Is there a quick way to test?

In the run-up to Autoconf 2.70 I got Lucas to do a Debian archive
rebuild and mass bug filing, so, look through Debian packages for
patches being carried for configure.ac and/or bundled .m4 files?

zw

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Wookey]

On 2022-11-10 19:08 +0100, Florian Weimer wrote:
> * Zack Weinberg via Gcc:
> 
> > It’s come to my attention (via https://lwn.net/Articles/913505/ and
> > https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and
> > Clang both plan to disable several “legacy” C language features by
> > default in a near-future release (GCC 14, Clang 16) (see the Fedora
> > wiki link for a list).

> based on a limited attempt to get this fixed about three years
> ago, I expect that many of the problematic packages have not had their
> configure scripts regenerated using autoconf for a decade or more.  This
> means that as an autoconf maintainer, you unfortunately won't be able to
> help us much.

We changed the default in debian to re-autoconf on build a few years
ago precisely so that changes in the tools (particularly new arch
support) were picked up even by code that was not being re-released or
released without autofoo updates.  This has worked remarkably well.

So changes in the tools will get used, at least in that context, which
includes a fairly hefty pile of crufty old code. I have no feeling for
how many packages are actually affected by this. Is there a quick way to test?

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

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

[Martin Uecker via Gcc]

Am Samstag, den 12.11.2022, 14:54 + schrieb Joseph Myers:
> On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
> 
> > Since it's to be used as an rvalue, not as a lvalue, I guess a
> > postfix-expression wouldn't be the right one.
> 
> Several forms of postfix-expression are only rvalues.
> 
> > > (with a special rule about how the identifier is interpreted, different
> > > from the normal scope rules)?  If so, then ".a = 1" could either match
> > > assignment-expression directly (assigning to the postfix-expression ".a").
> > 
> > No, assigning to a function parameter from within another parameter
> > declaration wouldn't make sense.  They should be readonly.  Side effects
> > should be forbidden, I think.
> 
> Such assignments are already allowed.  In a function definition, the side 
> effects (including in size expressions for array parameters adjusted to 
> pointers) take place before entry to the function body.
> 
> And, in any case, if you did have a constraint disallowing such 
> assignments, it wouldn't suffice for syntactic disambiguation (see the 
> previous point I made about that; I have some rough notes towards a WG14 
> paper on syntactic disambiguation, but haven't converted them into a 
> coherent paper).

My idea was to only allow

array-declarator : direct-declarator [ . identifier ]

and only for parameter (not nested inside structs declared
in parameter list) as a first step because it seems this 
would exclude all difficult cases.

But if we need to allow more complicated expressions, then
it starts getting more complicated.

One could could allow more generic expressions, and
specify that the .identifier refers to a
parameter in
the nearest lexically enclosing parameter list or
struct/union.

Then

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

would not be allowed (which is good because then we
could later use the syntax also inside structs). If
we apply scoping rules, the following would work:

struct bar { int y; };
void foo(char p[((struct bar){ .y = .x }).y], int x);

But not:

struct bar { int y; };
void foo(char p[((struct bar){ .y = .y }).y], int y);


But there are not only syntactical problems, because
also the type of the parameter might become relevant
and then you can get circular dependencies:

void foo(char (*a)[sizeof *.b], char (*b)[sizeof *.a]);

I am not sure what would the best way to fix it. One
could specifiy that parameters referred to by 
the .identifer syntax must of some integer type and
that the sub-expression .identifer is always
converted to a 'size_t'. 

Maybe one should also add a constraint that all new
type length expressions, i.e. using the syntax,
can not have side effects. Or even that they follow
all the rules of integer constant expressions with
the fictitious assumption that all . identifer 
sub-expressions are integer constant expressions.
The rationale being that this would facilitate
compile time reasoning about length expressions.
 

Martin

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

[Alejandro Colomar via Gcc]

Hi Joseph,

On 11/12/22 15:54, Joseph Myers wrote:

On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:


Since it's to be used as an rvalue, not as a lvalue, I guess a
postfix-expression wouldn't be the right one.


Several forms of postfix-expression are only rvalues.


(with a special rule about how the identifier is interpreted, different
from the normal scope rules)?  If so, then ".a = 1" could either match
assignment-expression directly (assigning to the postfix-expression ".a").


No, assigning to a function parameter from within another parameter
declaration wouldn't make sense.  They should be readonly.  Side effects
should be forbidden, I think.


Such assignments are already allowed.  In a function definition, the side
effects (including in size expressions for array parameters adjusted to
pointers) take place before entry to the function body.


Then, I'm guessing that rules need to change in a way that .initializer cannot 
appear as the left operand of an assignment-expression.


That is, for the following current definition of the assignment-expression (as 
of N3054):


assignment-expression:
conditional-expression
unary-expression assignment-operator assignment-expression

The unary-expression cannot be formed by a .initializer.

Would that be doable and sufficient?

Cheers,

Alex



And, in any case, if you did have a constraint disallowing such
assignments, it wouldn't suffice for syntactic disambiguation (see the
previous point I made about that; I have some rough notes towards a WG14
paper on syntactic disambiguation, but haven't converted them into a
coherent paper).



--



OpenPGP_signature
Description: OpenPGP digital signature

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

[Joseph Myers]

On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:

> Since it's to be used as an rvalue, not as a lvalue, I guess a
> postfix-expression wouldn't be the right one.

Several forms of postfix-expression are only rvalues.

> > (with a special rule about how the identifier is interpreted, different
> > from the normal scope rules)?  If so, then ".a = 1" could either match
> > assignment-expression directly (assigning to the postfix-expression ".a").
> 
> No, assigning to a function parameter from within another parameter
> declaration wouldn't make sense.  They should be readonly.  Side effects
> should be forbidden, I think.

Such assignments are already allowed.  In a function definition, the side 
effects (including in size expressions for array parameters adjusted to 
pointers) take place before entry to the function body.

And, in any case, if you did have a constraint disallowing such 
assignments, it wouldn't suffice for syntactic disambiguation (see the 
previous point I made about that; I have some rough notes towards a WG14 
paper on syntactic disambiguation, but haven't converted them into a 
coherent paper).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Zack Weinberg via Gcc]

Sam James  writes:

>> On 12 Nov 2022, at 03:40, Zack Weinberg  wrote:
>> This is definitely more work than I can see myself doing on a volunteer
>> basis, but a 2.69.1 patch release — nothing that’s not already on trunk,
>> cherry pick the changes needed to support the newer compilers (and
>> also newer Perl and Bash and M4) is a thing that could happen.
>
> I didn't want to ask you to do this because I felt fortunate enough
> you were volunteering to handle 2.72, but this would indeed be a help,
> because then I won't have to try persuade people they should totally upgrade,
> and it should happen naturally enough with distro upgrades.

To be clear, I am *not* volunteering to do this.  It would be
significantly more work than I can carve out the time for.

Whoever does this will need to go through the *entire* list of changes
since the original 2.69 release, to find all of the changes that improve
compatibility with newer versions of tools, disentangle each from any
other changes applied in the same commit, and then do a whole lot of
testing.  It’s tedious, and whoever does it should get paid to do it.
I’m guessing at least one full 40-hour week of work, and you should
budget for three times that, going by how much more work the 2.70
release was than we anticipated.

I can *advise* anyone who takes on the job, and review their changes,
but that’s it.

zw

Re: How can Autoconf help with the transition to stricter compilation defaults?

[Zack Weinberg via Gcc]

Paul Eggert  writes:

> On 2022-11-10 19:33, Zack Weinberg wrote:
>
>> It would be relatively easy for me to take a couple hours this
>> weekend and put out a 2.72 release with everything that's already in
>> trunk and nothing else.  Anyone have reasons I _shouldn't_ do that?
>
> I don't have anything other than some doc updates, which I just now
> installed (see attached).

couple of notes below

>>> Note that in autoconf git, we've also got
>>> https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60
>>> which is going to affect time_t efforts too
>> I have not been following the y2038 work closely.  Is it going to
>> affect things in a good way or a bad way??
>
> Both. […]

(let’s leave this discussion to the other thread)

> -  and ‘false’ work anyway.  This is for compatibility with C 2023 and
> +  and ‘false’ work anyway.  This is for compatibility with C23 and

Why are you changing four-digit years to two-digit years?  I know you’re
old enough to remember Y2K :-)

>  All other headers, including all headers
>  from later revisions of the C standard, need to be tested for
> +if your program is intended to be portable to C89
>  (@pxref{Header Files}).

I don’t understand what this addition is supposed to mean.  Not all
“modern” systems supply all of the C99 headers, even now.

> -The C standard says a call @code{malloc (0)} is implementation
> +The C standard says a successful call @code{malloc (0)} is implementation
>  dependent.  It can return either @code{NULL} or a new non-null pointer.

Style nit: how can a _call_ be implementation dependent?  Suggest
something like “The C standard says that _the result of_ a successful
call _to_ @code{malloc (0)} is implementation dependent.” (underscores
just to mark additions, not part of suggested text)

zw

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

[Alejandro Colomar via Gcc]

On 11/12/22 14:40, Alejandro Colomar wrote:

Hi Joseph,

On 11/12/22 14:03, Joseph Myers wrote:

On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:


struct s { int a; };
void f(int a, int b[((struct s) { .a = 1 }).a]);


Is it really ambiguous?  Let's show some currently-valid code:


Well, I still don't know what the syntax addition you propose is.  Is it

postfix-expression : . identifier


I'll try to explain it in standardeese, but I'm not sure if I'll get it right, 
so I'll accompany it with plain English.


Maybe Martin can help.

Since it's to be used as an rvalue, not as a lvalue, I guess a 
postfix-expression wouldn't be the right one.




(with a special rule about how the identifier is interpreted, different
from the normal scope rules)?  If so, then ".a = 1" could either match
assignment-expression directly (assigning to the postfix-expression ".a").


No, assigning to a function parameter from within another parameter declaration 
wouldn't make sense.  They should be readonly.  Side effects should be 
forbidden, I think.



Or it could match designation[opt] initializer, where ".a" is a
designator.  And as I've noted many times in discussions of C2x proposals
on the WG14 reflector, if some sequence of tokens can match the syntax in
more than one way, there always needs to be explicit normative text to
disambiguate the intended parse - it's not enough that one parse might
lead later to a violation of some other constraint (not that either parse
leads to a constraint violation in this case).

Or is the syntax

array-declarator : direct-declarator [ . assignment-expression ]


Not good either.  The '.' should prefix the identifier, not the expression.  So, 
for example, you would have:


    void *bsearch(const void key[.size], const void base[.size * .nmemb],
  size_t nmemb, size_t size,
  int (*compar)(const void [.size], const void [.size]));

That's taken from the current manual page from git HEAD.  See 'base', which gets 
its size from the multiplication of 'size' and 'nmemb'.




(with appropriate variants with static and type-qualifier-list and for
array-abstract-declarator as well, and with different identifier
interpretation rules inside the assignment-expression)?  If so, then there
are big problems parsing [ . ( a ) + ( b ) ], where 'a' is a typedef name
in an outer scope, because the appropriate parse would depend on whether
'a' is shadowed by a parameter - unless of course you add appropriate
wording like that present in some places about not being able to use this
syntax to shadow a typedef name.

Or is it just

array-declarator : direct-declarator [ . identifier ]


For the initial implementation, it would be, I think.



which might avoid some of these problems at the expense of being less
expressive?


Yes.



If you're proposing a C syntax addition, you always need to be clear about
exactly what the new cases in the syntax would be, and how you resolve
ambiguities with any other existing part of the syntax, how you interact
with rules on scopes, namespaces and linkage of identifiers, etc.


Yeah, I'll try.

I think that the complete feature would allow 'designator' to be used within 
unary-expression:


unary-expression: designator


Some mistake I did:  Since enum designators don't make sense in this feature, it 
should only be:


unary-expression: . identifier



Since sizeof(foo) is a unary-expression and you can't assign to it, I'm guessing 
that similar rules could be used for '.size'.



That would have the effect of allowing both features suggested by Martin: being 
able to used designators in both structures (as demonstrated in my last email) 
and function prototypes (as in the thing we're discussing).


I hope I got it right.  I'm not used to lexical grammar so much.

Cheers,

Alex




--



OpenPGP_signature
Description: OpenPGP digital signature

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

[Alejandro Colomar via Gcc]

Hi Joseph,

On 11/12/22 14:03, Joseph Myers wrote:

On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:


struct s { int a; };
void f(int a, int b[((struct s) { .a = 1 }).a]);


Is it really ambiguous?  Let's show some currently-valid code:


Well, I still don't know what the syntax addition you propose is.  Is it

postfix-expression : . identifier


I'll try to explain it in standardeese, but I'm not sure if I'll get it right, 
so I'll accompany it with plain English.


Maybe Martin can help.

Since it's to be used as an rvalue, not as a lvalue, I guess a 
postfix-expression wouldn't be the right one.




(with a special rule about how the identifier is interpreted, different
from the normal scope rules)?  If so, then ".a = 1" could either match
assignment-expression directly (assigning to the postfix-expression ".a").


No, assigning to a function parameter from within another parameter declaration 
wouldn't make sense.  They should be readonly.  Side effects should be 
forbidden, I think.



Or it could match designation[opt] initializer, where ".a" is a
designator.  And as I've noted many times in discussions of C2x proposals
on the WG14 reflector, if some sequence of tokens can match the syntax in
more than one way, there always needs to be explicit normative text to
disambiguate the intended parse - it's not enough that one parse might
lead later to a violation of some other constraint (not that either parse
leads to a constraint violation in this case).

Or is the syntax

array-declarator : direct-declarator [ . assignment-expression ]


Not good either.  The '.' should prefix the identifier, not the expression.  So, 
for example, you would have:


   void *bsearch(const void key[.size], const void base[.size * .nmemb],
 size_t nmemb, size_t size,
 int (*compar)(const void [.size], const void [.size]));

That's taken from the current manual page from git HEAD.  See 'base', which gets 
its size from the multiplication of 'size' and 'nmemb'.




(with appropriate variants with static and type-qualifier-list and for
array-abstract-declarator as well, and with different identifier
interpretation rules inside the assignment-expression)?  If so, then there
are big problems parsing [ . ( a ) + ( b ) ], where 'a' is a typedef name
in an outer scope, because the appropriate parse would depend on whether
'a' is shadowed by a parameter - unless of course you add appropriate
wording like that present in some places about not being able to use this
syntax to shadow a typedef name.

Or is it just

array-declarator : direct-declarator [ . identifier ]


For the initial implementation, it would be, I think.



which might avoid some of these problems at the expense of being less
expressive?


Yes.



If you're proposing a C syntax addition, you always need to be clear about
exactly what the new cases in the syntax would be, and how you resolve
ambiguities with any other existing part of the syntax, how you interact
with rules on scopes, namespaces and linkage of identifiers, etc.


Yeah, I'll try.

I think that the complete feature would allow 'designator' to be used within 
unary-expression:


unary-expression: designator

Since sizeof(foo) is a unary-expression and you can't assign to it, I'm guessing 
that similar rules could be used for '.size'.



That would have the effect of allowing both features suggested by Martin: being 
able to used designators in both structures (as demonstrated in my last email) 
and function prototypes (as in the thing we're discussing).


I hope I got it right.  I'm not used to lexical grammar so much.

Cheers,

Alex


--



OpenPGP_signature
Description: OpenPGP digital signature

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

[Joseph Myers]

On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:

> > struct s { int a; };
> > void f(int a, int b[((struct s) { .a = 1 }).a]);
> 
> Is it really ambiguous?  Let's show some currently-valid code:

Well, I still don't know what the syntax addition you propose is.  Is it

postfix-expression : . identifier

(with a special rule about how the identifier is interpreted, different 
from the normal scope rules)?  If so, then ".a = 1" could either match 
assignment-expression directly (assigning to the postfix-expression ".a").  
Or it could match designation[opt] initializer, where ".a" is a 
designator.  And as I've noted many times in discussions of C2x proposals 
on the WG14 reflector, if some sequence of tokens can match the syntax in 
more than one way, there always needs to be explicit normative text to 
disambiguate the intended parse - it's not enough that one parse might 
lead later to a violation of some other constraint (not that either parse 
leads to a constraint violation in this case).

Or is the syntax

array-declarator : direct-declarator [ . assignment-expression ]

(with appropriate variants with static and type-qualifier-list and for 
array-abstract-declarator as well, and with different identifier 
interpretation rules inside the assignment-expression)?  If so, then there 
are big problems parsing [ . ( a ) + ( b ) ], where 'a' is a typedef name 
in an outer scope, because the appropriate parse would depend on whether 
'a' is shadowed by a parameter - unless of course you add appropriate 
wording like that present in some places about not being able to use this 
syntax to shadow a typedef name.

Or is it just

array-declarator : direct-declarator [ . identifier ]

which might avoid some of these problems at the expense of being less 
expressive?

If you're proposing a C syntax addition, you always need to be clear about 
exactly what the new cases in the syntax would be, and how you resolve 
ambiguities with any other existing part of the syntax, how you interact 
with rules on scopes, namespaces and linkage of identifiers, etc.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Alejandro Colomar via Gcc]

On 11/12/22 13:34, Alejandro Colomar wrote:

struct s {
 int a;
};

struct t {
 struct s s;
 int a;
};

void f(void)
{
 struct t x = {
     .a = 1,
     .s = {
     .a = ((struct s) {.a = 1}).a,
     },
 };
}


From here, a demonstration of what I understood from Martin's email is that 
there's also an idea of allowing the following:



struct s {
int a;
int b;
};

struct t {
struct s s;
int a;
int b;
};

void f(void)
{
struct t x = {
.a = 1,
.s = {
// In the following line, .b=.a is assigning 2
.a = ((struct s) {.a = 2, .b = .a}).b,
// The previous line assigned 2, since the compound had 2 in .b
},
// In the following line, .b=.a is assigning 1
.b = .a,
};
}

--



OpenPGP_signature
Description: OpenPGP digital signature

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

[Alejandro Colomar via Gcc]

Hi Joseph,

On 11/11/22 00:19, Joseph Myers wrote:

On Thu, 10 Nov 2022, Martin Uecker via Gcc wrote:


One problem with WG14 papers is that people put in too much,
because the overhead is so high and the standard is not updated
very often.  It would be better to build such feature more
incrementally, which could be done more easily with a compiler
extension.  One could start supporting just [.x] but not more
complicated expressions.


Even a compiler extension requires the level of detail of specification
that you get with a WG14 paper (and the level of work on finding bugs in
that specification), to avoid the problem we've had before with too many
features added in GCC 2.x days where a poorly defined feature is "whatever
the compiler accepts".

If you use .x as the notation but don't limit it to [.x], you have a
completely new ambiguity between ordinary identifiers and member names

struct s { int a; };
void f(int a, int b[((struct s) { .a = 1 }).a]);


Is it really ambiguous?  Let's show some currently-valid code:


struct s {
int a;
};

struct t {
struct s s;
int a;
};

void f(void)
{
struct t x = {
.a = 1,
.s = {
.a = ((struct s) {.a = 1}).a,
},
};
}


It is ambiguous to a human reader, but that's a subjective thing, and of course 
shadowing should be avoided by programmers.  However, for a compiler, scoping 
and syntax rules should be unambiguous, I think.  In your code example, I 
believe it is unambiguous that both '.a' refer to the struct member.


But maybe we're not considering more complex situations that might really be 
ambiguous to the compiler, so a first round of supporting only [.a] would be a 
good first implementation.




where it's newly ambiguous whether ".a = 1" is an assignment to the
expression ".a" or a use of a designated initializer.

(I think that if you add any syntax for this, GNU VLA forward declarations
are clearly to be preferred to inventing something new like [.x] which
introduces its own problems.)



Cheers,

Alex

--



OpenPGP_signature
Description: OpenPGP digital signature

Free software

[Bdazzle McGregor via Gcc]

Sent from my iPhone