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,

Re: [PATCH v2] socket: Implement sockaddr_storage with an anonymous union

Hi Bastien, On 1/21/23 14:30, Bastien Roucariès wrote: [...] Ahh, indeed it seems to be UB. It's in the same 6.5.2.3/6: there's a requirement that the information about the union is kept in the function in which it's accessed. The standard presents an example, which is a bit ambiguous:

Re: [PATCH v2] socket: Implement sockaddr_storage with an anonymous union

Hi Zack, On 1/21/23 03:38, Alejandro Colomar wrote: Hi Zack, On 1/20/23 20:25, Alejandro Colomar wrote: [CC += GCC]  // pun not intended :P Hi Zack, On 1/20/23 19:04, Zack Weinberg wrote: On Fri, Jan 20, 2023, at 8:40 AM, Alejandro Colomar wrote: The historical design of

Re: [PATCH v2] socket: Implement sockaddr_storage with an anonymous union

Hi Zack, On 1/20/23 20:25, Alejandro Colomar wrote: [CC += GCC]  // pun not intended :P Hi Zack, On 1/20/23 19:04, Zack Weinberg wrote: On Fri, Jan 20, 2023, at 8:40 AM, Alejandro Colomar wrote: The historical design of `sockaddr_storage` makes it impossible to use without breaking strict

Re: [PATCH v2] socket: Implement sockaddr_storage with an anonymous union

On 1/20/23 21:46, Bastien Roucariès wrote: Le vendredi 20 janvier 2023, 20:38:32 UTC Alejandro Colomar a écrit : Hi Bastien, On 1/20/23 21:32, Bastien Roucariès wrote: [...] diff --git a/bits/socket.h b/bits/socket.h index aac8c49b00..c0c23b4e84 100644 --- a/bits/socket.h +++

Re: [PATCH v2] socket: Implement sockaddr_storage with an anonymous union

Hi Bastien, On 1/20/23 21:32, Bastien Roucariès wrote: [...] diff --git a/bits/socket.h b/bits/socket.h index aac8c49b00..c0c23b4e84 100644 --- a/bits/socket.h +++ b/bits/socket.h @@ -168,9 +168,14 @@ struct sockaddr struct sockaddr_storage { -__SOCKADDR_COMMON (ss_); /*

Re: [PATCH v2] socket: Implement sockaddr_storage with an anonymous union

[CC += GCC] // pun not intended :P Hi Zack, On 1/20/23 19:04, Zack Weinberg wrote: On Fri, Jan 20, 2023, at 8:40 AM, Alejandro Colomar wrote: The historical design of `sockaddr_storage` makes it impossible to use without breaking strict aliasing rules. Not only this type is unusable, but

Re: struct sockaddr_storage

Hi Stefan, On 1/20/23 11:06, Stefan Puiu wrote: Hi Alex, On Thu, Jan 19, 2023 at 4:14 PM Alejandro Colomar wrote: Hi! I just received a report about struct sockaddr_storage in the man pages. It reminded me of some concern I've always had about it: it doesn't seem to be a usable type. It

struct sockaddr_storage

Hi! I just received a report about struct sockaddr_storage in the man pages. It reminded me of some concern I've always had about it: it doesn't seem to be a usable type. It has some alignment promises that make it "just work" most of the time, but it's still a UB mine, according to ISO C.

Re: stdc_bit_ceil(3) and wrapping

On 12/30/22 23:33, Alejandro Colomar wrote: Hi Yann, On 12/30/22 21:33, Alejandro Colomar wrote: On 12/30/22 21:18, Yann Droneaud wrote: What's wrong with the following ? [...] unsigned long max = upper_bound - 1; unsigned long mask = ULONG_MAX >> __builtin_clzl(max); I

Re: stdc_bit_ceil(3) and wrapping

Hi Yann, On 12/30/22 21:33, Alejandro Colomar wrote: On 12/30/22 21:18, Yann Droneaud wrote: What's wrong with the following ? [...] unsigned long max = upper_bound - 1; unsigned long mask = ULONG_MAX >> __builtin_clzl(max); I hate coding these magic operations out of a

Re: stdc_bit_ceil(3) and wrapping

On 12/30/22 22:01, Alejandro Colomar wrote: On 12/30/22 21:56, Joseph Myers wrote: On Fri, 30 Dec 2022, Alejandro Colomar via Gcc wrote: For the C standard, shifts have wrap around semantics for unsigned types: Only if the shift count is nonnegative and strictly less than the width

Re: stdc_bit_ceil(3) and wrapping

On 12/30/22 21:56, Joseph Myers wrote: On Fri, 30 Dec 2022, Alejandro Colomar via Gcc wrote: For the C standard, shifts have wrap around semantics for unsigned types: Only if the shift count is nonnegative and strictly less than the width of the type. This is about shifting by an amount

Re: stdc_bit_ceil(3) and wrapping

Hi Yann, On 12/30/22 21:18, Yann Droneaud wrote: 30 décembre 2022 à 20:55 "Alejandro Colomar via Libc-alpha" a écrit: I'm implementing a small part of equivalent code for shadow. I need stdc_bit_ceilul() for a random number generator limited to a range (you've seen some of this in the

Re: stdc_bit_ceil(3) and wrapping

Hi Joseph, On 12/30/22 21:38, Joseph Myers wrote: On Fri, 30 Dec 2022, Alejandro Colomar via Gcc wrote: I was wondering if there was any reason to make that UB in the standard, when unsigned wrapping has always been well-defined, and this is a case that is likely to be implemented with some

Re: stdc_bit_ceil(3) and wrapping

Hi Yann, On 12/30/22 21:18, Yann Droneaud wrote: Hi, 30 décembre 2022 à 20:55 "Alejandro Colomar via Libc-alpha" a écrit: I'm implementing a small part of equivalent code for shadow. I need stdc_bit_ceilul() for a random number generator limited to a range (you've seen some of this in the

stdc_bit_ceil(3) and wrapping

Hi Joseph, I'm implementing a small part of equivalent code for shadow. I need stdc_bit_ceilul() for a random number generator limited to a range (you've seen some of this in the glibc mailing list. $ grepc -tfd shadow_random_uniform ./libmisc/random.c:76: unsigned long

Re: -minstd: Require a minimum std version, without being specific

Hi Alexander, On 12/21/22 20:12, Alexander Monakov wrote: On Wed, 21 Dec 2022, Alejandro Colomar via Gcc wrote: There's already a standard, portable way to check: #if __STDC_VERSION__ < 201710 #error C17 required #endif Hmm, not my favourite to stick that in every public header f

Re: -minstd: Require a minimum std version, without being specific

On 12/21/22 19:53, Alejandro Colomar wrote: Hi Alexander, On 12/21/22 19:51, Alexander Monakov wrote: On Wed, 21 Dec 2022, Alejandro Colomar via Gcc wrote: Hi, I've long had this wish: an option similar to -std, but which would not specify the standard.  Rather, mark a requirement

Re: -minstd: Require a minimum std version, without being specific

Hi Alexander, On 12/21/22 19:51, Alexander Monakov wrote: On Wed, 21 Dec 2022, Alejandro Colomar via Gcc wrote: Hi, I've long had this wish: an option similar to -std, but which would not specify the standard. Rather, mark a requirement that the standard be at least a version. This would

-minstd: Require a minimum std version, without being specific

Hi, I've long had this wish: an option similar to -std, but which would not specify the standard. Rather, mark a requirement that the standard be at least a version. This would be especially useful for libraries, which might for example require C99 or C11 to work. They would be able to

Optimization levels for getting all warnings (was: [BUG] missing warning for pointer arithmetic out of bounds)

Hi Andrew On 12/13/22 20:18, Andrew Pinski wrote: [...] GCC only warns during VRP which is only enabled at -O2: :8:12: warning: array subscript 6 is outside array bounds of 'char[5]' [-Warray-bounds=] 8 | p = buf + 6; | ~~^ :6:19: note: at offset 6 into

Re: [-Wstringop-overflow=] strncat(3)

Hi Martin, On 12/15/22 21:50, Martin Sebor wrote: On 12/14/22 16:14, Alejandro Colomar via Libc-alpha wrote: [...]    int    main(void)    {    char    buf[BUFSIZ];    size_t  len;    buf[0] = '\0';  // There’s no ’cpy’ function

Re: [-Wstringop-overflow=] strncat(3)

[CC += groff] Hi Andrew, On 12/14/22 23:57, Andrew Pinski wrote: On Wed, Dec 14, 2022 at 2:46 PM Alejandro Colomar via Libc-alpha wrote: Hi, I was rewriting the strncat(3) manual page, and when I tried to compile the example program, I got a surprise from the compiler. Here goes the page:

Re: [-Wstringop-overflow=] strncat(3)

On 12/14/22 23:51, Alejandro Colomar wrote: On 12/14/22 23:45, Alejandro Colomar wrote: Hi, I was rewriting the strncat(3) manual page, and when I tried to compile the example program, I got a surprise from the compiler. Here goes the page:    strncat(3)   Library

Re: [-Wstringop-overflow=] strncat(3)

On 12/14/22 23:45, Alejandro Colomar wrote: Hi, I was rewriting the strncat(3) manual page, and when I tried to compile the example program, I got a surprise from the compiler. Here goes the page:   strncat(3)   Library Functions Manual  strncat(3)   NAME  

[-Wstringop-overflow=] strncat(3)

Hi, I was rewriting the strncat(3) manual page, and when I tried to compile the example program, I got a surprise from the compiler. Here goes the page: strncat(3) Library Functions Manual strncat(3) NAME strncat - concatenate a null‐padded

Re: [BUG] missing warning for pointer arithmetic out of bounds

Hi Paul, On 12/13/22 20:22, Paul Koning wrote: On Dec 13, 2022, at 2:08 PM, Alejandro Colomar via Gcc wrote: Hi! For the following program: $ cat buf.c #include int main(void) { char *p, buf[5]; p = buf + 6; printf("%p\

Re: [BUG] missing warning for pointer arithmetic out of bounds

On 12/13/22 20:08, Alejandro Colomar wrote: Hi! For the following program:     $ cat buf.c     #include     int main(void)     {     char *p, buf[5];     p = buf + 6;     printf("%p\n", p);     } There are no warnings in gcc, as I would expect: I just re-read my

[BUG] missing warning for pointer arithmetic out of bounds

Hi! For the following program: $ cat buf.c #include int main(void) { char *p, buf[5]; p = buf + 6; printf("%p\n", p); } There are no warnings in gcc, as I would expect: $ gcc -Wall -Wextra buf.c -O0 Clang does warn, however: $ clang

Re: Missing optimization: mempcpy(3) vs memcpy(3)

Hi Jakub, On 12/12/22 17:09, Jakub Jelinek wrote: On Mon, Dec 12, 2022 at 04:56:27PM +0100, Alejandro Colomar wrote: "Names beginning with ‘str’, ‘mem’, or ‘wcs’ followed by a lowercase letter are reserved for additional string and array functions. See String and Array Utilities." It is not

Re: Missing optimization: mempcpy(3) vs memcpy(3)

Hi Jonathan and Jakub, On 12/12/22 15:53, Jakub Jelinek wrote: On Mon, Dec 12, 2022 at 02:48:35PM +, Jonathan Wakely wrote: On Mon, 12 Dec 2022 at 14:09, Alejandro Colomar wrote: On 12/12/22 14:56, Jakub Jelinek wrote: I think that is the case, plus the question if one can use a

Re: Missing optimization: mempcpy(3) vs memcpy(3)

Hi Jakub, On 12/12/22 14:56, Jakub Jelinek wrote: On Mon, Dec 12, 2022 at 02:44:04PM +0100, Alejandro Colomar via Gcc wrote: I don't see any problem with the code snippets you provided. Well, then the optimization may be the other way around (although I question why it is implemented

Re: Missing optimization: mempcpy(3) vs memcpy(3)

Hi Martin, On 12/12/22 14:37, Martin Liška wrote: On 12/9/22 18:11, Alejandro Colomar via Gcc wrote: I expect the compiler to be knowledgeable enough to call whatever is fastest, whatever it is, but be consistent in both cases.  However, here are the results: Hi. Note the glibc

Re: Spurious warning for zero-sized array parameters to a function

On 12/9/22 21:19, Alejandro Colomar wrote: Hi Martin, On 12/9/22 21:04, mse...@gmail.com wrote: Most of these warnings are designed to find simple mistakes in common use cases so "tricky," unusual, or otherwise unexpected code is likely to lead to surprises.  This warning expects that in

Re: Spurious warning for zero-sized array parameters to a function

Hi Martin, On 12/9/22 21:04, mse...@gmail.com wrote: Most of these warnings are designed to find simple mistakes in common use cases so "tricky," unusual, or otherwise unexpected code is likely to lead to surprises. This warning expects that in calls to a function, every parameter declared

Re: Spurious warning for zero-sized array parameters to a function

Hi Richard, On 12/7/22 09:17, Richard Biener wrote: [...] The warnings are invalid. While it's true that I'm referencing a pointer of size 0, it's false that I'm "accessing 1 byte" in that region. I guess this is all about the bogus design of 'static' in ISO C, where you can have an array

Missing optimization: mempcpy(3) vs memcpy(3)

Hi! I expect mempcpy(3) to be at least as fast as memcpy(3), since it performs the same operations, with the exception that mempcpy(3) returns something useful (as opposed to memcpy(3), which could perfectly return void), and in fact something more likely to be in cache, if the copy is

Spurious warning for zero-sized array parameters to a function

Hi! In the following function, past_end is a pointer to one-past-the-end of the array. Holding such a pointer is legal in C. I use it as a sentinel value that helps (1) avoid overrunning the buffer, and (2) detect truncation. I mark it as having a size of [0], which clearly states that it

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi Martin and Andrew! On 12/3/22 22:15, Martin Uecker wrote: Am Samstag, dem 03.12.2022 um 22:03 +0100 schrieb Alejandro Colomar: ... Since we've seen that using a '.' prefix seems to be problematic because of lookahead, and recently Michael Matz proposed using a different punctuator (he

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi! I'll probably have to release again before the Debian freeze of Bookworm. That's something I didn't want to do, but there's some important bug that affects downstream projects (translation pages), and I need to release. It's a bit weird that the bug has been reported now, because it has

Using size_t to crash on off-by-one errors (was: size_t vs long.)

Hi, On 11/18/22 00:04, Alejandro Colomar wrote: The main advantage of this code compared to the equivalent ssize_t or ptrdiff_t or idx_t code is that if you somehow write an off-by-one error, and manage to access the array at [-1], if i is unsigned you'll access [SIZE_MAX], which will

Re: size_t vs long.

Hi Paul, On 11/17/22 22:39, Paul Eggert wrote: Second and more important, that code is bogus. Nobody should ever write code like that. If I wrote code like that, I'd *want* a trap. for (size_t i = 41; i < sizeof A / sizeof A[0]; --i) {    A[i] = something_nice; } The code above seems a bug

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

Hi Joseph! On 11/14/22 18:52, Joseph Myers wrote: On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote: Maybe allowing integral types and pointers would be enough. However, foreseeing that the _Lengthof() proposal (BTW, which paper was it?) will succeed, and combining it with this one

  1   2   3   >