Re: [PATCH v18 0/2] c: Add __countof__ operator

Hi Joseph, Jakub, On Thu, Feb 27, 2025 at 09:51:35PM +0100, Jakub Jelinek wrote: > On Thu, Feb 27, 2025 at 08:44:25PM +, Joseph Myers via Gcc wrote: > > On Thu, 27 Feb 2025, Alejandro Colomar via Gcc wrote: > > > > > Can you please confirm if we should add a versi

Re: [PATCH v18 0/2] c: Add __countof__ operator

Hi Joseph, Aaron, (Aaron, there's no code in this email, so you should be able to read it, I guess. We're just discussing the naming of the operator.) Context for readers: The C Committee has finally accepted this as _Countof instead of _Lengthof, due to the concerns regarding confusion with st

[[gnu::malloc()]] on inline functions

Hi! I'd like to be able to inline functions declared with the [[gnu::malloc()]] attribute. The reason is that it's quite sensitive code, and I'd like to give as much information as possible to the analyzer. Would it be possible to change the implementation so that even when a function is inlined

Re: 'defer' (n3199) concerns

Hi all, After some private discussion with JeanHeyd, I'd like to *partially* withdraw my concerns against 'defer', as long as it ends up being as simple as [[gnu::cleanup()]] (or reasonably similar). The -fanalyzer is currently not smart enough to warn about strsep(3), but that's a known bug, and

Re: Handling C2Y zero-length operations on null pointers

> > And get clarified the qsort/bsearch cases whether it is about just > > nmemb == 0 or nmemb * size == 0. > > C does not support zero-sized objects, so that's something for us to > figure out on our own. We can treat size == 0 as invalid because the > functions can't work, as they use pointers

Re: Handling C2Y zero-length operations on null pointers

Hi, I had a discussion about this with another WG14 member when this was voted in. We both voted against, because this is nefarious for static analysis. However, I think this can be though to resemble how 'const' works in the standard: const char cbuf[10]; memcpy((char *)cbuf,

Re: VLA representation in GCC internals

Hi Martin, On Sat, Nov 09, 2024 at 11:34:58AM GMT, Martin Uecker wrote: > > > You can just eliminate the code for the star as it would now > > > automatically end up as variable. > > > > Thanks! > > > > Have a lovely day! > > Alex > > Just committed, so you could rebase on trunk now. Thanks!

Re: VLA representation in GCC internals

On Sat, Nov 09, 2024 at 09:38:45AM GMT, Martin Uecker wrote: > Am Samstag, dem 09.11.2024 um 00:54 +0100 schrieb Alejandro Colomar via Gcc: > > Hi Martin, > > > > I'm in the process of rebasing my __countof__ changes after your patch > > that fixes support fo

VLA representation in GCC internals

Hi Martin, I'm in the process of rebasing my __countof__ changes after your patch that fixes support for [*] and [0]. I should update the implementation of the following function: static bool is_top_array_vla (tree type) { bool zero, star, var; tree d;

Re: [PATCH v17 2/2] c: Add __countof__ operator

Hi Joseph, On Fri, Nov 08, 2024 at 03:54:51PM GMT, Joseph Myers wrote: > On Fri, 8 Nov 2024, Alejandro Colomar wrote: > > > Hi Thorsten, JeanHeyd, > > > > I've just checked that JeanHeyd opened a survey about the name. > > It's here: . > > Than

'defer' (n3199) concerns

Hi JeanHeyd, I was involved this week in a fix for a bug I wrote some months ago about a call to free(3) with a bad pointer. The simplest reproducer is: $ cat strsep_bad.c #include #include #include int main(void) { char

Re: [PATCH v17 2/2] c: Add __countof__ operator

Hi Thorsten, JeanHeyd, I've just checked that JeanHeyd opened a survey about the name. It's here: . Thanks for the survey, JeanHeyd; It's a fair one. (The only thing I miss is anouncing it to some relevant publics, but I guess I'm doing it now,

Re: [PATCH v17 2/2] c: Add __countof__ operator

On Sun, Oct 27, 2024 at 02:00:01PM GMT, Alejandro Colomar wrote: > Hi Thorsten, > > On Sun, Oct 27, 2024 at 04:30:43AM GMT, Thorsten Glaser wrote: > > Hi Alejandro, > > > > >On Sun, Oct 27, 2024 at 01:40:23AM GMT, mirabilos wrote: > > >> Not too sure what the root context of this thread is, but i

Re: [PATCH v17 2/2] c: Add __countof__ operator

Hi Thorsten, On Sun, Oct 27, 2024 at 04:30:43AM GMT, Thorsten Glaser wrote: > Hi Alejandro, > > >On Sun, Oct 27, 2024 at 01:40:23AM GMT, mirabilos wrote: > >> Not too sure what the root context of this thread is, but in BSD land > > > >The root context is that > > > >- _Lengthof was added to C2y

Re: [PATCH v17 2/2] c: Add __countof__ operator

Hi mirabilos, On Sun, Oct 27, 2024 at 01:40:23AM GMT, mirabilos wrote: > Not too sure what the root context of this thread is, but in BSD land The root context is that - _Lengthof was added to C2y in the Minnesota meeting. It was proposed by me, although they pushed me to rename the operato

Re: [PATCH v17 2/2] c: Add __countof__ operator

On Sat, Oct 26, 2024 at 12:12:39PM GMT, Alejandro Colomar wrote: > On Sat, Oct 26, 2024 at 12:07:04PM GMT, Alejandro Colomar wrote: > > [Moved from gcc-patches@ to gcc@] > > > > Hi JeanHeyd, наб, > > > > I see you (JeanHeyd) are developing yet another survey about the names > > for this new opera

Re: [PATCH v17 2/2] c: Add __countof__ operator

On Sat, Oct 26, 2024 at 12:27:03PM GMT, Alejandro Colomar wrote: > On Sat, Oct 26, 2024 at 12:12:39PM GMT, Alejandro Colomar wrote: > > On Sat, Oct 26, 2024 at 12:07:04PM GMT, Alejandro Colomar wrote: > > > [Moved from gcc-patches@ to gcc@] > > > > > > Hi JeanHeyd, наб, > > > > > > I see you (Jea

Re: [PATCH v17 2/2] c: Add __countof__ operator

On Sat, Oct 26, 2024 at 12:07:04PM GMT, Alejandro Colomar wrote: > [Moved from gcc-patches@ to gcc@] > > Hi JeanHeyd, наб, > > I see you (JeanHeyd) are developing yet another survey about the names > for this new operator. Let me ask you to be clear about my fear of > ambiguity with null-termina

Re: [PATCH v17 2/2] c: Add __countof__ operator

[Moved from gcc-patches@ to gcc@] Hi JeanHeyd, наб, I see you (JeanHeyd) are developing yet another survey about the names for this new operator. Let me ask you to be clear about my fear of ambiguity with null-terminated strings which are stored within arrays and the length of both entities diff

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

CC += JeanHeyd On Thu, Oct 17, 2024 at 05:25:55PM GMT, Alejandro Colomar wrote: > On Thu, Oct 17, 2024 at 05:19:07PM GMT, Alejandro Colomar wrote: > > CC += Robert, Joseph, gcc@ > > > > On Thu, Oct 17, 2024 at 04:30:27PM GMT, Alejandro Colomar wrote: > > > On Thu, Oct 17, 2024 at 04:23:29PM GMT,

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

On Thu, Oct 17, 2024 at 05:19:07PM GMT, Alejandro Colomar wrote: > CC += Robert, Joseph, gcc@ > > On Thu, Oct 17, 2024 at 04:30:27PM GMT, Alejandro Colomar wrote: > > On Thu, Oct 17, 2024 at 04:23:29PM GMT, Alejandro Colomar wrote: > > > CC += Doug, as the author of the original malloc(3). > > >

Re: BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

CC += Robert, Joseph, gcc@ On Thu, Oct 17, 2024 at 04:30:27PM GMT, Alejandro Colomar wrote: > On Thu, Oct 17, 2024 at 04:23:29PM GMT, Alejandro Colomar wrote: > > CC += Doug, as the author of the original malloc(3). > > > > On Thu, Oct 17, 2024 at 04:21:22PM GMT, Alejandro Colomar wrote: > > > Hi

Re: n3369 New _Lengthof operator (v4)

Hi all, On Wed, Oct 02, 2024 at 08:29:26PM GMT, Alejandro Colomar wrote: > > On Wed, Oct 02, 2024 at 11:41:20AM +0200, Alejandro Colomar wrote: > > > Hi! > > > > > > This operator is as voted in a WG14 meeting yesterday, with the only > > > difference that we name it __lengthof__ instead of _Leng

n3369 New _Lengthof operator (v4)

On Wed, Oct 02, 2024 at 08:21:54PM +0200, Alejandro Colomar wrote: > > Hi Daniel, > > Here's a revised version of the WG14 paper, with all issues addressed. I had a topy in the paper number. Here's the paper with the number fixed. Cheers, Alex > > Have a lovely day! > Alex > > On Wed, Oct 0

n3365 New _Lengthof operator (v4)

Hi Daniel, Here's a revised version of the WG14 paper, with all issues addressed. Have a lovely day! Alex On Wed, Oct 02, 2024 at 11:41:20AM +0200, Alejandro Colomar wrote: > Hi! > > This operator is as voted in a WG14 meeting yesterday, with the only > difference that we name it __lengthof__

Re: [C2y] n3313.2 draft

Hi, On Mon, Aug 19, 2024 at 01:04:28PM GMT, Alejandro Colomar wrote: > On Mon, Aug 19, 2024 at 12:58:30PM GMT, Alejandro Colomar wrote: > > I have a draft for an updated proposal to WG14 (more recent than n3313). > > It has some changes to the documentation of prior art, some typo fixes, > > etc.,

[C2y] n3313.1 draft

On Mon, Aug 19, 2024 at 12:58:30PM GMT, Alejandro Colomar wrote: > I have a draft for an updated proposal to WG14 (more recent than n3313). > It has some changes to the documentation of prior art, some typo fixes, > etc., and renames elementsof()=>nelementsof(), but the meat of the > proposal is th

[PATCH v10 0/3] c: Add __nelementsof__ operator

Hi! This is v10 of this patch set; hopefully, we're close to an end. I've already submitted a proposal for C2y to WG14, as n3313: For those who haven't been following since the start, the entire thread of patch set revisions and their

v2.2 Draft for an elementsof paper

[To: s/gcc-patches/gcc/] Hi, Attached is a new revision of the proposal for WG14 for adding an elementsof() operator (both the man(7) source, and the generated PDF). v2.2: - Rename lengthof => elementsof. Aaron found incompatible existing functions called lengthof() in the wild. - Requi

Re: v2.1 Draft for a lengthof paper

[CC: s/gcc-patches@/gcc@/] Hi Jens, On Wed, Aug 14, 2024 at 05:44:57PM GMT, Jens Gustedt wrote: > > However, strlen(3) came first, and we must respect it. > > Sure, string length, a dynamic feature, and array length are two features. (Except that I've seen --and also written myself-- also stri

Re: Promote -Wno-sizeof-array-argument to an error

On Fri, Aug 09, 2024 at 04:03:53PM GMT, Jakub Jelinek wrote: > E.g. consider GCC > #define iterative_hash_object(OB,INIT) iterative_hash (&OB, sizeof (OB), INIT) > macro. > If one uses it on the function parameters declared as arrays but turned into > pointers and you know what you are doing, why n

Re: Promote -Wno-sizeof-array-argument to an error

Hi Jakub, On Fri, Aug 09, 2024 at 02:24:48PM GMT, Jakub Jelinek wrote: > You can compile your sources with -Werror=sizeof-array-argument if you want > it to be an error, The problem with that is that the error will still be enforced _after_ GCC would change the behavior of sizeof(aparam). Admitt

Re: Promote -Wno-sizeof-array-argument to an error

Hi Martin, On Thu, Aug 08, 2024 at 09:31:37AM GMT, Martin Uecker wrote: > Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar: > > Hi Martin, > > > > Can we promote -Wno-sizeof-array-argument to a hard error? I don't > > think there's any legitimate use sizeof() on such a para

Re: Spurious -Wsequence-point with auto

Hi Martin, On Fri, Aug 09, 2024 at 10:31:55AM GMT, Martin Uecker wrote: > Can you file a bug if there isn't one already? > BTW: Double evaluation is not only a problem for semantics, but also because > it can cause long compile times, cf. t

Spurious -Wsequence-point with auto

Hi, I've seen some bogus warning in GCC that suggests that some use of auto may cause undefined behavior (due to double evaluation). $ cat auto.c #include int main(void) { int i = 3; int a[2 * i]; int (*p)[2 * i]; i = 1; p = &a; auto q = p +

Re: Promote -Wno-sizeof-array-argument to an error

On Thu, Aug 08, 2024 at 09:31:37AM GMT, Martin Uecker wrote: > Am Donnerstag, dem 08.08.2024 um 02:36 +0200 schrieb Alejandro Colomar: > > Hi Martin, > > > > Can we promote -Wno-sizeof-array-argument to a hard error? I don't > > think there's any legitimate use sizeof() on such a parameter. > >

Re: Promote -Wno-sizeof-array-argument to an error

On Thu, Aug 08, 2024 at 02:36:36AM GMT, Alejandro Colomar wrote: > Hi Martin, > > Can we promote -Wno-sizeof-array-argument to a hard error? I don't D'oh! I obviously meant -Wsizeof-array-argument. > think there's any legitimate use sizeof() on such a parameter. > > It would be an incompatibl

Promote -Wno-sizeof-array-argument to an error

Hi Martin, Can we promote -Wno-sizeof-array-argument to a hard error? I don't think there's any legitimate use sizeof() on such a parameter. It would be an incompatible extension to ISO C, which would make sure that there are no remaining uses of sizeof(array_param), which would itself allow in

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

Hi Martin, On Sat, Jul 27, 2024 at 12:59:34AM GMT, Martin Uecker wrote: > Am Samstag, dem 27.07.2024 um 00:26 +0200 schrieb Alejandro Colomar: > > On Sat, Jul 27, 2024 at 12:03:20AM GMT, Martin Uecker wrote: > > > > Maybe if GNU C compilers (GCC and Clang) add it first as an extension, > > > > add

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

On Sat, Jul 27, 2024 at 12:03:20AM GMT, Martin Uecker wrote: > > Maybe if GNU C compilers (GCC and Clang) add it first as an extension, > > adding diagnostics, it would help. > > Both GCC and Clang already have such diagnostics and/or run-time checks: > > https://godbolt.org/z/MPnxqb9h7 Hi Marti

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

On Fri, Jul 26, 2024 at 09:22:42PM GMT, Joseph Myers wrote: > On Fri, 26 Jul 2024, Alejandro Colomar via Gcc wrote: > > > > See reflector message SC22WG14.18575, 17 Nov 2020 (the former convenor > > > replying when I asked about just that paper). > > > >

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

Hi Joseph, On Fri, Jul 26, 2024 at 08:30:33PM GMT, Joseph Myers wrote: > On Fri, 26 Jul 2024, Alejandro Colomar via Gcc wrote: > > > I don't see why it should not apply to void*. memcpy(3) should get this > > attribute: > > > > [[alx::restrict(1)]] > &

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

Hi Joseph, On Fri, Jul 26, 2024 at 04:24:14PM GMT, Joseph Myers wrote: > On Wed, 10 Jul 2024, Alejandro Colomar via Gcc wrote: > > >6.7.13.x The restrict function attribute > > Constraints > > The restrict attribute shall be applied to a function.

Re: n3294 - The restrict function attribute as a replacement of the restrict qualifier

Hi Branden! On Fri, Jul 26, 2024 at 11:35:51AM GMT, G. Branden Robinson wrote: > At 2024-07-26T16:24:14+, Joseph Myers wrote: > > I know that "noalias" was included in some C89 drafts but removed from > > the final standard after objections. Maybe someone who was around > > then could explain

Re: Apply function attributes (e.g., [[gnu::access()]]) to pointees too

Hi Martin, On Thu, Jul 11, 2024 at 06:34:04PM GMT, Alejandro Colomar wrote: > Hi Martin, David, > > On Thu, Jul 11, 2024 at 06:08:38PM GMT, David Brown wrote: > > On 11/07/2024 11:58, Martin Uecker via Gcc wrote: > > > > [[gnu::access(read_write, 1)]] > > > > [[gnu::access(read_on

Re: Apply function attributes (e.g., [[gnu::access()]]) to pointees too

Hi Martin, David, On Thu, Jul 11, 2024 at 06:08:38PM GMT, David Brown wrote: > On 11/07/2024 11:58, Martin Uecker via Gcc wrote: > > > [[gnu::access(read_write, 1)]] > > > [[gnu::access(read_only, 2)]] > > > [[gnu::nonnull(1, 2)]] > > > [[gnu::null_terminated_string_arg(2)]] > > > char *

Re: Bad interaction between gcc and glibc's handling of GNU extension [GCC PR 115724]

Hi Mark, David Malcolm wrote: > On Tue, 2024-07-02 at 22:39 +0200, Mark Wielaard wrote: > > Is there an "optimal" optimization level for -fanalyzer (like having > > -Og for debugging)? > > There isn't, sorry. What I do is compile several times in a loop, with all optimization levels, to maximize

n3294 - The restrict function attribute as a replacement of the restrict qualifier

Here's a proposal for adding a function attribute for replacing the restrict restrict qualifier. It's v0.3 of n3294 (now we have a document number). I was going to name it [[noalias()]], but I thought that it would be possible to mark several pointers as possibly referencing the same object, and

Re: [WG14] Request for document number; strtol restrictness

Hi Daniel, On Sun, Jul 07, 2024 at 03:46:48PM GMT, Daniel Plakosh wrote: > Alex, > > Your document number is below: > > n3294 - strtol(3) et al. shouldn't have a restricted first parameter > > Please return the updated document with this number Am I allowed to retitle the paper? n3294 - [[n

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Paul, On Tue, Jul 09, 2024 at 02:09:24PM GMT, Paul Eggert wrote: > On 7/8/24 00:52, Alejandro Colomar wrote: > > a small set of functions > > accept pointers that alias each other, but one of them is never > > accessed; in those few cases, restrict was added to the parameters in > > ISO C, but

Re: WG14 paper for removing restrict from nptr in strtol(3)

On Tue, Jul 09, 2024 at 12:28:18PM GMT, Alejandro Colomar wrote: > Hi Jakub, > > On Tue, Jul 09, 2024 at 11:18:11AM GMT, Jakub Jelinek wrote: > > On Tue, Jul 09, 2024 at 11:07:59AM +0200, Alejandro Colomar wrote: > > > Yup, I was thinking that maybe noalias is a better name. > > > > Name is one t

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Jakub, On Tue, Jul 09, 2024 at 11:18:11AM GMT, Jakub Jelinek wrote: > On Tue, Jul 09, 2024 at 11:07:59AM +0200, Alejandro Colomar wrote: > > Yup, I was thinking that maybe noalias is a better name. > > Name is one thing, but you'd also need to clearly define what it means. > When restrict is a

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Martin, On Tue, Jul 09, 2024 at 07:58:40AM GMT, Martin Uecker wrote: > Am Montag, dem 08.07.2024 um 22:17 +0200 schrieb Alejandro Colomar: > > Hi Martin, > > > > On Mon, Jul 08, 2024 at 06:05:08PM GMT, Martin Uecker wrote: > > > Am Montag, dem 08.07.2024 um 17:01 +0200 schrieb Alejandro Coloma

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Dave, On Mon, Jul 08, 2024 at 06:48:51PM GMT, David Malcolm wrote: > > restrict, as of the formal definition of ISO C is useless crap.  The > > more I read it, the more I agree. > > Please note that "useless crap" was your wording, not mine. Yup. :) > > > > > restrict, as of what -Wrestri

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Martin, On Mon, Jul 08, 2024 at 06:05:08PM GMT, Martin Uecker wrote: > Am Montag, dem 08.07.2024 um 17:01 +0200 schrieb Alejandro Colomar: > > On Mon, Jul 08, 2024 at 10:30:48AM GMT, David Malcolm wrote: > > ... > > And then have it mean something strict, such as: The object pointed to > > by

Re: WG14 paper for removing restrict from nptr in strtol(3)

On Mon, Jul 08, 2024 at 10:30:48AM GMT, David Malcolm wrote: > > > Why is this change worth > > > making? Real-world programs do not make calls like that. > > > > Because it makes analysis of 'restrict' more consistent.  The obvious > > improvement of GCC's analyzer to catch restrict violations wi

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Paul, On Sun, Jul 07, 2024 at 07:30:43PM GMT, Paul Eggert wrote: > On 7/7/24 14:42, Alejandro Colomar wrote: > > On Sun, Jul 07, 2024 at 12:42:51PM GMT, Paul Eggert wrote: > > > Also, “global variables” is not > > > right here. The C standard allows strtol, for example, to read and write > > >

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Martin, On Sun, Jul 07, 2024 at 02:21:17PM GMT, Martin Uecker wrote: > Am Sonntag, dem 07.07.2024 um 13:07 +0200 schrieb Alejandro Colomar via Gcc: > > Which is actually having perfect information, regardless of 'restrict' > > on nptr. :-) > > Yes, but my point

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Paul, On Sun, Jul 07, 2024 at 12:42:51PM GMT, Paul Eggert wrote: > On 7/7/24 03:58, Alejandro Colomar wrote: > > > I've incorporated feedback, and here's a new revision, let's call it > > v0.2, of the draft for a WG14 paper. > Although I have not followed the email discussion closely, I read v

Re: WG14 paper for removing restrict from nptr in strtol(3)

Hi Martin, On Sun, Jul 07, 2024 at 09:15:23AM GMT, Martin Uecker wrote: > > Hi Alejandro, > > if in caller it is known that endptr has access mode "write_only" > then it can conclude that the content of *endptr has access mode > "none", couldn't it? H. I think you're correct. I'll incorpo

WG14 paper for removing restrict from nptr in strtol(3)

Hi, I've incorporated feedback, and here's a new revision, let's call it v0.2, of the draft for a WG14 paper. I've attached the man(7) source, and the generated PDF. Cheers, Alex -- strtol.man Description: Unix manual page strtol.pdf Description: Adobe

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Hi Xi, On Sat, Jul 06, 2024 at 10:24:16AM GMT, Xi Ruoyao wrote: > On Sat, 2024-07-06 at 00:02 +0200, Alejandro Colomar wrote: > > That's precisely the case with strtol(3): it doesn't access any objects > > through *endptr, and so that pointer need not be restrict. > > > > Then, nptr is a read-onl

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

On Sat, Jul 06, 2024 at 08:10:28AM GMT, Alejandro Colomar wrote: > Hi Xi, > > On Sat, Jul 06, 2024 at 10:24:16AM GMT, Xi Ruoyao wrote: > > On Sat, 2024-07-06 at 00:02 +0200, Alejandro Colomar wrote: > > > That's precisely the case with strtol(3): it doesn't access any objects > > > through *endptr

[[gnu::null_terminated_string_arg(1)]] on strtol(1) (was: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like) functions

Hi Xi, On Sat, Jul 06, 2024 at 10:39:41AM GMT, Xi Ruoyao wrote: > BTW among your list: > > > > [[gnu::access(read_only, 1)]] > > > [[gnu::access(write_only, 2)]] > > > [[gnu::leaf]] > > > [[gnu::nothrow]] > > > [[gnu::null_terminated_string_arg(1)]] > > IMO we should add these access attributes,

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

On Sat, Jul 06, 2024 at 12:02:06AM GMT, Alejandro Colomar wrote: > Hi Jonathan, > > On Fri, Jul 05, 2024 at 10:39:52PM GMT, Jonathan Wakely wrote: > > On Fri, 5 Jul 2024 at 21:55, Alejandro Colomar wrote: > > > > > > On Fri, Jul 05, 2024 at 09:28:46PM GMT, Jonathan Wakely wrote: > > > > > If we m

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Hi Jonathan, On Fri, Jul 05, 2024 at 10:39:52PM GMT, Jonathan Wakely wrote: > On Fri, 5 Jul 2024 at 21:55, Alejandro Colomar wrote: > > > > On Fri, Jul 05, 2024 at 09:28:46PM GMT, Jonathan Wakely wrote: > > > > If we marked endptr as "write_only" (which it might already > > > > be) then a future

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

On Fri, Jul 05, 2024 at 09:28:46PM GMT, Jonathan Wakely wrote: > > If we marked endptr as "write_only" (which it might already > > be) then a future warning mechanism for -Wrestrict could > > ignore the content of *endptr. > > > That seems more useful. Add semantic information instead of taking i

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

On Fri, Jul 05, 2024 at 09:28:46PM GMT, Jonathan Wakely wrote: > On Fri, 5 Jul 2024 at 21:26, Martin Uecker wrote: > > > > Am Freitag, dem 05.07.2024 um 21:28 +0200 schrieb Alejandro Colomar: > > > > ... > > > > > > > > Showing that you can contrive a case where a const char* restrict and > > > >

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Hi Jonathan, On Fri, Jul 05, 2024 at 08:52:30PM GMT, Jonathan Wakely wrote: > > > > > > > It **shouldn't**. strtol will only violate restrict if it's > > > > > > > wrongly > > > > > > > implemented, or something dumb is done like "strtol((const char*) > > > > > > > &p, > > > > > > > &p, 0)". >

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Hi Jonathan, On Fri, Jul 05, 2024 at 08:38:15PM GMT, Jonathan Wakely wrote: > On Fri, 5 Jul 2024 at 20:28, Alejandro Colomar wrote: > > > > Hi, > > > > On Fri, Jul 05, 2024 at 06:30:50PM GMT, Martin Uecker wrote: > > > Am Freitag, dem 05.07.2024 um 17:24 +0100 schrieb Jonathan Wakely: > > > > On

[WG14] Request for document number; strtol restrictness

Hi, I have a paper for removing restrict from the first parameter of strtol(3) et al. The title is strtol(3) et al. should’t have a restricted first parameter. If it helps, I already have a draft of the paper, which I attach (both the PDF, and the man(7) source). Cheers, Alex --

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Hi, On Fri, Jul 05, 2024 at 06:30:50PM GMT, Martin Uecker wrote: > Am Freitag, dem 05.07.2024 um 17:24 +0100 schrieb Jonathan Wakely: > > On Fri, 5 Jul 2024 at 17:02, Xi Ruoyao via Gcc wrote: > > > > > > On Fri, 2024-07-05 at 17:53 +0200, Alejandro Colomar wrote: > > > > At least, I hope there's

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

On Fri, Jul 05, 2024 at 06:32:26PM GMT, Alejandro Colomar wrote: > Hi Xi, > > On Fri, Jul 05, 2024 at 11:55:05PM GMT, Xi Ruoyao wrote: > > On Fri, 2024-07-05 at 17:23 +0200, Alejandro Colomar wrote: > > > > strtol does have  a "char * restrict * restrict" though, so the > > > > situation is differ

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Hi Xi, On Fri, Jul 05, 2024 at 11:55:05PM GMT, Xi Ruoyao wrote: > On Fri, 2024-07-05 at 17:23 +0200, Alejandro Colomar wrote: > > > strtol does have  a "char * restrict * restrict" though, so the > > > situation is different.   A "char **" and a "const char *" > > > shouldn't alias anyway. > > >

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Hi Martin, On Fri, Jul 05, 2024 at 05:34:55PM GMT, Martin Uecker wrote: > > I've written functions that more closely resemble strtol(3), to show > > that in the end they all share the same issue regarding const-ness: (Above I meant s/const/restrict/) > > > > $ cat d.c > > int d(const c

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

Hi Martin, On Fri, Jul 05, 2024 at 05:02:15PM GMT, Martin Uecker wrote: > > But when the thing gets non-trivial, as in strtol(3), GCC misses the > > -Wrestrict diagnostic, as reported in > > . > > > > Let's write a reproducer by altering the du

Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

[CC += linux-man@, since we're discussing an API documented there, and the manual page would also need to be updated] Hi Xi, Jakub, On Fri, Jul 05, 2024 at 09:38:21PM GMT, Xi Ruoyao wrote: > On Fri, 2024-07-05 at 15:03 +0200, Alejandro Colomar wrote: > > ISO C specifies these APIs as accepting

[PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

ISO C specifies these APIs as accepting a restricted pointer in their first parameter: $ stdc c99 strtol long int strtol(const char *restrict nptr, char **restrict endptr, int base); $ stdc c11 strtol long int strtol(const char *restrict nptr, char **restrict endptr, int base); However, it should

Re: strtol(3) with QChar arguments

Hi Martin, On Sun, May 05, 2024 at 04:47:21PM +0200, Martin Uecker wrote: > Am Sonntag, dem 05.05.2024 um 15:13 +0200 schrieb Alejandro Colomar: > > Hi Martin, > > > > I was wondering why C23 didn't use QChar for strtol(3). It has the same > > problems that string functions have: a const input s

strtol(3) with QChar arguments

Hi Martin, I was wondering why C23 didn't use QChar for strtol(3). It has the same problems that string functions have: a const input string and a non-const output string (the endptr). I think endptr should have the same constness of the string passed to strtol(3), no? Should this be addressed

Re: Sourceware mitigating and preventing the next xz-backdoor

Hi Mark, On Sun, Apr 21, 2024 at 10:40:14PM +0200, Alejandro Colomar wrote: [...] > Let's generate a v2 patch set, showing the range-diff against v1. We > need to check the commit IDs of the first set, which can be found in the > mailing list archives, thanks to the trick we used. The v1 range

Re: Sourceware mitigating and preventing the next xz-backdoor

On Sun, Apr 21, 2024 at 10:40:14PM +0200, Alejandro Colomar wrote: > On Sun, Apr 21, 2024 at 05:30:52PM +0200, Mark Wielaard wrote: > > Hi Alejandro, > > Hi Mark, > > I've reordered your message, to organize my response. > > > On Wed, Apr 10, 2024 at 06:30:42PM +0200, Alejandro Colomar wrote: >

Re: Sourceware mitigating and preventing the next xz-backdoor

On Sun, Apr 21, 2024 at 05:30:52PM +0200, Mark Wielaard wrote: > Hi Alejandro, Hi Mark, I've reordered your message, to organize my response. > On Wed, Apr 10, 2024 at 06:30:42PM +0200, Alejandro Colomar wrote: > > It would also be interesting to require showing range-diffs between > > patch rev

Re: Sourceware mitigating and preventing the next xz-backdoor

Hi Joel, On Wed, Apr 03, 2024 at 08:53:21AM -0500, Joel Sherrill wrote: > On Wed, Apr 3, 2024, 3:09 AM Florian Weimer via Gdb > wrote: > > > * Guinevere Larsen via Overseers: > > > > > Beyond that, we (GDB) are already experimenting with approved-by, and > > > I think glibc was doing the same. >

Re: Missed optimization of strcpy(3) (or stpcpy(3))

Hi Richard, On Mon, Nov 13, 2023 at 07:56:00AM +0100, Richard Biener wrote: > Can you file a bugreport please? It looks like a transform for the > strlen pass. Done; thanks. -- signature.asc Description

Missed optimization of strcpy(3) (or stpcpy(3))

Hi, The following code can be optimized to use memcpy(3), since the length of the copy is known (we've just called strnlen(3), and discarded the possibility of truncated lengths). $ cat strxcpy.c #include #include #include ssize_t strxcpy(char *restrict dst, const char *restrict src, size_t d

Re: Confusing location of error in source code

Hi Jonathan, On 2023-09-01 08:49, Jonathan Wakely wrote: > On Thu, 31 Aug 2023, 17:05 Alejandro Colomar via Gcc, > wrote: > >> Hi! >> >> I've been confused for some time with a compilation error that >> pointed to a slightly-off location. I wasn't se

Confusing location of error in source code

Hi! I've been confused for some time with a compilation error that pointed to a slightly-off location. I wasn't seeing that I used a temporary variable in a constant expression. The code could be reduced to: $ cat const.c int main(void) { int x = 42; _Static_assert(0 || 7 > x,

Re: Should GCC warn about sizeof(flexible_struct)?

On 2023-08-14 19:11, Alejandro Colomar wrote: > Hi Martin, > > On 2023-08-14 18:49, Martin Uecker wrote: >> Am Montag, dem 14.08.2023 um 12:21 +0200 schrieb Alejandro Colomar: > [...] > >>> Would you mind chiming in to this question?: >>> >> >> Unclear

Re: Should GCC warn about sizeof(flexible_struct)?

Hi Martin, On 2023-08-14 18:49, Martin Uecker wrote: > Am Montag, dem 14.08.2023 um 12:21 +0200 schrieb Alejandro Colomar: [...] >> Would you mind chiming in to this question?: >> > > Unclear. It is probably UB by omission. Agree. > But this is pos

Re: Should GCC warn about sizeof(flexible_struct)?

Hi Richard, On 2023-08-14 08:41, Richard Biener wrote: > On Fri, Aug 11, 2023 at 8:30 PM Alejandro Colomar via Gcc > wrote: [...] >> How about some -Wfam-sizeof-arithmetic that would not warn about taking >> sizeof(s) but would warn if that sizeof is used in any arithmet

Re: Should GCC warn about sizeof(flexible_struct)?

On 2023-08-11 20:29, Alejandro Colomar wrote: > Hi! > > Structures with flexible array members have restrictions about being > used in arrays or within other structures, as the size of the enclosing > aggregate type would be... inconsistent. > > In general, sizeof(flexible_struct) is a problemati

Should GCC warn about sizeof(flexible_struct)?

Hi! Structures with flexible array members have restrictions about being used in arrays or within other structures, as the size of the enclosing aggregate type would be... inconsistent. In general, sizeof(flexible_struct) is a problematic thing that rarely means what programmers think it means.

Re: ISO C's [static] (was: _Nullable and _Nonnull in GCC's analyzer)

Hi Martin! On 2023-08-09 14:03, Martin Uecker wrote: [...] >> GCC could perfectly add a warning for the following case: >> >> void foo(size_t n, int a[n]); >> >> int >> main(void) >> { >> int a[7]; >> >> foo(42, a); >> } >> >> Nobody in their right mind would s

ISO C's [static] (was: _Nullable and _Nonnull in GCC's analyzer)

Hi Martin, On 2023-08-09 09:26, Martin Uecker wrote: > it is a bit cumbersome to use, but one can use [static] > instead, which gives you the same static warnings. > > [static] does not work with __builtin_dynamic_object_size, > but maybe this could be changed (there is a bug filed.) > > I am no

Re: _Nullable and _Nonnull in GCC's analyzer (was: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h)

On 7/10/23 22:14, Alejandro Colomar wrote: [CC += Andrew] Hi Xi, Andrew, On 7/10/23 20:41, Xi Ruoyao wrote: Maybe we should have a weaker version of nonnull which only performs the diagnostic, not the optimization.  But it looks like they hate the idea: https://gcc.gnu.org/PR110617. This is

_Nullable and _Nonnull in GCC's analyzer (was: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h)

[CC += Andrew] Hi Xi, Andrew, On 7/10/23 20:41, Xi Ruoyao wrote: Maybe we should have a weaker version of nonnull which only performs the diagnostic, not the optimization. But it looks like they hate the idea: https://gcc.gnu.org/PR110617. This is the one thing that makes me use both Clang a

Re: [wish] Flexible array members in unions

Hi Joseph, Kees, On 5/12/23 00:52, Joseph Myers wrote: > On Thu, 11 May 2023, Kees Cook via Gcc wrote: > >> Okay, understood. If this is a C-only thing, we can ignore the C++ >> impact. > > We're a lot more careful lately in WG14 about checking for C++ > compatibility issues and expecting appro

Re: [wish] Flexible array members in unions

[CC += Kees, Andrew] [start of thread: ] On 5/11/23 18:07, Alejandro Colomar wrote: > Hi! > > Currently, one can have pseudo-flexible array members in unions with > [0] syntax, but it's not allowed with [] syn

[wish] Flexible array members in unions

Hi! Currently, one can have pseudo-flexible array members in unions with [0] syntax, but it's not allowed with [] syntax. Here's an example of how it is possible today: struct s { ... size_t n; union { ptrdiff_t off[0]; // [n]; offsets from s->data.

  1   2   3   >