Re: ISO C3X proposal: nonnull qualifier

On 12/2/21 21:24, Alejandro Colomar (man-pages) wrote: #define nonnull_assign(nn, p) \ ({    \     auto p_  = p; \     auto nn_ = nn;    \

Re: ISO C3X proposal: nonnull qualifier

On 11/16/21 13:34, Alejandro Colomar (man-pages) wrote: $ cat _Nonnull.c #include int *_Nonnull f(int *_Nullable p) { if (!p)     exit(1); return p; } int *_Nonnull g(int *_Null_unspecified p) { return p; } int *_Nonnull h(int *p) { return p; } int *_Nullable

Re: [cfe-dev] ISO C3X proposal: nonnull qualifier

Hi Dmitri On 12/2/21 01:39, Dmitri Gribenko wrote: Pre-C3X headers won't work correctly when included in C3X programs, making incremental adoption of C3X syntax, as it was intended to be used, impossible. Projects would likely invent a NULLABLE macro, which would expand to _Nullable in C3X and

Re: [cfe-dev] ISO C3X proposal: nonnull qualifier

Hi Dmitry, On 11/23/21 13:45, Dmitri Gribenko wrote: >> >> Let's imagine a scenario where C3X specifies that non-qualified pointers >> are nonnull. And there's only a qualifier, _Nullable, to allow NULL. >> Asigning _Nullable to nonnull would issue a diagnostic. > > I think C3X specifying that

Re: [cfe-dev] ISO C3X proposal: nonnull qualifier

Hi Dmitry, On 11/23/21 12:17, Dmitri Gribenko wrote: Hi Alejandro, On Tue, Nov 16, 2021 at 1:34 PM Alejandro Colomar (man-pages) via cfe-dev wrote: First of all, I see unnecessary (probably over-engineered) qualifiers: - _Null_unspecified seems to me the same as nothing. If I didn't specify

Ping: ISO C3X proposal: nonnull qualifier

Ping On 11/17/21 01:06, Alejandro Colomar (man-pages) wrote: Hi, Sorry for Clang people, when I started this thread, I wasn't subscribed to your list, and some messages are not on your list. You can find the complete thread on the GCC list:

Re: ISO C3X proposal: nonnull qualifier

Hi, Sorry for Clang people, when I started this thread, I wasn't subscribed to your list, and some messages are not on your list. You can find the complete thread on the GCC list: I have a few questions for you. See below, please.

Re: ISO C3X proposal: nonnull qualifier

Hi Joseph, On 11/15/21 23:47, Joseph Myers wrote: On Mon, 15 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote: Hi Joseph, On 11/15/21 23:17, Joseph Myers wrote: On Mon, 15 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote: How is restrict handling that problem of lvalue-to-rvalue

Re: ISO C3X proposal: nonnull qualifier

Hi Joseph, On 11/15/21 23:17, Joseph Myers wrote: On Mon, 15 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote: How is restrict handling that problem of lvalue-to-rvalue already? restrict has tricky rules about "based on" (6.7.3.1). Hmm, I think I can "base on" th

Re: ISO C3X proposal: nonnull qualifier

Hi Joseph, On 11/15/21 21:18, Joseph Myers wrote: lvalue-to-rvalue conversion loses qualifiers, which makes any rules based on whether the RHS of an assignment was nonnull-qualified very problematic. (The specification of restrict is exceedingly tricky and very unlikely to be a good basis for

Re: ISO C3X proposal: nonnull qualifier

Hi, On 11/15/21 5:01 PM, Alejandro Colomar (man-pages) wrote: > Hi all, > > I'd like to propose the following feature for ISO C (and also ISO C++). > It is based on a mix of GCC's [[gnu::nonnull]] and Clang's _Nonnull, > with a pinch of salt of mine. > > I'd like to get some feedback from GCC

ISO C3X proposal: nonnull qualifier

Hi all, I'd like to propose the following feature for ISO C (and also ISO C++). It is based on a mix of GCC's [[gnu::nonnull]] and Clang's _Nonnull, with a pinch of salt of mine. I'd like to get some feedback from GCC and Clang, before sending it as an official proposal. BTW, since the working

New attribute proposal: [[gnu::no_int_promotion]]

Hi, Usual arithmetic promotions are (sometimes) quite unexpected. Especially, in random architectures where int may be wider than expected. Fixed-width math in C has been partially supported since C99. I say partially, because the following code may surprise some (few) programmers:

Re: [PATCH v3] bpf.2: Use standard types and attributes

On 5/15/21 9:01 PM, Alejandro Colomar wrote: Some manual pages are already using C99 syntax for integral types 'uint32_t', but some aren't. There are some using kernel syntax '__u32'. Fix those. Both the kernel and the standard types are 100% binary compatible, and the source code differences

Re: [RFC v2] bpf.2: Use standard types and attributes

Hi Daniel, On 5/4/21 10:06 PM, Daniel Borkmann wrote: On 5/4/21 6:08 PM, Daniel Borkmann wrote:  >  > But what /problem/ is this really solving? Why bother to change this /now/  > after so many years?! I think this is causing more confusion than solving  > anything, really. Moreover, what

Re: [RFC v2] bpf.2: Use standard types and attributes

Hi Florian, On 5/4/21 9:45 PM, Florian Weimer wrote: * Alejandro Colomar: The thing is, in all of those threads, the only reasons to avoid types in the kernel (at least, the only explicitly mentioned ones) are (a bit simplified, but this is the general idea of those threads): * Possibly

Re: [RFC v2] bpf.2: Use standard types and attributes

Hi Greg, Daniel, On 5/4/21 6:06 PM, Greg KH wrote: > There's a very old post from Linus where he describes the difference > between things like __u32 and uint32_t. They are not the same, they > live in different namespaces, and worlds, and can not always be swapped > out for each other on all

Re: [RFC v2] bpf.2: Use standard types and attributes

Hi Greg and Alexei, On Tue, May 04, 2021 at 07:12:01AM -0700, Alexei Starovoitov wrote: For the same reasons as explained earlier: Nacked-by: Alexei Starovoitov Okay, I'll add that. On 5/4/21 4:24 PM, Greg KH wrote:> I agree, the two are not the same type at all, this change should not

Re: [RFC] bpf.2: Use standard types and attributes

Hi Joseph, On 4/26/21 7:19 PM, Joseph Myers wrote: On Sat, 24 Apr 2021, Alejandro Colomar via Libc-alpha wrote: Some pages also document attributes, using GNU syntax '__attribute__((xxx))'. Update those to use the shorter and more portable C2x syntax, which hasn't been standardized yet, but

Re: [RFC] bpf.2: Use standard types and attributes

Hello Alexei, On 4/24/21 1:20 AM, Alexei Starovoitov wrote: Nack. The man page should describe the kernel api the way it is in .h file. Why? When glibc uses __size_t (or any other non-standard types) just because the standard doesn't allow it to define some types in some specific header,

Ping: [PATCH v6] cacheflush.2: Document __builtin___clear_cache() as a more portable alternative

Ping On 12/15/20 2:30 PM, Alejandro Colomar wrote: > Reported-by: Heinrich Schuchardt > Signed-off-by: Alejandro Colomar > Cc: Martin Sebor > Cc: Dave Martin > --- > > v6: > - GCC has always exposed 'void *', as Martin Sebor noted. > It's Clang (and maybe others) that (following GCC's

Re: Ping: cacheflush.2

e GCC internal file > gcc/builtins.def, where they are hidden behind layers of macros. > For example, on the GCC 10 branch, the declaration for > __builtin___clear_cache is here: > > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/builtins.def;h=fa8b0641ab13b36f983c591a7020f6b432e5fb3d;hb=refs/heads/rel

Ping: cacheflush.2

> > P.S.: Michael, wait for a patch revision (v6). > > On 12/14/20 10:13 PM, Martin Sebor wrote: >> On 12/11/20 11:14 AM, Alejandro Colomar (man-pages) via Gcc wrote: >>> It looks like GCC recently moved from 'char *' to 'void *'. >>> This SO question[1] (4 years ago) qu

Re: cacheflush.2

, Alex P.S.: Michael, wait for a patch revision (v6). On 12/14/20 10:13 PM, Martin Sebor wrote: > On 12/11/20 11:14 AM, Alejandro Colomar (man-pages) via Gcc wrote: >> It looks like GCC recently moved from 'char *' to 'void *'. >> This SO question[1] (4 years ago) quot

RFC v4: Re: cacheflush.2

I forgot to add a junk to the text. v4: NOTES Unless you need the finer grained control that this system call provides, you probably want to use the GCC built-in function __builtin___clear_cache(), which provides a portable interface across platforms supported

RFC v3: Re: cacheflush.2

Hi all, Please review this text: [ NOTES Unless you need the finer grained control that this system call provides, you probably want to use the GCC built-in function __builtin___clear_cache(), which provides a more portable interface: void

Re: cacheflush.2

It looks like GCC recently moved from 'char *' to 'void *'. This SO question[1] (4 years ago) quotes the GCC docs and they had 'char *'. Maybe Clang hasn't noticed the change. I'll report a bug. [1]: https://stackoverflow.com/q/35741814/6872717 On 12/9/20 8:15 PM, Alejandro Colomar (man-pages)

Re: RFC v2: Re: cacheflush.2

Hi Michael, On 12/11/20 9:15 AM, Michael Kerrisk (man-pages) wrote: > i Alex, > > On 12/10/20 9:56 PM, Alejandro Colomar (man-pages) wrote: >> Hi all, >> >> v2: >> >> [ >> NOTES >>Unless you need the finer grained control that this system >>call provides, you probably want to

RFC v2: Re: cacheflush.2

Hi all, v2: [ NOTES Unless you need the finer grained control that this system call provides, you probably want to use the GCC built-in function __builtin___clear_cache(), which provides a more portable interface: void

Re: cacheflush.2

Hi Heinrich, It looks like a bug (or at least an undocumented divergence from GCC) in Clang/LLVM. Or I couldn't find the documentation for it. Clang uses 'char *': https://github.com/llvm/llvm-project/blob/7faf62a80bfc3a9dfe34133681fcc31f8e8d658b/clang/include/clang/Basic/Builtins.def#L583 GCC