Re: ISO C3X proposal: nonnull qualifier

[Jonathan Wakely via Gcc]

On Mon, 15 Nov 2021, 21:15 Alejandro Colomar (man-pages) 
wrote:

> My intention is that the final PDF to be sent to the committee
> will have those diffs.
> But I have no clue of how to do that kind of things,
> so for an initial draft to discuss on,
> before even presenting it to the committee,
> I think my "native" language for writing technical documents
> will be easier.
>
> Also,
> I'm curious,
> do you do those diffs usually by hand?
>

Yes. Just highlight text in red and green, with strike through or
underlining.

If you write the paper in LaTeX you can use macros like:

\definecolor{addclr}{rgb}{0,.6,.6}
\definecolor{remclr}{rgb}{1,0,0}

\renewcommand{\added}[1]{\textcolor{addclr}{\uline{#1}}}
\newcommand{\removed}[1]{\textcolor{remclr}{\sout{#1}}}
\renewcommand{\changed}[2]{\removed{#1}\added{#2}}



I mean, you can't diff(1) a PDF, can you? :)
>

Aside: see diffpdf, which is packaged by some distros.

Re: Anything I can contribute?

[Martin Jambor]

Hi Kaisheng,

On Sat, Nov 13 2021, Deng Kaisheng wrote:
> Hi,
>
> My name is Deng Kaisheng, a graduate student in National University of
> Sinapore (NUS) now major in computer science. I've read the
> introduction of your organization and I'm quite interested in what
> you're doing.
>
> I want to do something and contribute to the community, and I wonder
> if there is something I can do. I major in computer science since
> undergraduate with a solid foundation in CS, and I'm also confident in
> my fast-learning skills. I have programming skills in C++, Python,
> Java, Objective-C, etc., and database skills in MySQL and Cassandra.
>
> I wonder if your organization is going to take part in the GSoC 2022,
> if possible, I would like to contribute to your project in GSOC 2022.
>
> I am looking forward to your reply!
>

I am delighted you found contributing to GCC interesting.  As far as
GSoC is concerned, at this time I can only point you to
https://gcc.gnu.org/wiki/SummerOfCode and specifically to
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply which explains
some of the steps you can take to familiarize yourself with our code
base.

Apart from what is described there, any further advice would depend on
what part of GCC you would like to contribute to.   Most of the projects
listed at the top of the page linked above will still be relevant in
2022.

If you have any further questions, this is the right spot to ask.

Good luck,

Martin

Re: ISO C3X proposal: nonnull qualifier

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


restrict has tricky rules about "based on" (6.7.3.1).


Hmm, I think I can "base on" that,
to define what I had in mind. :)


"based on" is about optimizations; I think it's even less suited to
anything relating to diagnostics than it is to optimization.

To restrict assignment between different kinds of pointers, I'd think
you'd want pointer type variants that differ in some way *other* than
qualifiers, a way that's unaffected by lvalue-to-rvalue conversion, but
that comes with its own rules on implicit conversion as if by assignment
(6.5.16.1) (though then you also need to work out what's allowed in terms
of mixing these pointer type variants in all the other operations allowing
pointers, what type results of pointer arithmetic have, etc.).  And there
should surely also be some way of converting a normal pointer to this
variant with a runtime check for NULL.

Note that discussion of prior art in such a proposal should also consider
relevant prior art (for constraining possible values of a variable through
the type system) in C++ or other languages if possible.



The only other language that I know is C++, so I'll talk about it:

C++ added long ago something close to this: references.
However, IMO:
- They don't provide any enforced safety at all.
  It's just as safe as using [[gnu::nonnull]].
  See an example code below showing why.
- They unnecessarily changed pointer syntax to use value syntax.
  This syntax has not been widely accepted by some C programmers,
  which would have to adapt their minds considerably.

Clang's _Nonnull (and _Nullable) qualifiers (are they?):
- Do have the safety that C++ references should have had,
  if they had been properly designed.
  Again, see the example code below.
- They have an intuitive syntax for C programmers,
  by just adding a qualifier to a pointer,
  you mark it as either possibly being NULL or not.

It has the appearance of a qualifier,
and the documentation refers to it as a qualifier,
but how does it implement it clang internally?
Is it implemented as a completely different type
with some implicit conversion rules?
I don't know.
See
.


---

$ cat nonnull.c
[[gnu::returns_nonnull]]
int *foo(int *p)
{
return p;
}
/*
 * No (nonnull-related) diagnostics from the following commands:
 * $ gcc -Wall -Wextra -std=gnu2x -S nonnull.c
 * $ clang -Weverything -std=gnu2x -S nonnull.c
 */

/**/

/* Clang only */
int *_Nonnull bar(int *_Nullable p)
{
return p;
}
/*
 * Clang provides safety here:
 *
 * $ clang -Weverything -std=gnu2x -S nonnull.c
 * nonnull.c:17:9: warning: implicit conversion from nullable pointer 
'int * _Nullable' to non-nullable pointer type 'int * _Nonnull' 
[-Wnullable-to-nonnull-conversion]

 * return p;
 *^
 */

/**/

/* C++ only */
int *baz(int *p)
{
int &q = *p;
return &q;
}
/* No (nonnull-related) diagnostics from the following commands:
 * $ gcc -Wall -Wextra -std=gnu++2b -S nonnull.cxx
 * $ clang -Weverything -std=gnu++20 -S nonnull.cxx
 */

---


So we have the following list of prior art:

- [[gnu::nonnull]]  (GCC)
- _Nonnull  (Clang)
- & (references)(C++)

From which I completely dislike references,
for not adding any real benefits,
and being unnecessarily unintuitive (to C programmers).

I like from _Nonnull that it enforces diagnostics.
And I like from [[gnu::nonnull]] that it allows optimizations.
I'm trying to mix them in a good way.

Since Clang's _Nonnull is closer to what I have in mind,
I did further tests to _Nonnull,
to see what I like,
and what I dislike:

---

$ 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(int *_Nonnull p)
{
return p;
}

---

First of all,
I see unnecessary (probably over-engineered) qualifiers:

- _Null_unspecified seems to me the same as nothing.
If I didn't specify its nullability,
it's by definition unspecified.  Right?

- _Nullable seems to me also the same as nothing.
The language allows for a pointer to be NULL,
so if you don't specify if it can or not be null,
you better stay on the safe side and consider it as nullable.

Then,
I see other problems:

- I don't get a warning from g(), nor from h(), which I'd want.
  To get something like const-safety,
  we need to design it so that it can be enforced;
  either you guarantee that a pointer cannot be NULL (_Nonnull),
  or you cannot guarantee it (not _Nonnull).
  Otherwise,

Getting started with open-source contributions

[RAMAN SHEKHAWAT (RA2011003010289) via Gcc]

Respected Sir/Ma'am,
I am Raman Shekhawat, a computer science undergraduate who has just entered
his second year of college at SRM University. I am new to open-source
contributions, but I am well versed with technologies like HTML5 and CSS,
and also with programming languages like C++ and JavaScript. I would love
to contribute to your organization but would require guidance from you on
how to get started. Looking forward to hearing from you soon.

Regards,
Raman

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

[Arthur O'Dwyer via Gcc]

On Tue, Nov 16, 2021 at 4:31 AM Jonathan Wakely via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> On Mon, 15 Nov 2021, 21:15 Alejandro Colomar (man-pages) 
> wrote:
>
>> Also, I'm curious, do you do those diffs usually by hand?
>>
>
> Yes. Just highlight text in red and green, with strike through or
> underlining.
>
> If you write the paper in LaTeX you can use macros like:
> \definecolor{addclr}{rgb}{0,.6,.6}
> \definecolor{remclr}{rgb}{1,0,0}
> \renewcommand{\added}[1]{\textcolor{addclr}{\uline{#1}}}
> \newcommand{\removed}[1]{\textcolor{remclr}{\sout{#1}}}
> \renewcommand{\changed}[2]{\removed{#1}\added{#2}}
>

Or, if you use Bikeshed, it's just the HTML tags  and . For
example:
https://github.com/Quuxplusone/draft/blob/29d1609da4182504dec7ada25b0700246bb7d86a/Makefile#L12
https://github.com/Quuxplusone/draft/blob/29d1609da4182504dec7ada25b0700246bb7d86a/d2266-implicit-move-rvalue-ref.bs#L529-L552
produces
https://quuxplusone.github.io/draft/d2266-implicit-move-rvalue-ref.html#wording

Even with Bikeshed, copy-pasting the standard text and marking up the diff
is still a manual process; but it *looks* pretty nice IMO, at both the
source level and the finished-product level.

HTH,
Arthur

Re: "musttail" statement attribute for GCC?

[Pietro Monteiro]

On Fri, 2021-04-23 at 16:07 -0400, David Malcolm wrote:
> On Fri, 2021-04-23 at 12:44 -0700, Josh Haberman via Gcc wrote:
> > Would it be feasible to implement a "musttail" statement attribute
> > in
> > GCC to get a guarantee that tail call optimization will be
> > performed?
> > 
> > Such an attribute has just landed in the trunk of Clang
> > (https://reviews.llvm.org/D99517). It makes it possible to write
> > algorithms that use arbitrarily long chains of tail calls without
> > risk
> > of blowing the stack. I would love to see something like this land
> > in
> > GCC also (ultimately I'd love to see it standardized).
> 
> 
> FWIW I implemented something like this in GCC's middle-end here:
>  
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9a385c2d3d74ffed78f2ed9ad47b844d2f294105
> exposing it in API form for libgccjit:
>  
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=15c671a79ca66df5b1de70dd1a0b78414fe003ef
>  
> https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html#c.gcc_jit_rvalue_set_bool_require_tail_call
> but IIRC it's not yet exposed to the regular GCC frontends.

I hacked on the plugin you created to test CALL_EXPR_MUST_TAIL_CALL to
add the musttail attribute for functions and pushed it here:

https://github.com/pietro/gcc-musttail-plugin

This patch adds it to the plugin testsuite and successfully runs the
same tests as the original plugin:

https://gist.github.com/pietro/9a582b054b008e9a4ad3e1afe3a4cc22

It seems that in order to be able to add attributes to the return
statement changes are needed to the frontend parser. If this attribute
is something people think is usefull I'll try to implement it as a
proper patch to GCC.

Pietro

Re: ISO C3X proposal: nonnull qualifier

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


- I get a warning from f().
   Ideally,
   a programmer should not need to cast
   (casts are dangerous),
   to convert a nullable pointer to a _Nonnull pointer.
   For that,
   appropriate checks should be in the preceeding code.
   Otherwise, a diagnostic should be issued.
   To be on the safe side,
   if a compiler has doubts,
   it should diagnose.

   There's some Clang document that talks about something similar.
   I don't know its validity,
   or if it was a draft before _Nonnull qualifiers.
   


That document suggests that I shouldn't get a diagnostic from f().
Why did I get a diagnostic?  (I tried clang 11, 13 & 14(experimental))


Is it talking about a different nonnull attribute/qualifier?
Was it about a proposal prior to the current _Nonnull?
Why is it not in use?  Was it too difficult to implement?


Do you think Clang could be improved to not warn on f()?


Thanks,
Alex