On Thu, Nov 2, 2023 at 1:00 AM Richard Biener
wrote:
>
> On Wed, Nov 1, 2023 at 3:47 PM Qing Zhao wrote:
> >
> >
> >
> > > On Oct 31, 2023, at 6:14 PM, Joseph Myers wrote:
> > >
> > > On Tue, 31 Oct 2023, Qing Zhao wrote:
> > >
> > >> 2.3 A new semantic requirement in the user documentation of "
On Thu, Nov 2, 2023 at 1:36 PM Qing Zhao wrote:
>
> Thanks a lot for raising these issues.
>
> If I understand correctly, the major question we need to answer is:
>
> For the following example: (Jakub mentioned this in an early message)
>
> 1 struct S { int a; char b __attribute__((counted_by
On Tue, Aug 20, 2024 at 6:41 AM Qing Zhao wrote:
> > On Aug 20, 2024, at 05:58, Richard Biener
> > wrote:
> >
> > On Tue, Aug 13, 2024 at 5:34 PM Qing Zhao wrote:
> >>
> >> With the addition of the 'counted_by' attribute and its wide roll-out
> >> within the Linux kernel, a use case has been fo
On Wed, Aug 21, 2024 at 10:44 AM Kees Cook wrote:
>
> On Wed, Aug 21, 2024 at 03:27:56PM +, Qing Zhao wrote:
> > > On Aug 21, 2024, at 10:45, Martin Uecker wrote:
> > >
> > > Am Mittwoch, dem 21.08.2024 um 16:34 +0200 schrieb Martin Uecker:
> > >> Am Mittwoch, dem 21.08.2024 um 14:12 + sc
On Wed, Aug 21, 2024 at 10:52 AM Qing Zhao wrote:
> > On Aug 21, 2024, at 11:43, Martin Uecker wrote:
> > Am Mittwoch, dem 21.08.2024 um 15:24 + schrieb Qing Zhao:
> >>>
> >>> But if we changed it to return a void pointer, we could make this
> >>> a compile-time check:
> >>>
> >>> auto ret =
On Wed, Aug 21, 2024 at 2:54 PM Bill Wendling wrote:
>
> On Wed, Aug 21, 2024 at 10:44 AM Kees Cook wrote:
> >
> > On Wed, Aug 21, 2024 at 03:27:56PM +, Qing Zhao wrote:
> > > > On Aug 21, 2024, at 10:45, Martin Uecker wrote:
> > > >
> >
On Wed, Aug 21, 2024 at 8:43 AM Martin Uecker wrote:
>
> Am Mittwoch, dem 21.08.2024 um 15:24 + schrieb Qing Zhao:
> > >
> > > But if we changed it to return a void pointer, we could make this
> > > a compile-time check:
> > >
> > > auto ret = __builtin_get_counted_by(__p->FAM);
> > >
> > > _
On Thu, Aug 22, 2024 at 8:03 AM Qing Zhao wrote:
> > On Aug 21, 2024, at 18:08, Bill Wendling wrote:
> >> For the unary operator __counted_by(PTR), “PTR” must have a counted_by
> >> attribute, if not, there will be a compilation time error.
> >>
> >&g
On Tue, Aug 27, 2024 at 6:58 AM Qing Zhao wrote:
> > On Aug 27, 2024, at 02:17, Martin Uecker wrote:
> > Am Montag, dem 26.08.2024 um 17:21 -0700 schrieb Kees Cook:
> >> On Mon, Aug 26, 2024 at 11:01:08PM +0200, Martin Uecker wrote:
> >>> Am Montag, dem 26.08.2024 um 13:30 -0700 schrieb Kees Cook
Hi Qing,
Sorry for my late reply.
On Thu, Aug 29, 2024 at 7:22 AM Qing Zhao wrote:
>
> Hi,
>
> Thanks for the information.
>
> Yes, providing a unary operator similar as __counted_by(PTR) as suggested by
> multiple people previously is a cleaner approach.
>
> Then the programmer will use the fo
On Fri, Sep 6, 2024 at 12:32 PM Martin Uecker wrote:
>
> Am Freitag, dem 06.09.2024 um 13:59 + schrieb Qing Zhao:
> >
> > > On Sep 5, 2024, at 18:22, Bill Wendling wrote:
> > >
> > > Hi Qing,
> > >
> > > Sorry for my late reply.
>
On Fri, Sep 6, 2024 at 10:50 PM Martin Uecker wrote:
>
> Am Freitag, dem 06.09.2024 um 13:59 -0700 schrieb Bill Wendling:
> > On Fri, Sep 6, 2024 at 12:32 PM Martin Uecker wrote:
> > >
> > > Am Freitag, dem 06.09.2024 um 13:59 + schrieb Qing Zhao:
> > &g
long history of hating compiler
warnings, even in cases where they explicitly *ask* for the warnings,
so it's not likely to run into a NACK or anything...
> thanks.
>
> Qing
> > On Sep 6, 2024, at 16:59, Bill Wendling wrote:
> >
> > On Fri, Sep 6, 2024 at 12:32 PM
On Fri, Sep 6, 2024 at 11:16 PM Martin Uecker wrote:
>
> Am Samstag, dem 07.09.2024 um 00:12 + schrieb Qing Zhao:
> > Now, if
> >
> > 1. __builtin_get_counted_by should return a LVALUE instead of a pointer
> > (required by CLANG’s design)
> > And
> > 2. It’s better not to change the behavior
On Sun, Sep 8, 2024 at 3:07 AM Martin Uecker wrote:
>
> Am Sonntag, dem 08.09.2024 um 02:09 -0700 schrieb Bill Wendling:
> > On Fri, Sep 6, 2024 at 10:50 PM Martin Uecker wrote:
> > >
> > > Am Freitag, dem 06.09.2024 um 13:59 -0700 schrieb Bill Wendling:
> >
On Wed, Sep 11, 2024 at 2:13 PM Qing Zhao wrote:
>
> compared to the 4th version, the changes are (address Jacub's concerns):
>
> 1. change the global "in_builtin_counted_by_ref" from a boolean to an int;
> 2. delete the label for the error handling code, and decress the global
>"in_builtin_co
On Thu, Dec 5, 2024 at 2:37 PM Martin Uecker wrote:
>
> Am Donnerstag, dem 05.12.2024 um 14:28 -0800 schrieb Bill Wendling:
> > On Thu, Dec 5, 2024 at 1:09 PM Qing Zhao wrote:
> > > > On Dec 3, 2024, at 10:29, Qing Zhao wrote:
> > > > > On Dec
On Thu, Dec 5, 2024 at 2:28 PM Bill Wendling wrote:
> On Thu, Dec 5, 2024 at 1:09 PM Qing Zhao wrote:
> > > On Dec 3, 2024, at 10:29, Qing Zhao wrote:
> > >> On Dec 3, 2024, at 10:07, Martin Uecker wrote:
> > >> The language extension does not exist yet, s
On Thu, Dec 12, 2024 at 1:28 PM Martin Uecker wrote:
>
> Am Montag, dem 09.12.2024 um 16:20 + schrieb Qing Zhao:
> >
> > > On Dec 7, 2024, at 03:57, Martin Uecker wrote:
> > >
> > > Am Freitag, dem 06.12.2024 um 16:13 + schrieb Qing Zhao:
> > > >
> > > > > On Dec 6, 2024, at 10:56, Martin
On Thu, Dec 5, 2024 at 1:09 PM Qing Zhao wrote:
> > On Dec 3, 2024, at 10:29, Qing Zhao wrote:
> >> On Dec 3, 2024, at 10:07, Martin Uecker wrote:
> >> The language extension does not exist yet, so there is no problem.
> > Yeah, I should mention this as “corresponding future language extension”
On Tue, Jan 21, 2025 at 10:40 AM Joseph Myers wrote:
> On Tue, 21 Jan 2025, Qing Zhao wrote:
> > So, even after we introduce the designator syntax for counted_by attribute,
> > arbitrary expressions as:
> >
> > counted_by (.len1 + const)
> > counted_by (.len1 + .len2)
> >
> > Still cannot be sup
On Fri, Jan 17, 2025 at 8:20 AM Qing Zhao wrote:
>
> Hi, Bill,
>
> Thanks a lot for your testing case.
>
> I studied this testing case and realized that we need to decide
> what’s the expected behavior for the following situation:
>
> struct bar;
>
> struct a {
>int dummy;
>struct bar *arr
gt;>
> >> Although in the previous discussion, I agreed with Martin that we should
> >> use the
> >> designator syntax (i.e, counted_by (.n) instead of counted_by (n)) for the
> >> counted_by attribute for pointer fields, after more consideration and
> >
On Fri, Jan 17, 2025 at 3:14 PM Joseph Myers wrote:
>
> On Fri, 17 Jan 2025, Qing Zhao wrote:
>
> > struct fc_bulk {
> > ...
> > struct fs_bulk fs_bulk;
> > struct fc fcs[] __counted_by(fs_bulk.len);
> > };
> >
> > i.e, the “counted_by” field is in the inner structure of the current
> > st
On Thu, Jan 16, 2025 at 3:06 PM Qing Zhao wrote:
> > On Jan 16, 2025, at 17:29, Bill Wendling wrote:
> >
> > On Thu, Jan 16, 2025 at 1:19 PM Qing Zhao wrote:
> >>
> >> Hi,
> >>
> >> This is the patch set to extend "counted_by"
;p->array', and 'ref2' uses 'val2' as the number of elements in
> 'p->array'. "
>
> Although in the previous discussion, I agreed with Martin that we should use
> the
> designator syntax (i.e, counted_by (.n) instead of counted_by (
On Thu, Apr 3, 2025 at 9:54 AM Kees Cook wrote:
> On Wed, Apr 02, 2025 at 09:16:47PM +, Qing Zhao wrote:
> > Hi, Bill,
> >
> > Thanks for the summary.
> >
> > I think that this is good.
> >
> > Two more questions:
> >
> > 1. Shall we keep the same name of the attribute counted_by for the 2nd n
I'd like to offer up this to solve the issues we're facing. This is a
combination of everything that's been discussed here (or at least that
I've been able to read in the centi-thread :-).
---
1. The use of '__self' isn't feasible, so we won't use it. Instead,
we'll rely upon the current behavior
On Fri, Apr 4, 2025, 12:23 PM Qing Zhao wrote:
>
>
> > On Apr 4, 2025, at 13:09, Martin Uecker wrote:
> >
> > Am Freitag, dem 04.04.2025 um 18:51 +0200 schrieb Michael Matz:
> >> Hello,
> >>
> >> On Fri, 4 Apr 2025, Qing Zhao wrote:
> >>
> >>> So, a different attribute name “counted_by_exp” migh
On Tue, Apr 1, 2025 at 5:41 AM Michael Matz wrote:
>
> Hello,
>
> On Mon, 31 Mar 2025, Bill Wendling wrote:
>
> > 1. The use of '__self' isn't feasible, so we won't use it.
>
> That's a bold statement. How's that? The only thing I read h
t *buf __counted_by_expr(size_t len; len << FOO);
int len;
};
The 'len' from the macro expansion will use the 'len' in the struct,
which may not be what was intended, but would nevertheless be quietly
accepted.
-bw
> Thanks.
>
> Qing
> > On Apr 14, 20
SAfter being on a mini-vacation and thinking about this more,
I'm a bit less satisfied with the current proposal. The main issue is
that we have seemingly two lookup rules based on which attribute is
used (counted_by vs. counted_by_expr).
1. counted_by: We expect an expression that's a l
Here is the proposal on the Clang Discourse:
https://discourse.llvm.org/t/rfc-bounds-safety-in-c-syntax-compatibility-with-gcc/85885
-bw
On Thu, Apr 24, 2025 at 8:15 AM Qing Zhao wrote:
>
> Hi,
>
> Kees reported a segmentation failure when he used the patch to compiler
> kernel,
> and the reduced the testing case is something like the following:
>
> struct f {
> void *g __attribute__((__counted_by__(h)));
> long h;
> };
>
> exte
[sorry for hijacking this thread]
Does anyone have any response to Yeoul Na's suggestion to hold off on
implementing __counted_by_expr() until the next C standards committee?
https://discourse.llvm.org/t/rfc-bounds-safety-in-c-syntax-compatibility-with-gcc/85885/17?u=void
I'm fine with it, bu
On Thu, Apr 24, 2025 at 4:56 PM Kees Cook wrote:
> On April 24, 2025 1:44:23 PM PDT, Qing Zhao wrote:
> >> On Apr 24, 2025, at 15:43, Bill Wendling wrote:
> >>
> >> On Thu, Apr 24, 2025 at 8:15 AM Qing Zhao wrote:
> >>>
> >>> Hi,
> &g
On Tue, Apr 15, 2025 at 5:50 AM Michael Matz wrote:
>
> Hello,
>
> On Mon, 14 Apr 2025, Bill Wendling wrote:
>
> > Now, I don't think this will be necessarily confusing to the
> > programmer, but it's inconsistent. In other words, either 'counted_by&#x
On Thu, Mar 6, 2025 at 4:28 PM Yeoul Na wrote:
>
> Hi Qing,
>
> Thanks for writing up the RFC and keeping us in the loop. Are you planning to
> add “__self.” to GCC's C++ compiler as well in the future? The problem we
> have with “__self” being a default way of annotating bounds is that C++
> c
On Mon, Mar 10, 2025 at 11:33 PM Henrik Olsson wrote:
>
>
>
> On Mar 10, 2025, at 11:04 PM, Martin Uecker wrote:
>
> Am Montag, dem 10.03.2025 um 19:30 -0400 schrieb John McCall:
>
> On 10 Mar 2025, at 18:30, Martin Uecker wrote:
>
> Am Montag, dem 10.03.2025 um 16:45 -0400 schrieb John McCall:
>
On Wed, Mar 12, 2025 at 3:28 PM Yeoul Na wrote:
> > On Mar 12, 2025, at 2:51 PM, John McCall wrote:
> >
> > On 12 Mar 2025, at 16:02, Bill Wendling wrote:
> >> Qing pointed out in four lines of code how there are two different
> >> token resolution rules being
On Fri, Apr 4, 2025 at 8:55 AM Michael Matz wrote:
>
> Hello,
>
> On Fri, 4 Apr 2025, Qing Zhao wrote:
>
> > A:
> > constexpr int len = 20;
> > struct s {
> > int len;
> > int *buf __attribute__ ((counted_by (len))); // this continues to be
> > member ‘len’, not global ‘len'
> > };
> >
> > B:
On Fri, Apr 4, 2025 at 10:09 AM Martin Uecker wrote:
>
> Am Freitag, dem 04.04.2025 um 18:51 +0200 schrieb Michael Matz:
> > Hello,
> >
> > On Fri, 4 Apr 2025, Qing Zhao wrote:
> >
> > > So, a different attribute name “counted_by_exp” might be better?
> >
> > I would prefer Martins empty-decl idea
On Tue, Apr 1, 2025 at 11:49 PM Jakub Jelinek wrote:
> On Tue, Apr 01, 2025 at 05:13:46PM -0700, Bill Wendling wrote:
> > On Tue, Apr 1, 2025 at 8:29 AM Martin Uecker wrote:
> > > Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zhao:
> > > > > On Apr
On Tue, Apr 1, 2025 at 8:29 AM Martin Uecker wrote:
> Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zhao:
> > > On Apr 1, 2025, at 10:04, Martin Uecker wrote:
> > > Am Montag, dem 31.03.2025 um 13:59 -0700 schrieb Bill Wendling:
> > > > > I'd
I posted this on the LLVM Discourse forum[1] and got some traction, so
I want to get the GCC community's input. (My initial proposal is
replicated here.)
I had already mentioned this in previous emails in this thread, so
it's nothing super new, and there have been some suggested
improvements alrea
n support generalized expressions in
attributes at some point?) And the first part is patronizing and
blatantly wrong.
-bw
On Wed, Jun 25, 2025 at 1:37 PM Bill Wendling wrote:
>
> I posted this on the LLVM Discourse forum[1] and got some traction, so
> I want to get the GCC community
On Wed, Jun 25, 2025 at 1:37 PM Bill Wendling wrote:
>
> I posted this on the LLVM Discourse forum[1] and got some traction, so
> I want to get the GCC community's input. (My initial proposal is
> replicated here.)
>
> I had already mentioned this in previous emails in
On Mon, Jul 21, 2025 at 2:19 PM Martin Uecker wrote:
> Am Montag, dem 21.07.2025 um 04:29 -0700 schrieb Bill Wendling:
> > On Sun, Jul 20, 2025 at 4:41 AM Martin Uecker wrote:
> > But first, as of this time, all of our efforts over the past several
> > months to get an
identifier
operates with *no* context of how it was initially parsed. It performs
a 'lookup_name' (with scope) and then runs through the TREE_CHAIN
until it gets to the field.
-bw
> Martin
>
> Am Sonntag, dem 20.07.2025 um 11:20 + schrieb mo...@google.com:
> > From: Bill
On Wed, Jul 23, 2025 at 2:11 PM Joseph Myers wrote:
> On Wed, 23 Jul 2025, Martin Uecker wrote:
> > IMHO there are enough reasons to reject delayed parsing
> > as bad design for C. We should work towards proper
> > language features that cleanly fit into the language,
> > instead of pushing the b
On Tue, Jul 22, 2025 at 10:47 PM Martin Uecker wrote:
> IMHO there are enough reasons to reject delayed parsing
> as bad design for C. We should work towards proper
> language features that cleanly fit into the language,
> instead of pushing the boundaries with macros.
You've mentioned one reaso
On Tue, Jul 22, 2025 at 11:22 PM Martin Uecker wrote:
> Am Montag, dem 21.07.2025 um 16:03 -0700 schrieb Bill Wendling:
> > On Mon, Jul 21, 2025 at 2:19 PM Martin Uecker wrote:
> > > Am Montag, dem 21.07.2025 um 04:29 -0700 schrieb Bill Wendling:
> > > > On Sun,
On Thu, Jul 24, 2025 at 11:11 AM Martin Uecker wrote:
> Am Donnerstag, dem 24.07.2025 um 16:26 + schrieb Aaron Ballman:
> > On Thu, Jul 24, 2025 at 3:03 PM Martin Uecker wrote:
> > > Am Donnerstag, dem 24.07.2025 um 14:08 + schrieb Aaron Ballman:
> > > For my understanding: What is the pr
+josmy...@redhat.com
On Sun, Jul 20, 2025 at 4:20 AM wrote:
>
> From: Bill Wendling
>
> Also, this code doesn't go further than parsing. I.e., it doesn't generate the
> internal gimple code that accesses the struct fields. The code is meant to
> show
> tha
On Thu, Jul 24, 2025 at 3:20 PM Martin Uecker wrote:
> Am Donnerstag, dem 24.07.2025 um 15:06 -0700 schrieb Bill Wendling:
> > > constexpr size_t size = 4;
> > > struct foo {
> > > char (*buf)[size] __counted_by(size); // two different "size"!
> &
On Thu, Jul 24, 2025 at 2:53 PM Martin Uecker wrote:
> Am Donnerstag, dem 24.07.2025 um 14:25 -0700 schrieb Bill Wendling:
> > On Thu, Jul 24, 2025 at 8:03 AM Martin Uecker wrote:
> > > Am Donnerstag, dem 24.07.2025 um 14:08 + schrieb Aaron Ballman:
> > > > O
On Thu, Jul 24, 2025 at 8:03 AM Martin Uecker wrote:
> Am Donnerstag, dem 24.07.2025 um 14:08 + schrieb Aaron Ballman:
> > On Wed, Jul 23, 2025 at 8:38 PM Martin Uecker wrote:
> > > > That said, John McCall pointed out some usage patterns Apple has with
> > > > their existing feature:
> > > >
On Mon, Jul 28, 2025 at 2:39 PM Martin Uecker wrote:
> Yes, forwards declarations are this simplest solution.
>
Forward declarations work until you get something complex. For
example, if we want to support substructure fields in the attribute,
you'd have to replicate the whole substructure's decla
On Sat, Jul 26, 2025 at 1:05 AM Martin Uecker wrote:
> Am Freitag, dem 25.07.2025 um 20:07 -0700 schrieb Bill Wendling:
[snip, because I'm part of the choir]
> > I don't know what else to tell you except that
> > resolving to the struct first is the exact behavior we&
On Fri, Jul 25, 2025 at 8:55 PM Andrew Pinski wrote:
> On Fri, Jul 25, 2025 at 8:50 PM Bill Wendling wrote:
> > On Thu, Jul 24, 2025 at 3:20 PM Martin Uecker wrote:
> > > Am Donnerstag, dem 24.07.2025 um 15:06 -0700 schrieb Bill Wendling:
> > > > > constexpr
On Mon, Jul 28, 2025 at 1:48 PM Qing Zhao wrote:
> > On Jul 28, 2025, at 16:09, Martin Uecker wrote:
> > Am Montag, dem 28.07.2025 um 11:18 -0700 schrieb Yeoul Na:
> >>> On Jul 28, 2025, at 10:27 AM, Qing Zhao wrote:
> On Jul 26, 2025, at 12:43, Yeoul Na wrote:
> > On Jul 24, 2025, at
On Mon, Jul 28, 2025 at 4:29 PM Martin Uecker wrote:
> Am Montag, dem 28.07.2025 um 16:01 -0700 schrieb Bill Wendling:
> > On Mon, Jul 28, 2025 at 2:39 PM Martin Uecker wrote:
> > > Yes, forwards declarations are this simplest solution.
> > >
> > Forward declarat
On Mon, Jul 28, 2025 at 4:36 PM Yeoul Na wrote:
> On Jul 28, 2025, at 2:40 PM, Bill Wendling wrote:
> On Mon, Jul 28, 2025 at 1:48 PM Qing Zhao wrote:
> On Jul 28, 2025, at 16:09, Martin Uecker wrote:
> Am Montag, dem 28.07.2025 um 11:18 -0700 schrieb Yeoul Na:
>
> On Jul 28,
On Mon, Jul 28, 2025 at 4:52 PM Yeoul Na wrote:
>
> Could someone working on Linux answer my earlier question? Working on a
> compromise solution is one thing, but I’m trying to understand the situation
> better.
>
> > Out of curiosity, do you think focusing on simple identifier cases (which,
>
On Mon, Jul 28, 2025 at 11:36 PM Martin Uecker wrote:
>
> Am Montag, dem 28.07.2025 um 17:45 -0700 schrieb Bill Wendling:
> > On Mon, Jul 28, 2025 at 4:29 PM Martin Uecker wrote:
> > > Am Montag, dem 28.07.2025 um 16:01 -0700 schrieb Bill Wendling:
> > > > On Mo
On Tue, Jul 29, 2025 at 11:13 AM Yeoul Na wrote:
>
>
> On Jul 28, 2025, at 5:54 PM, Bill Wendling wrote:
>
> On Mon, Jul 28, 2025 at 4:52 PM Yeoul Na wrote:
>
>
> Could someone working on Linux answer my earlier question? Working on a
> compromise solution is o
66 matches
Mail list logo
