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

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

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

Re: [COMMITTED] Regenerate c.opt.urls

Hi Mark, On Wed, Jul 17, 2024 at 06:07:20PM GMT, Mark Wielaard wrote: > > diff --git a/gcc/c-family/c.opt.urls b/gcc/c-family/c.opt.urls > > index 1b60ae4847b..df5f58a1eee 100644 > > --- a/gcc/c-family/c.opt.urls > > +++ b/gcc/c-family/c.opt.urls > > @@ -870,6 +870,9 @@ > >

Re: ☠ Buildbot (Sourceware): gcc-autoregen - failed 'git diff ...' (failure) (master)

Hi Jonathan, On Sun, Jul 14, 2024 at 01:37:02PM GMT, Jonathan Wakely wrote: > On Sun, 14 Jul 2024, 12:30 Alejandro Colomar via Gcc-help, < > gcc-h...@gcc.gnu.org> wrote: > > Did I break anything? I see the failure being `git diff --exit-code`, > > which doesn't seem lik

Re: ☠ Buildbot (Sourceware): gcc-autoregen - failed 'git diff ...' (failure) (master)

Hi! On Sun, Jul 14, 2024 at 10:01:34AM GMT, buil...@sourceware.org wrote: > A new failure has been detected on builder gcc-autoregen while building gcc. > > Full details are available at: > https://builder.sourceware.org/buildbot/#/builders/269/builds/6546 Did I break anything? I see the

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)]] > > > >

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

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 -

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

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

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

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

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

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 is tha

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 seeing th

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 >

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

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

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

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

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

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

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

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

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 []

[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.

[PATCH v3] sockaddr.3type: POSIX Issue 8 will solve strict-aliasing issues with these types

Link: Reported-by: Bastien Roucariès Reported-by: Alejandro Colomar Reviewed-by: Eric Blake Cc: glibc Cc: GCC Cc: Stefan Puiu Cc: Igor Sysoev Cc: Rich Felker Cc: Andrew Clayton Cc: Richard Biener Cc: Zack Weinberg Cc: Florian Weimer Cc:

Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used

On 4/21/23 16:58, Alejandro Colomar wrote: > Hi Eric, > > On 4/14/23 18:08, Zack Weinberg via Libc-alpha wrote: >> On 2023-04-06 3:37 PM, Eric Blake wrote: >>> Since Issue 7 is tied to C99, and Issue 8 will be tied to C17, both of >>> which use the same section number despite being a different

Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used

Hi Eric, On 4/14/23 18:08, Zack Weinberg via Libc-alpha wrote: > On 2023-04-06 3:37 PM, Eric Blake wrote: >> Since Issue 7 is tied to C99, and Issue 8 will be tied to C17, both of >> which use the same section number despite being a different edition of >> the C standard, being that specific may

[PATCH] doc: tfix

Remove repeated word (typo). Signed-off-by: Alejandro Colomar --- gcc/doc/extend.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index fd3745c5608..cdfb25ff272 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@

Ping: [PATCH v2] C, ObjC: Add -Wunterminated-string-initialization

Hi David, On 3/24/23 18:58, David Malcolm wrote: > On Fri, 2023-03-24 at 18:45 +0100, Alejandro Colomar wrote: >> Hi David, >> >> On 3/24/23 15:53, David Malcolm wrote: >>> On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc- >>> patches &

Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used

Hi Eric, On 4/6/23 18:24, Eric Blake wrote: > On Wed, Apr 05, 2023 at 02:42:04AM +0200, Alejandro Colomar wrote: >> Hi Eric, >> >> I'm going to reply both your emails here so that GCC is CCed, and they can >> suggest better stuff. I'm worried about sending something to POSIX without >> enough

Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used

Hi Eric, I'm going to reply both your emails here so that GCC is CCed, and they can suggest better stuff. I'm worried about sending something to POSIX without enough eyes checking it. So this will be a long email. On 3/30/23 20:36, eblake wrote: > On Thu, Mar 30, 2023 at 06:25:30PM +0200,

[PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used

POSIX.1 Issue 8 will fix the long-standing issue with sockaddr APIs, which inevitably caused UB either on user code, libc, or more likely, both. sockaddr_storage has been clarified to be implemented in a manner that aliasing it is safe (suggesting a unnamed union, or other compiler magic). Link:

Re: -Wanalyzer-malloc-leak false positives

On 3/29/23 15:41, Alejandro Colomar wrote: >>> Should I report this in bugzilla? >> Yes please. > Will do. > >> Please can you attach the preprocessed source [1] to the >> bug report(s) so that we're looking at the same code. Reported: --

Re: -Wanalyzer-malloc-leak false positives

Hi David, On 3/29/23 15:32, David Malcolm wrote: >> $ cat pass.c >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> > > [...snip...] > > I very briefly tried to reproduce this myself, but I suspect we've got > different headers. I'm on Debian Sid

-Wanalyzer-malloc-leak false positives

Hi! With both GCC 12.2.0 (Debian), and GCC 13.0.1 20230315 (built from source), I can reproduce these false positives. The reproducer program is a small program that checks a password against a hardcoded string, and conditionally prints "validated". I wrote it precisely to demonstrate how

Re: [PATCH v2] C, ObjC: Add -Wunterminated-string-initialization

Hi David, On 3/24/23 15:53, David Malcolm wrote: > On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc-patches > wrote: >> Warn about the following: >> >>     char  s[3] = "foo"; >> [...] >> --- >> >> Hi, > > Hi Alex,

[PATCH v2] C, ObjC: Add -Wunterminated-string-initialization

Warn about the following: char s[3] = "foo"; Initializing a char array with a string literal of the same length as the size of the array is usually a mistake. Rarely is the case where one wants to create a non-terminated character sequence from a string literal. In some cases, for writing

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

Hi Bastien and Eric! On 3/18/23 08:54, roucaries bastien wrote: > Hi, > > I have opened a defect at austin group > https://www.austingroupbugs.net/view.php?id=1641 Sorry for not having prepared yet my report as I promised to Eric. I've been busy with other stuff, but still had in mind doing it

Re: [PATCH] C, ObjC: Add -Wunterminated-string-initialization

On 3/17/23 02:12, Alejandro Colomar wrote: > Warn about the following: > > char s[3] = "foo"; > > Initializing a char array with a string literal of the same length as > the size of the array is usually a mistake. Rarely is the case where > one wants to create a non-terminated character

[PATCH] C, ObjC: Add -Wunterminated-string-initialization

Warn about the following: char s[3] = "foo"; Initializing a char array with a string literal of the same length as the size of the array is usually a mistake. Rarely is the case where one wants to create a non-terminated character sequence from a string literal. In some cases, for writing

Re: Ping: [PATCH resend] Make -Wuse-after-free=3 the default one in -Wall

Hi Richard, On 3/15/23 15:52, Richard Biener wrote: > On Wed, Mar 15, 2023 at 3:30 PM Alejandro Colomar via Gcc-patches > wrote: >> >> Ping > > -Wuse-after-free=3 was explicitly added to cover cases with a high > false-positive rate. If you want to > make that

Ping: [PATCH resend] Make -Wuse-after-free=3 the default one in -Wall

Ping On 2/18/23 00:05, Alejandro Colomar wrote: > Link: > > Link: > Cc: Andreas Schwab > Cc: David Malcolm > Cc: Florian Weimer > Cc:

[PATCH resend] Make -Wuse-after-free=3 the default one in -Wall

Link: Link: Cc: Andreas Schwab Cc: David Malcolm Cc: Florian Weimer Cc: Iker Pedrosa Cc: Jens Gustedt Cc: Jonathan Wakely Cc: Mark

Re: [PATCH] Make -Wuse-after-free=3 the default one in -Wall

Hi Siddhesh, On 2/17/23 22:39, Siddhesh Poyarekar wrote: > On 2023-02-17 16:20, Alejandro Colomar wrote: >> Link: >> >> Link: >> >> Cc:

[PATCH] Make -Wuse-after-free=3 the default one in -Wall

Link: Link: Cc: Andreas Schwab Cc: David Malcolm Cc: Florian Weimer Cc: Iker Pedrosa Cc: Jens Gustedt Cc: Jonathan Wakely Cc: Mark

Re: Missed warning (-Wuse-after-free)

Hi Jonathan, On 2/17/23 12:24, Jonathan Wakely wrote: > Please be aware that in C++ it's implementation-defined, not undefined. > > That means that an implementation without trap representations for pointers > can choose to make it behave just like using (uintptr_t)p. (uintptr_t)p is defined (I

Re: Missed warning (-Wuse-after-free)

Hi Martin, On 2/17/23 09:12, Martin Uecker wrote: > Am Freitag, dem 17.02.2023 um 02:04 +0100 schrieb Alejandro Colomar > > >> >> [...] >> >>> >>> I'm not convinced that it's useful to the end-user to warn about >>> the >>> "use of q itself" case. >> >> I didn't quote the standard because I

Re: Missed warning (-Wuse-after-free)

Hi Siddhesh, On 2/17/23 04:48, Siddhesh Poyarekar wrote: > On 2023-02-16 10:15, David Malcolm via Gcc wrote: >> I'm not convinced that it's useful to the end-user to warn about the >> "use of q itself" case. > > FWIW, -Wuse-after-free=3 already should do this: Thanks! It works. I would have

Re: Missed warning (-Wuse-after-free)

On 2/17/23 02:04, Alejandro Colomar wrote: > [CC: Added those who contributed to the discussion in linux-man@, > and also the authors of N2861 for C2x] [...] > > There was a discussion in linux-man@ some years ago, which now I realize it > didn't end up being applied (I thought we had

Re: Missed warning (-Wuse-after-free)

[CC: Added those who contributed to the discussion in linux-man@, and also the authors of N2861 for C2x] Hi David, On 2/16/23 16:15, David Malcolm wrote: > On Thu, 2023-02-16 at 15:35 +0100, Alejandro Colomar via Gcc wrote: >> Hi! >> >> I was preparing an example p

Missed warning (-Wuse-after-free)

Hi! I was preparing an example program of a use-after-realloc bug, when I found that GCC doesn't warn in a case where it should. alx@debian:~/tmp$ cat realloc.c #include #include #include #include #include static inline char * xstrdup(const char *s) { char *p; p =

[wish] -Wmissing-array-initializers

Hi! I was wondering if we can have a warning similar to -Wmissing-field-initializers but for arrays. Here's some example of what kind of code would benefit from this warning: // foo.c char *foo[5] = { "foo", "bar", "baz" // oops, accidentally the size doesn't match the actual

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

Hello Eric, On 2/6/23 19:45, Eric Blake wrote: On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote: Regardless of the merits of the patch, let's not introduce typos: +++ b/man3type/sockaddr.3type @@ -120,6 +120,26 @@ .SH NOTES .I and .IR . +.SH BUGS +.I sockaddr_storage

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

Hi Rich, On 2/6/23 14:38, Rich Felker wrote: There is absolutely not any need to declare the union for application code calling the socket APIs. You declare whatever type you will be using. For binding or connecting a unix socket, sockaddr_un. For IPv6, sockaddr_in6. Etc. Then you cast the

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

Hi Xi, On 2/6/23 07:02, Xi Ruoyao wrote: On Sun, 2023-02-05 at 16:31 +0100, Alejandro Colomar via Libc-alpha wrote: The only correct way to use  different  types  in  an  API  is through  a  union. I don't think this statement is true (in general). Technically we can write something like

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

Hi Rich, On 2/6/23 00:43, Rich Felker wrote: On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote: As discussed before, and Bastien and I seem to agree, ideally we should define the following types: struct sockaddr_storage { union { struct {

Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

Formatted version: BUGS sockaddr_storage was designed back when strict aliasing wasn’t a prob‐ lem. Back then, one would define a variable of that type, and then ac‐ cess it as any of the other sockaddr_* types, depending on the value of the first member. This

[PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

As discussed before, and Bastien and I seem to agree, ideally we should define the following types: struct sockaddr_storage { union { struct { sa_family_t ss_family; }; struct sockaddr_in sin; struct sockaddr_in6

Re: struct sockaddr_storage

Hi Stefan, On 1/23/23 08:40, Stefan Puiu wrote: According to strict aliasing rules, if you declare a variable of type 'struct sockaddr_storage', that's what you get, and trying to access it later as some other sockaddr_8 is simply not legal. The compiler may assume those accesses can't happen,

  1   2   3   4   >