Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Thu, 24 Jul 2025, Aaron Ballman wrote: > Question on the .N syntax: I thought I heard that this was something > GCC could handle, but that it still requires late parsing to ensure > type information for N is available and that was a problem. e.g., > > void func(char *buffer __counted_by(.N * s

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

> On Jul 29, 2025, at 7:48 PM, Bill Wendling wrote: > > 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

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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 one thing, but I’m trying to unders

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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 Mon, Jul 28, 2025 at 2:39 PM Martin U

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

> 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 one thing, but I’m trying to understand the situation >> better. >> >>> Out of curi

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

> On Jul 29, 2025, at 11:52, Martin Uecker wrote: > > Am Dienstag, dem 29.07.2025 um 13:49 + schrieb Qing Zhao: >> >>> On Jul 28, 2025, at 17:39, Martin Uecker wrote: >>> >>> Am Montag, dem 28.07.2025 um 20:48 + schrieb Qing Zhao: > On Jul 28, 2025, at 16:09, Martin Uecker

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Dienstag, dem 29.07.2025 um 13:49 + schrieb Qing Zhao: > > > On Jul 28, 2025, at 17:39, Martin Uecker wrote: > > > > Am Montag, dem 28.07.2025 um 20:48 + schrieb Qing Zhao: > > > > > > > On Jul 28, 2025, at 16:09, Martin Uecker wrote: > > > > > > > > > ... > > > > > Ex 6) > > >

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

> On Jul 28, 2025, at 17:39, Martin Uecker wrote: > > Am Montag, dem 28.07.2025 um 20:48 + schrieb Qing Zhao: >> >>> 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 Zha

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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 Mon, Jul 28, 2025 at 2:39 PM Martin Uecker wrote: > > > > Yes, forwards declarations are this simples

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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, >

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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, 2025, at 10:27 AM,

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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 declarations work until you get something

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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, as > I understand, are the majority in the Linux kernel as we

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

> 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, 2025, at 10:27 AM, Qing Z

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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 declarations work until you get something complex. For > example, if we want to support substructure fiel

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Montag, dem 28.07.2025 um 23:39 +0200 schrieb Martin Uecker: > Am Montag, dem 28.07.2025 um 20:48 + schrieb Qing Zhao: > > > > > 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, 20

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Montag, dem 28.07.2025 um 20:48 + schrieb Qing Zhao: > > > 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 2

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

> 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 3:52 PM, Kees

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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 3:52 PM, Kees Cook wrote: > > > > > > > > On Thu, Jul 24, 2025 at

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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've been trying > > to get cor

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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 size_t size = 4; > > > > > struct foo

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

In case, this may be a useful data point for anyone, guarded_by (which is an attribute used in C and C++, while it’s currently used more in C++) already accepts relatively more complex expressions as operands, like `&id`, `foo()->get_lock()`, `system->machine_lock`, and `*obj`. And it uses forwa

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

> 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 3:52 PM, Kees Cook wrote: >>> >>> On Thu, Jul 24, 2025 at 04:26:12PM +, Aaron Ballman wrote: Ah, apologies, I wasn't clear. My thinking is: we'r

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

FYI, here is our proposal to WG (the C standard committee) to generally solve the problem of forward referencing and name lookup for fields for this new category attributes which need to refer to “peers", including bounds attributes: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3656.pdf Ch

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

> On Jul 26, 2025, at 12:43, Yeoul Na wrote: > > > >> On Jul 24, 2025, at 3:52 PM, Kees Cook wrote: >> >> On Thu, Jul 24, 2025 at 04:26:12PM +, Aaron Ballman wrote: >>> Ah, apologies, I wasn't clear. My thinking is: we're (Clang folks) >>> going to want it to work in C++ mode because of

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

> On Jul 24, 2025, at 3:52 PM, Kees Cook wrote: > > On Thu, Jul 24, 2025 at 04:26:12PM +, Aaron Ballman wrote: >> Ah, apologies, I wasn't clear. My thinking is: we're (Clang folks) >> going to want it to work in C++ mode because of shared headers. If it >> works in C++ mode, then we have t

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

> On Jul 23, 2025, at 12:30 AM, Kees Cook wrote: > > On Wed, Jul 23, 2025 at 07:47:11AM +0200, 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, >> inst

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

> On 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 t

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Freitag, dem 25.07.2025 um 20:07 -0700 schrieb Bill Wendling: > 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

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Freitag, dem 25.07.2025 um 20:12 -0700 schrieb Bill Wendling: > 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); //

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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 size_t size = 4; > > > > struct foo { > > > > char (*buf)[size] __counted_by(size); // two diff

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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"! > > > int size; > > > }; > > > > VLAs within struc

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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: > > > > On Wed, Jul 23, 2025 at 8:38 PM Mar

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Thu, Jul 24, 2025 at 07:19:48PM +, Aaron Ballman wrote: > I'll have to think about that more, but my initial reaction is: that's > making our implementation/design problems be the user's problem. Maybe > that's fine? But it would be kind of frustrating as a user to have > code using `__count

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Thu, Jul 24, 2025 at 04:26:12PM +, Aaron Ballman wrote: > Ah, apologies, I wasn't clear. My thinking is: we're (Clang folks) > going to want it to work in C++ mode because of shared headers. If it > works in C++ mode, then we have to figure out what it means with all > the various C++ featur

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Donnerstag, dem 24.07.2025 um 15:06 -0700 schrieb Bill Wendling: > On Thu, Jul 24, 2025 at 11:11 AM Martin Uecker wrote: > > Am Donnerstag, dem 24.07.2025 um 16:26 + schrieb Aaron Ballman: > > > > > > constexpr size_t size = 4; > > struct foo { > > char (*buf)[size] __counted_by(size);

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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: > > > On Wed, Jul 23, 2025 at 8:38 PM Martin Uecker wrote: ... > > > > TBH, I am not terrible convin

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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: > > > >

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

> On Jul 24, 2025, at 11:03, Martin Uecker wrote: __counted_by(M)); ``` It's kind of gross to need two attributes to do the same notional thing, but it does solve the vast majority of the usages seen in the wild if you're willing to accept some awkwardness around things

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Donnerstag, dem 24.07.2025 um 19:19 + schrieb Aaron Ballman: > On Thu, Jul 24, 2025 at 6:11 PM 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

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Thu, Jul 24, 2025 at 6:11 PM 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: > > > > On Wed, Jul 23, 2025 at 8:3

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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: > > > On Wed, Jul 23, 2025 at 8:38 PM Martin Uecker wrote: > > > > > ... > > > > > > Personall

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Thu, Jul 24, 2025 at 3:03 PM 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 exist

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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: > > > > > > * 655 simple references to variables or str

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Wed, Jul 23, 2025 at 7:40 PM Kees Cook wrote: > > On Wed, Jul 23, 2025 at 11:53:40AM +, Aaron Ballman wrote: > > That said, John McCall pointed out some usage patterns Apple has with > > their existing feature: > > > > * 655 simple references to variables or struct members: __counted_by(len

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Wed, Jul 23, 2025 at 8:38 PM Martin Uecker wrote: > > Am Mittwoch, dem 23.07.2025 um 11:53 + schrieb Aaron Ballman: > > On Wed, Jul 23, 2025 at 5:47 AM Martin Uecker wrote: > > > > > > > This is a personal stance of mine, not a Clang community response. > > > > > > > But this requires true

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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 boundaries with macros. At the last WG14 meeting it was said t

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Mittwoch, dem 23.07.2025 um 12:58 -0700 schrieb Bill Wendling: > 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: > > > > ... > > > > Please give an example of

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Mittwoch, dem 23.07.2025 um 11:53 + schrieb Aaron Ballman: > On Wed, Jul 23, 2025 at 5:47 AM Martin Uecker wrote: > > > > This is a personal stance of mine, not a Clang community response. > > > > But this requires true collaboration, which can not > > exist when one side is not able to

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Mittwoch, dem 23.07.2025 um 12:34 -0700 schrieb Bill Wendling: > 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, >

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Wed, Jul 23, 2025 at 06:40:07PM +0200, Martin Uecker wrote: > Am Mittwoch, dem 23.07.2025 um 00:30 -0700 schrieb Kees Cook: > > On Wed, Jul 23, 2025 at 07:47:11AM +0200, Martin Uecker wrote: > ... > > > > > How would GCC want to define the syntax for expressions here? I still > > think it shou

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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, Jul 20, 2025 at 4:41 AM Martin Uec

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Wed, Jul 23, 2025 at 04:28:36PM +, Qing Zhao wrote: > > > > On Jul 23, 2025, at 03:30, Kees Cook wrote: > > > > > > How would GCC want to define the syntax for expressions here? I still > > think it should be possible to wire up something that matches it in > > Clang, even if it is a "r

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Wed, Jul 23, 2025 at 11:53:40AM +, Aaron Ballman wrote: > That said, John McCall pointed out some usage patterns Apple has with > their existing feature: > > * 655 simple references to variables or struct members: __counted_by(len) > * 73 dereferences of variables or struct members: __count

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Am Mittwoch, dem 23.07.2025 um 00:30 -0700 schrieb Kees Cook: > On Wed, Jul 23, 2025 at 07:47:11AM +0200, Martin Uecker wrote: ... > > How would GCC want to define the syntax for expressions here? I still > think it should be possible to wire up something that matches it in > Clang, even if it is

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

> On Jul 23, 2025, at 03:30, Kees Cook wrote: > > > How would GCC want to define the syntax for expressions here? I still > think it should be possible to wire up something that matches it in > Clang, even if it is a "redundant" syntax within Clang (i.e. Clang can > support 2 way to handle exp

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Wed, Jul 23, 2025 at 5:47 AM Martin Uecker wrote: > This is a personal stance of mine, not a Clang community response. > 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, > inst

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Wed, Jul 23, 2025 at 07:47:11AM +0200, 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. > > But this requi

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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, Jul 20, 2025 at 4:41 AM Martin Uecker wrote: .. > > > > Re original context: The 'struct c_par

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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. But this requires true collaboration, which can not exist when one side is not able to

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

[Explicitly CCing Joseph since this thread[1] is about the C front-end] On Tue, Jul 22, 2025 at 09:01:35PM +, Qing Zhao wrote: > However, given the current situation, I also think that provide two different > interfaces from CLANG > and GCC might be the practical solution to this endless disc

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

Hi, Bill, Thanks a lot for your effort to try to provide a consistent interface of counted_by attribute to the users. Really appreciate for this. However, given the current situation, I also think that provide two different interfaces from CLANG and GCC might be the practical solution to this

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

+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 > that it *is* possible to perform a delayed

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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 agreement on a syntax suita

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

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: > > I think the question is not whether this could be done somehow, > > but whether it should. Why design a language feature that requires > > storing tokens and parsing it outsi

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

On Sun, Jul 20, 2025 at 4:41 AM Martin Uecker wrote: > I think the question is not whether this could be done somehow, > but whether it should. Why design a language feature that requires > storing tokens and parsing it outside the original context? Fine, and I'm willing to have this discussion,

Re: [PATCH] [RFC] Delayed parsing for bounds safety attributes

I think the question is not whether this could be done somehow, but whether it should. Why design a language feature that requires  storing tokens and parsing it outside the original context?   For an attribute this may still be acceptable, but we need the same thing for array sizes in C. For