Re: ISO C3X proposal: nonnull qualifier

2021-12-02 Thread Alejandro Colomar (man-pages) via Gcc
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

2021-12-02 Thread Alejandro Colomar (man-pages) via Gcc
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 i(in

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

2021-12-01 Thread Alejandro Colomar (man-pages) via Gcc
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 n

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

2021-12-01 Thread Alejandro Colomar (man-pages) via Gcc
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 n

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

2021-11-23 Thread Alejandro Colomar (man-pages) via Gcc
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

2021-11-20 Thread Alejandro Colomar (man-pages) via Gcc
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

2021-11-16 Thread Alejandro Colomar (man-pages) via Gcc
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. On

Re: ISO C3X proposal: nonnull qualifier

2021-11-16 Thread Alejandro Colomar (man-pages) via Gcc
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

2021-11-15 Thread Alejandro Colomar (man-pages) via Gcc
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

2021-11-15 Thread Alejandro Colomar (man-pages) via Gcc
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 s

Re: ISO C3X proposal: nonnull qualifier

2021-11-15 Thread Alejandro Colomar (man-pages) via Gcc
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 an

ISO C3X proposal: nonnull qualifier

2021-11-15 Thread Alejandro Colomar (man-pages) via Gcc
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 g

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

2021-11-10 Thread Alejandro Colomar (man-pages) via Gcc
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: uint16_

Re: Ping: cacheflush.2

2020-12-19 Thread Alejandro Colomar (man-pages) via Gcc
"declarations" are specified in the 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=fa8b0641ab13b

Ping: cacheflush.2

2020-12-18 Thread Alejandro Colomar (man-pages) via Gcc
Thanks, > > 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 *&#

Re: cacheflush.2

2020-12-14 Thread Alejandro Colomar (man-pages) via Gcc
to the user declared? Thanks, 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 *'. >>

RFC v4: Re: cacheflush.2

2020-12-11 Thread Alejandro Colomar (man-pages) via Gcc
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

2020-12-11 Thread Alejandro Colomar (man-pages) via Gcc
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 __bui

Re: cacheflush.2

2020-12-11 Thread Alejandro Colomar (man-pages) via Gcc
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) wr

Re: RFC v2: Re: cacheflush.2

2020-12-11 Thread Alejandro Colomar (man-pages) via Gcc
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

2020-12-10 Thread Alejandro Colomar (man-pages) via Gcc
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 __builtin___clear_cache(vo

Re: cacheflush.2

2020-12-09 Thread Alejandro Colomar (man-pages) via Gcc
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