[9front] [PATCH] cc: support const and restrict inside array declarations

[9front] [PATCH] cc: support const and restrict inside array declarations

[mia soweli]

this allows c23 style array declarations (see c23 draft section 6.7.6),
with type qualifiers inside the brackets.
for example:

	const int list[restrict 4];
	int list[const 4];
	int list[const restrict 4];
	int list[volatile 4];
	int list[noret 4]; /* we may not want to allow this */

they are ignored as with other uses of const, restrict, and volatile.
it does not allow

	int list[static 4];

which is also allowed in c23.

diff 090af6255bebf0129c891116b53b31808fe49dc7 uncommitted
--- a/sys/src/cmd/cc/cc.y
+++ b/sys/src/cmd/cc/cc.y
@@ -142,9 +142,9 @@
 	{
 		$$ = new(OFUNC, $1, $3);
 	}
-|	xdecor2 '[' zexpr ']'
+|	xdecor2 '[' zgnlist zexpr ']'
 	{
-		$$ = new(OARRAY, $1, $3);
+		$$ = new(OARRAY, $1, $4);
 	}
 
 /*
@@ -273,9 +273,9 @@
 	{
 		$$ = new(OFUNC, $1, $3);
 	}
-|	abdecor2 '[' zexpr ']'
+|	abdecor2 '[' zgnlist zexpr ']'
 	{
-		$$ = new(OARRAY, $1, $3);
+		$$ = new(OARRAY, $1, $4);
 	}
 
 abdecor3:
@@ -283,9 +283,9 @@
 	{
 		$$ = new(OFUNC, (Z), Z);
 	}
-|	'[' zexpr ']'
+|	'[' zgnlist zexpr ']'
 	{
-		$$ = new(OARRAY, (Z), $2);
+		$$ = new(OARRAY, (Z), $3);
 	}
 |	'(' abdecor1 ')'
 	{

Re: [9front] [PATCH] cc: support const and restrict inside array declarations

[ori]

Quoth mia soweli <inbox@tachibana-labs.org>:
> this allows c23 style array declarations (see c23 draft section 6.7.6),
> with type qualifiers inside the brackets.
> for example:
> 
> 	const int list[restrict 4];
> 	int list[const 4];
> 	int list[const restrict 4];
> 	int list[volatile 4];
> 	int list[noret 4]; /* we may not want to allow this */
> 
> they are ignored as with other uses of const, restrict, and volatile.
> it does not allow
> 
> 	int list[static 4];
> 
> which is also allowed in c23.
> 

I'm not sure why this is useful. Is there some specific code
that wants this?

[9front] Re: [9front] [PATCH] cc: support const and restrict inside array declarations

[mia soweli]

i came across code like this updating the netsurf port. i think it was in libcss.

On 14 May 2023 06:25:45 BST, ori@eigenstate.org wrote:
>Quoth mia soweli <inbox@tachibana-labs.org>:
>> this allows c23 style array declarations (see c23 draft section 6.7.6),
>> with type qualifiers inside the brackets.
>> for example:
>> 
>> 	const int list[restrict 4];
>> 	int list[const 4];
>> 	int list[const restrict 4];
>> 	int list[volatile 4];
>> 	int list[noret 4]; /* we may not want to allow this */
>> 
>> they are ignored as with other uses of const, restrict, and volatile.
>> it does not allow
>> 
>> 	int list[static 4];
>> 
>> which is also allowed in c23.
>> 
>
>I'm not sure why this is useful. Is there some specific code
>that wants this?
>

Re: [9front] [PATCH] cc: support const and restrict inside array declarations

[Michael Forney]

On 2023-05-13, mia soweli <inbox@tachibana-labs.org> wrote:
> this allows c23 style array declarations (see c23 draft section 6.7.6),
> with type qualifiers inside the brackets.
> for example:
>
> 	const int list[restrict 4];
> 	int list[const 4];
> 	int list[const restrict 4];
> 	int list[volatile 4];
> 	int list[noret 4]; /* we may not want to allow this */

I have no idea what this is. Maybe you are thinking of noreturn? Even
so, _Noreturn (what noreturn is defined as) is a function-specifier,
not a type-qualifier, and is not allowed in the brackets of an array
declarator in any C standard.

>
> they are ignored as with other uses of const, restrict, and volatile.
> it does not allow
>
> 	int list[static 4];
>
> which is also allowed in c23.

Just FYI, all of the above (except noret, which is nonsense) are valid
in C99. I don't think any of this changed in C23.

See http://port70.net/~nsz/c/c99/n1256.html#6.7.5.2

[9front] Re: [9front] [PATCH] cc: support const and restrict inside array declarations

[mia soweli]

in our c compilers, const, volatile, restrict, and noret fall under the same yacc rule "gname", so by allowing "zgnlist" in array brackets we would also end up allowing int a[noret 4].

it would need some changes to not allow this.

On 14 May 2023 09:10:23 BST, Michael Forney <mforney@mforney.org> wrote:
>On 2023-05-13, mia soweli <inbox@tachibana-labs.org> wrote:
>> this allows c23 style array declarations (see c23 draft section 6.7.6),
>> with type qualifiers inside the brackets.
>> for example:
>>
>> 	const int list[restrict 4];
>> 	int list[const 4];
>> 	int list[const restrict 4];
>> 	int list[volatile 4];
>> 	int list[noret 4]; /* we may not want to allow this */
>
>I have no idea what this is. Maybe you are thinking of noreturn? Even
>so, _Noreturn (what noreturn is defined as) is a function-specifier,
>not a type-qualifier, and is not allowed in the brackets of an array
>declarator in any C standard.
>
>>
>> they are ignored as with other uses of const, restrict, and volatile.
>> it does not allow
>>
>> 	int list[static 4];
>>
>> which is also allowed in c23.
>
>Just FYI, all of the above (except noret, which is nonsense) are valid
>in C99. I don't think any of this changed in C23.
>
>See http://port70.net/~nsz/c/c99/n1256.html#6.7.5.2

[9front] [PATCH] cc: support type qualifiers inside array brackets.

[mia soweli]

allows c99 array declarations with type qualifiers inside the brackets.
for example:

	int list[const 5];
	int list[const restrict 5];
	int list[volatile 5];
	int list[static 5];

i am not sure if the handling of static is correct.

diff 090af6255bebf0129c891116b53b31808fe49dc7 uncommitted
--- a/sys/src/cmd/cc/cc.y
+++ b/sys/src/cmd/cc/cc.y
@@ -27,8 +27,8 @@
 	vlong	vval;
 }
 %type	<sym>	ltag
-%type	<lval>	gctname gcname cname gname tname
-%type	<lval>	gctnlist gcnlist zgnlist
+%type	<lval>	gctname gcname cname gname tname aname
+%type	<lval>	gctnlist gcnlist zgnlist zanlist
 %type	<type>	tlist sbody complex
 %type	<tycl>	types
 %type	<node>	zarglist arglist zcexpr
@@ -142,9 +142,11 @@
 	{
 		$$ = new(OFUNC, $1, $3);
 	}
-|	xdecor2 '[' zexpr ']'
+|	xdecor2 '[' zanlist zexpr ']'
 	{
-		$$ = new(OARRAY, $1, $3);
+		$$ = new(OARRAY, $1, $4);
+		$$->garb = simpleg($3);
+		$$->class = simplec($3);
 	}
 
 /*
@@ -273,9 +275,11 @@
 	{
 		$$ = new(OFUNC, $1, $3);
 	}
-|	abdecor2 '[' zexpr ']'
+|	abdecor2 '[' zanlist zexpr ']'
 	{
-		$$ = new(OARRAY, $1, $3);
+		$$ = new(OARRAY, $1, $4);
+		$$->garb = simpleg($3);
+		$$->class = simplec($3);
 	}
 
 abdecor3:
@@ -283,9 +287,11 @@
 	{
 		$$ = new(OFUNC, (Z), Z);
 	}
-|	'[' zexpr ']'
+|	'[' zanlist zexpr ']'
 	{
-		$$ = new(OARRAY, (Z), $2);
+		$$ = new(OARRAY, (Z), $3);
+		$$->garb = simpleg($2);
+		$$->class = simplec($2);
 	}
 |	'(' abdecor1 ')'
 	{
@@ -1099,6 +1105,15 @@
 		$$ = typebitor($1, $2);
 	}
 
+zanlist:
+	{
+		$$ = 0;
+	}
+|	zanlist aname
+	{
+		$$ = typebitor($1, $2);
+	}
+
 gctname:
 	tname
 |	gname
@@ -1152,6 +1167,12 @@
 |	LVOLATILE { $$ = BVOLATILE; }
 |	LRESTRICT { $$ = 0; }
 |	LNORET { $$ = BNORET; }
+
+aname:	/* words allowed in an array declaration */
+	LCONSTNT { $$ = BCONSTNT; }
+|	LVOLATILE { $$ = BVOLATILE; }
+|	LRESTRICT { $$ = 0; }
+|	LSTATIC { $$ = BSTATIC; }
 
 name:
 	LNAME

[9front] Re: [9front] [PATCH] cc: support type qualifiers inside array brackets.

[mia soweli]

allows c99 array declarations with type qualifiers inside the brackets.
for example:

	int list[const 5];
	int list[const restrict 5];
	int list[volatile 5];
	int list[static 5];

i read the standard more closely, the static seems to be an optimization thing that means the array has *at least* however many members, and we should ignore it instead of treating it like static outside the brackets.

diff 090af6255bebf0129c891116b53b31808fe49dc7 uncommitted
--- a/sys/src/cmd/cc/cc.y
+++ b/sys/src/cmd/cc/cc.y
@@ -27,8 +27,8 @@
	vlong	vval;
}
%type	<sym>	ltag
-%type	<lval>	gctname gcname cname gname tname
-%type	<lval>	gctnlist gcnlist zgnlist
+%type	<lval>	gctname gcname cname gname tname aname
+%type	<lval>	gctnlist gcnlist zgnlist zanlist
%type	<type>	tlist sbody complex
%type	<tycl>	types
%type	<node>	zarglist arglist zcexpr
@@ -142,9 +142,11 @@
	{
		$$ = new(OFUNC, $1, $3);
	}
-|	xdecor2 '[' zexpr ']'
+|	xdecor2 '[' zanlist zexpr ']'
	{
-		$$ = new(OARRAY, $1, $3);
+		$$ = new(OARRAY, $1, $4);
+		$$->garb = simpleg($3);
	}

/*
@@ -273,9 +275,11 @@
	{
		$$ = new(OFUNC, $1, $3);
	}
-|	abdecor2 '[' zexpr ']'
+|	abdecor2 '[' zanlist zexpr ']'
	{
-		$$ = new(OARRAY, $1, $3);
+		$$ = new(OARRAY, $1, $4);
+		$$->garb = simpleg($3);
	}

abdecor3:
@@ -283,9 +287,11 @@
	{
		$$ = new(OFUNC, (Z), Z);
	}
-|	'[' zexpr ']'
+|	'[' zanlist zexpr ']'
	{
-		$$ = new(OARRAY, (Z), $2);
+		$$ = new(OARRAY, (Z), $3);
+		$$->garb = simpleg($2);
	}
|	'(' abdecor1 ')'
	{
@@ -1099,6 +1105,15 @@
		$$ = typebitor($1, $2);
	}

+zanlist:
+	{
+		$$ = 0;
+	}
+|	zanlist aname
+	{
+		$$ = typebitor($1, $2);
+	}
+
gctname:
	tname
|	gname
@@ -1152,6 +1167,12 @@
|	LVOLATILE { $$ = BVOLATILE; }
|	LRESTRICT { $$ = 0; }
|	LNORET { $$ = BNORET; }
+
+aname:	/* words allowed in an array declaration */
+	LCONSTNT { $$ = BCONSTNT; }
+|	LVOLATILE { $$ = BVOLATILE; }
+|	LRESTRICT { $$ = 0; }
+|	LSTATIC { $$ = BSTATIC; }

name:
	LNAME

Re: [9front] Re: [9front] [PATCH] cc: support type qualifiers inside array brackets.

[ori]

Quoth mia soweli <inbox@tachibana-labs.org>:
> allows c99 array declarations with type qualifiers inside the brackets.
> for example:
> 
> 	int list[const 5];
> 	int list[const restrict 5];
> 	int list[volatile 5];
> 	int list[static 5];
> 
> i read the standard more closely, the static seems to be an optimization thing that means the array has *at least* however many members, and we should ignore it instead of treating it like static outside the brackets.
> 

the patch looks fine, but the feature seems idiotic.

I wonder if it's more reasonable to just patch it out
and send the patch to upstream.

[9front] Re: [9front] Re: [9front] [PATCH] cc: support type qualifiers inside array brackets.

[mia soweli]

>the patch looks fine, but the feature seems idiotic.
yeah.

>I wonder if it's more reasonable to just patch it out and send the patch to upstream.
in the netsurf case we can just #define restrict, but for static that's not really an option.
i haven't come across much else that needs this, so it might not be worth the patch.

on the other hand, it's not a very significant code change, it might be good to just include it to be slightly more c99 compatible.

whichever seems best.