On Sat, 3 Dec 2022, Alejandro Colomar via Gcc wrote:
> What do you think about it? I'm not asking for your opinion about adding it
> to GCC, but rather for replacing the current '.' in the man-pages before I
> release later this month. Do you think I should apply that change?
I think man pages
Hi Martin and Andrew!
On 12/3/22 22:15, Martin Uecker wrote:
Am Samstag, dem 03.12.2022 um 22:03 +0100 schrieb Alejandro Colomar:
...
Since we've seen that using a '.' prefix seems to be problematic
because of lookahead, and recently Michael Matz proposed using a
different punctuator (he propos
Am Samstag, dem 03.12.2022 um 22:03 +0100 schrieb Alejandro Colomar:
...
> Since we've seen that using a '.' prefix seems to be problematic
> because of lookahead, and recently Michael Matz proposed using a
> different punctuator (he proposed '@') for differentiating parameters
> from struct member
On Sat, Dec 3, 2022 at 1:05 PM Alejandro Colomar via Gcc
wrote:
>
> Hi!
>
> I'll probably have to release again before the Debian freeze of Bookworm.
> That's something I didn't want to do, but there's some important bug that
> affects downstream projects (translation pages), and I need to release
Hi!
I'll probably have to release again before the Debian freeze of Bookworm.
That's something I didn't want to do, but there's some important bug that
affects downstream projects (translation pages), and I need to release. It's a
bit weird that the bug has been reported now, because it has a
On 11/29/22 18:19, Alex Colomar wrote:
Hi Martin, Joseph,
On 11/29/22 18:00, Martin Uecker wrote:
Am Dienstag, dem 29.11.2022 um 16:53 + schrieb Jonathan Wakely:
On Tue, 29 Nov 2022 at 16:49, Joseph Myers wrote:
On Tue, 29 Nov 2022, Michael Matz via Gcc wrote:
like. But I'm generally
Hi Martin and Michael,
On 11/29/22 17:58, Uecker, Martin wrote:
Hi,
Am Dienstag, dem 29.11.2022 um 15:44 + schrieb Michael Matz:
Hey,
On Tue, 29 Nov 2022, Uecker, Martin wrote:
It does not require any changes on how arrays are represented.
As part of VM-types the size becomes part of
Hi Martin, Joseph,
On 11/29/22 18:00, Martin Uecker wrote:
Am Dienstag, dem 29.11.2022 um 16:53 + schrieb Jonathan Wakely:
On Tue, 29 Nov 2022 at 16:49, Joseph Myers wrote:
On Tue, 29 Nov 2022, Michael Matz via Gcc wrote:
like. But I'm generally doubtful of this whole feature within C
Am Dienstag, dem 29.11.2022 um 16:53 + schrieb Jonathan Wakely:
> On Tue, 29 Nov 2022 at 16:49, Joseph Myers wrote:
> >
> > On Tue, 29 Nov 2022, Michael Matz via Gcc wrote:
> >
> > > like. But I'm generally doubtful of this whole feature within C
> > > itself.
> > > It serves a purpose in do
Hi,
Am Dienstag, dem 29.11.2022 um 15:44 + schrieb Michael Matz:
> Hey,
>
> On Tue, 29 Nov 2022, Uecker, Martin wrote:
>
> > It does not require any changes on how arrays are represented.
> >
> > As part of VM-types the size becomes part of the type and this
> > can be used for static or d
On Tue, 29 Nov 2022 at 16:49, Joseph Myers wrote:
>
> On Tue, 29 Nov 2022, Michael Matz via Gcc wrote:
>
> > like. But I'm generally doubtful of this whole feature within C itself.
> > It serves a purpose in documentation, so in man-pages it seems fine enough
> > (but then still could use a differ
On Tue, 29 Nov 2022, Michael Matz via Gcc wrote:
> like. But I'm generally doubtful of this whole feature within C itself.
> It serves a purpose in documentation, so in man-pages it seems fine enough
> (but then still could use a different puncuator to not be confusable with
> C syntax).
In
Hey,
On Tue, 29 Nov 2022, Uecker, Martin wrote:
> It does not require any changes on how arrays are represented.
>
> As part of VM-types the size becomes part of the type and this
> can be used for static or dynamic analysis, e.g. you can
> - today - get a run-time bounds violation with the san
Am Dienstag, dem 29.11.2022 um 14:58 + schrieb Michael Matz:
> Hey,
>
> On Tue, 29 Nov 2022, Alex Colomar via Gcc wrote:
>
> > How about the compiler parsing the parameter list twice?
>
> This _is_ unbounded look-ahead. You could avoid this by using "."
> for
> your new syntax. Use someth
Hey,
On Tue, 29 Nov 2022, Alex Colomar via Gcc wrote:
> How about the compiler parsing the parameter list twice?
This _is_ unbounded look-ahead. You could avoid this by using "." for
your new syntax. Use something unambiguous that can't be confused with
other syntactic elements, e.g. with a
On Tue, 29 Nov 2022, Alex Colomar via Gcc wrote:
> I guess asking the compiler to do two passes on the param list isn't as bad as
> asking to do unbound lookahead. In this case it's bound: look ahead till the
> end of the param list; get as much info as possible, and then do it again to
> comple
Hi Martin,
On 11/13/22 15:58, Martin Uecker wrote:
Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
On 11/13/22 14:33, Alejandro Colomar wrote:
Hi Martin,
On 11/13/22 14:19, Alejandro Colomar wrote:
But there are not only syntactical problems, because
also the type of the
Hi Joseph,
On 11/14/22 19:26, Joseph Myers wrote:
On Mon, 14 Nov 2022, Alejandro Colomar via Gcc wrote:
To quote the convenor in WG14 reflector message 18575 (17 Nov
2020) when I asked about its status, "The author asked me not to put those
on the agenda. He will supply updated versions later
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-expressi
On Mon, 14 Nov 2022, Alejandro Colomar via Gcc wrote:
> > To quote the convenor in WG14 reflector message 18575 (17 Nov
> > 2020) when I asked about its status, "The author asked me not to put those
> > on the agenda. He will supply updated versions later.".
>
> Since his email is not in the pap
On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:
> SYNOPSIS:
>
> unary-operator: . identifier
That's not what you mean. See the standard syntax.
unary-expression:
[other alternatives]
unary-operator cast-expression
unary-operator: one of
& * + - ~ !
> - It is not an lvalue.
>
>
Hi Joseph!
On 11/14/22 18:52, Joseph Myers wrote:
On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:
Maybe allowing integral types and pointers would be enough. However,
foreseeing that the _Lengthof() proposal (BTW, which paper was it?) will
succeed, and combining it with this one, _Lengt
On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:
> Maybe allowing integral types and pointers would be enough. However,
> foreseeing that the _Lengthof() proposal (BTW, which paper was it?) will
> succeed, and combining it with this one, _Lengthof(pointer) would ideally give
> the length of
On 11/13/22 17:56, Alejandro Colomar wrote:>>> On 11/13/22 17:28, Alejandro
Colomar wrote:
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
Sorry, the above is a thinko.
I wanted to say that,
On 11/13/22 17:34, Alejandro Colomar wrote:
On 11/13/22 17:31, Alejandro Colomar wrote:
On 11/13/22 17:28, Alejandro Colomar wrote:
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
Sor
On 11/13/22 17:31, Alejandro Colomar wrote:
On 11/13/22 17:28, Alejandro Colomar wrote:
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
Sorry, the above is a thinko.
I wanted to say tha
On 11/13/22 17:28, Alejandro Colomar wrote:
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
Sorry, the above is a thinko.
I wanted to say that, like sizeof() and _Lengthof(), you can't ass
SYNOPSIS:
unary-operator: . identifier
DESCRIPTION:
- It is not an lvalue.
- This means sizeof() and _Lengthof() cannot be applied to them.
- This prevents ambiguity with a designator in an initializer-list within a
nested braced-initializer.
- The type of a .identifier is alway
Hi Martin,
On 11/13/22 16:32, Martin Uecker wrote:
Am Sonntag, den 13.11.2022, 16:15 +0100 schrieb Alejandro Colomar:
Hi Martin,
On 11/13/22 15:58, Martin Uecker wrote:
Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
On 11/13/22 14:33, Alejandro Colomar wrote:
On 11/13/22
Am Sonntag, den 13.11.2022, 16:15 +0100 schrieb Alejandro Colomar:
> Hi Martin,
>
> On 11/13/22 15:58, Martin Uecker wrote:
> > Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
> > > On 11/13/22 14:33, Alejandro Colomar wrote:
> > > > On 11/13/22 14:19, Alejandro Colomar wrote:
>
Hi Martin,
On 11/13/22 15:58, Martin Uecker wrote:
Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
On 11/13/22 14:33, Alejandro Colomar wrote:
On 11/13/22 14:19, Alejandro Colomar wrote:
But there are not only syntactical problems, because
also the type of the parameter m
Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:
>
> On 11/13/22 14:33, Alejandro Colomar wrote:
> > Hi Martin,
> >
> > On 11/13/22 14:19, Alejandro Colomar wrote:
> > > > But there are not only syntactical problems, because
> > > > also the type of the parameter might become re
On 11/13/22 14:33, Alejandro Colomar wrote:
Hi Martin,
On 11/13/22 14:19, Alejandro Colomar wrote:
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)[s
Hi Martin,
On 11/13/22 14:19, Alejandro Colomar wrote:
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]);
This seems to be a difficult sto
Hi Martin!
On 11/12/22 16:56, Martin Uecker wrote:
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 o
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 alread
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 fu
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.
>
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 ab
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
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,
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
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 : .
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
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
incrementa
Am Samstag, den 12.11.2022, 01:09 + schrieb Joseph Myers:
> On Fri, 11 Nov 2022, Martin Uecker via Gcc wrote:
>
> > > 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 specificatio
On Fri, 11 Nov 2022, Martin Uecker via Gcc wrote:
> > 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 ad
Am Donnerstag, den 10.11.2022, 23:19 + schrieb Joseph Myers:
> 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 s
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
incrementa
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 co
Hi Alex,
At 2022-11-10T11:59:02+0100, Alejandro Colomar wrote:
> > You know what Moltke said about plans and contact with the enemy.
> > For one thing, I think the Linux kernel will move too fast to permit
> > such a leisurely cadence.
>
> Heh, at this point, I burnt my ships, by using enhanced V
Hi Branden!
On 11/10/22 10:40, G. Branden Robinson wrote:
Hi Alex,
At 2022-11-10T01:06:31+0100, Alejandro Colomar wrote:
Now, I've released man-pages-6.01 very recently (just a few weeks
ago), and I don't plan to release again in a year or two, so there's
time to do the implementation in GCC.
Hi Joseph and Martin!
On 11/10/22 07:21, Martin Uecker wrote:
Am Donnerstag, den 10.11.2022, 01:39 + schrieb Joseph Myers:
On Thu, 10 Nov 2022, Joseph Myers wrote:
On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote:
I've shown the three kinds of prototypes that have been changed:
-
Hi Alex,
At 2022-11-10T01:06:31+0100, Alejandro Colomar wrote:
> Now, I've released man-pages-6.01 very recently (just a few weeks
> ago), and I don't plan to release again in a year or two, so there's
> time to do the implementation in GCC. From my side, please consider
> this an ACK or even som
Am Donnerstag, den 10.11.2022, 01:39 + schrieb Joseph Myers:
> On Thu, 10 Nov 2022, Joseph Myers wrote:
>
> > On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote:
> >
> > > I've shown the three kinds of prototypes that have been changed:
> > >
> > > - Normal VLA; nothing fancy except for t
On Thu, 10 Nov 2022, Joseph Myers wrote:
> On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote:
>
> > I've shown the three kinds of prototypes that have been changed:
> >
> > - Normal VLA; nothing fancy except for the '.'.
> > - Complex size expressions.
> > - 'void *' VLAs (assuming GNU con
On Thu, 10 Nov 2022, Alejandro Colomar via Gcc wrote:
> I've shown the three kinds of prototypes that have been changed:
>
> - Normal VLA; nothing fancy except for the '.'.
> - Complex size expressions.
> - 'void *' VLAs (assuming GNU conventions: sizeof(void *)==1).
That doesn't cover any of
On 11/10/22 01:06, Alejandro Colomar wrote:
Hi Martin,
On 9/3/22 17:31, Martin Uecker wrote:
My experience is that if one wants to see something fixed,
one has to push for it. Standardization is meant
to standardize existing practice, so if we want to see
this improved, we can not wait for t
Hi Martin,
On 9/3/22 17:31, Martin Uecker wrote:
My experience is that if one wants to see something fixed,
one has to push for it. Standardization is meant
to standardize existing practice, so if we want to see
this improved, we can not wait for this.
I fully agree with you. I've been rumin
Hi Martin,
On 9/3/22 22:02, Alejandro Colomar wrote:
We thought about using this syntax
int foo(char buf[.n], int n);
BTW, it would be useful if this syntax was accepted for void * too,
especially since GNU C allows pointer arithmetic on void *.
void *memmove(void dest[.n], const void
Hi Martin,
On 9/3/22 17:31, Martin Uecker wrote:
[...]
But the recent discussion about presenting
nonnull pointers as [static 1] is horrible. But let's wait till the
future hopefully fixes this.
yes, [static 1] is problematic because then the number
can not be used as a bound anymore.
My ex
Hi Alejandro,
Am Samstag, den 03.09.2022, 16:59 +0200 schrieb Alejandro Colomar:
> Hi Martin,
>
> On 9/3/22 16:35, Martin Uecker wrote:
> > Am Samstag, den 03.09.2022, 15:41 +0200 schrieb Alejandro Colomar:
> > > Hi Martin,
> > >
> > > On 9/3/22 14:47, Martin Uecker wrote:
> > > [...]
> > >
> >
Hi Ingo,
On 9/3/22 15:29, Ingo Schwarze wrote:
the only point i strongly care about is this one:
Manual pages should not use
* non-standard syntax
* non-portable syntax
* ambiguous syntax (i.e. syntax that might have different meanings
with different compilers or in different contexts
Hi Martin,
On 9/3/22 16:35, Martin Uecker wrote:
Am Samstag, den 03.09.2022, 15:41 +0200 schrieb Alejandro Colomar:
Hi Martin,
On 9/3/22 14:47, Martin Uecker wrote:
[...]
GCC will warn if the bound is specified inconsistently between
declarations and also emit warnings if it can see that a b
Am Samstag, den 03.09.2022, 15:41 +0200 schrieb Alejandro Colomar:
> Hi Martin,
>
> On 9/3/22 14:47, Martin Uecker wrote:
> [...]
>
> > GCC will warn if the bound is specified inconsistently between
> > declarations and also emit warnings if it can see that a buffer
> > which is passed is too sma
Hi Martin,
On 9/3/22 14:47, Martin Uecker wrote:
[...]
GCC will warn if the bound is specified inconsistently between
declarations and also emit warnings if it can see that a buffer
which is passed is too small:
https://godbolt.org/z/PsjPG1nv7
That's very good news!
BTW, it's nice to see th
Hi,
the only point i strongly care about is this one:
Manual pages should not use
* non-standard syntax
* non-portable syntax
* ambiguous syntax (i.e. syntax that might have different meanings
with different compilers or in different contexts)
* syntax that might be invalid or dangerous wi
...
> >
> >Whether or not you feel like the manpages are the best place to
> > start that, I'll leave up to you!
>
> I'll try to defend the reasons to start this in the man-pages.
>
> This feature is mostly for documentation purposes, not being meaningful
> for code at all (for some me
Hi JeanHeyd,
Subject: Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in
function parameters
Date: Fri, 2 Sep 2022 16:56:00 -0400
From: JeanHeyd Meneide
To: Alejandro Colomar
CC: Ingo Schwarze , linux-...@vger.kernel.org
Hi Alejandro and Ingo,
Just chiming
69 matches
Mail list logo
