Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #169082 > unrolled thread

[RFC] _Optional: a type qualifier to indicate pointer nullability

Back to article view | Back to comp.lang.c

Contents

  [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-28 08:15 -0800
    Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Richard Damon <Richard@Damon-Family.org> - 2023-01-28 11:31 -0500
      Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-29 01:02 -0800
        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Richard Damon <Richard@Damon-Family.org> - 2023-01-29 13:00 -0500
          Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-29 12:48 -0800
            Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Richard Damon <Richard@Damon-Family.org> - 2023-01-29 16:37 -0500
              Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-29 14:18 -0800
                Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Richard Damon <Richard@Damon-Family.org> - 2023-01-29 18:00 -0500
                Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-30 00:00 +0000
                  Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-30 14:57 -0800
                    Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-30 23:28 +0000
                      Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-30 23:39 -0800
                        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-31 12:19 -0500
                          Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-31 09:39 -0800
                        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Kaz Kylheku <864-117-4973@kylheku.com> - 2023-02-01 01:59 +0000
                    Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Richard Damon <Richard@Damon-Family.org> - 2023-01-30 21:05 -0500
                      Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-31 00:05 -0800
                Re: [RFC] _Optional: a type qualifier to indicate pointer nullability James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-30 02:13 -0500
            Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Andrew Smallshaw <andrews@sdf.org> - 2023-01-29 21:52 +0000
              Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-29 14:44 -0800
          Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-29 13:17 -0800
            Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Richard Damon <Richard@Damon-Family.org> - 2023-01-29 16:48 -0500
              Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-29 14:36 -0800
                Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Richard Damon <Richard@Damon-Family.org> - 2023-01-29 18:10 -0500
                  Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-29 23:33 +0000
                    Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Richard Damon <Richard@Damon-Family.org> - 2023-01-29 18:50 -0500
                      Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-30 01:05 +0000
                        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Richard Damon <Richard@Damon-Family.org> - 2023-01-29 21:02 -0500
                          Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-30 14:11 +0000
                            Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-30 15:22 -0800
        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-30 02:19 -0500
          Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-30 03:16 -0800
            Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Richard Harnden <richard.nospam@gmail.com> - 2023-01-30 12:48 +0000
              Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-30 14:19 +0000
                Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Richard Harnden <richard.nospam@gmail.com> - 2023-01-30 18:10 +0000
          Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-30 15:05 -0800
            Re: [RFC] _Optional: a type qualifier to indicate pointer nullability James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-31 01:15 -0500
    Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-29 02:24 +0000
      Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-29 01:21 -0800
        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-29 13:35 +0000
          Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-29 07:21 -0800
        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-29 13:46 +0000
          Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-29 06:54 -0800
    Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Oğuz <oguzismailuysal@gmail.com> - 2023-01-29 12:24 +0300
      Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-29 07:55 -0800
      Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-29 08:03 -0800
        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Oğuz <oguzismailuysal@gmail.com> - 2023-01-29 20:43 +0300
        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-29 19:03 -0800
          Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Richard Damon <Richard@Damon-Family.org> - 2023-01-29 22:23 -0500
    Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Thiago Adams <thiago.adams@gmail.com> - 2023-01-29 12:53 -0800
      Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-29 13:31 -0800
        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Thiago Adams <thiago.adams@gmail.com> - 2023-01-29 13:42 -0800
          Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-29 14:27 -0800
            Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Thiago Adams <thiago.adams@gmail.com> - 2023-01-31 04:56 -0800
        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Thiago Adams <thiago.adams@gmail.com> - 2023-01-29 13:46 -0800
        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Richard Damon <Richard@Damon-Family.org> - 2023-01-29 16:54 -0500
    Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-31 07:54 -0800
      Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Christopher Bazley <cs99cjb@gmail.com> - 2023-01-31 09:25 -0800
        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability bart c <bart4858@gmail.com> - 2023-01-31 14:44 -0800
          Re: [RFC] _Optional: a type qualifier to indicate pointer nullability David Brown <david.brown@hesbynett.no> - 2023-02-01 09:45 +0100
        Re: [RFC] _Optional: a type qualifier to indicate pointer nullability James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-31 18:00 -0500
          Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-01-31 15:52 -0800
            Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-02-01 00:04 +0000
              Re: [RFC] _Optional: a type qualifier to indicate pointer nullability David Brown <david.brown@hesbynett.no> - 2023-02-01 09:29 +0100
                Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-02-01 02:31 -0800
    Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Siri Cruise <chine.bleu@yahoo.com> - 2023-01-31 18:07 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#169082 — [RFC] _Optional: a type qualifier to indicate pointer nullability

Hi all,

I've just submitted my paper n3089, “_Optional: a type qualifier to indicate pointer nullability” to the WG14 committee.

This is either the most important thing I've ever written or a waste of a few months of research, design, prototyping and testing. Obviously, I'm hoping that it isn't the latter, but I'm fully prepared for that outcome! :) If you have time and interest in how to improve the C programming language, then please read on.

Abstract: This paper proposes a new type qualifier for the purpose of adding pointer nullability information to C programs. Its goal is to provide value not only for static analysis and documentation, but also for compilers which report errors based only on existing type-compatibility rules. The syntax and semantics are designed to be as familiar (to C programmers) and ergonomic as possible. In contrast, existing solutions are incompatible, confusing, error-prone, and intrusive.

I wrote a Medium article with much the same content as my paper, which is published here: https://medium.com/itnext/why-c-needs-a-new-type-qualifier-61ad553cbe71

I created a fully working prototype of my change in Clang (both simple type-compatibility rules, and static analyzer) . The stack of my commits (many fixing latent bugs in the existing attempt at path-sensitive analysis of null pointers) is here: https://reviews.llvm.org/D142744

I also started a discussion thread on the LLVM forums here: https://discourse.llvm.org/t/rfc-optional-a-type-qualifier-to-indicate-pointer-nullability/68004
My initial forum post discusses the necessary changes to Clang in a lot more detail than the WG14 paper does.

Thanks for reading!

[toc] | [next] | [standalone]

#169083

On 1/28/23 11:15 AM, Christopher Bazley wrote:
> Hi all,
> 
> I've just submitted my paper n3089, “_Optional: a type qualifier to indicate pointer nullability” to the WG14 committee.
> 
> This is either the most important thing I've ever written or a waste of a few months of research, design, prototyping and testing. Obviously, I'm hoping that it isn't the latter, but I'm fully prepared for that outcome! :) If you have time and interest in how to improve the C programming language, then please read on.
> 
> Abstract: This paper proposes a new type qualifier for the purpose of adding pointer nullability information to C programs. Its goal is to provide value not only for static analysis and documentation, but also for compilers which report errors based only on existing type-compatibility rules. The syntax and semantics are designed to be as familiar (to C programmers) and ergonomic as possible. In contrast, existing solutions are incompatible, confusing, error-prone, and intrusive.
> 
> I wrote a Medium article with much the same content as my paper, which is published here: https://medium.com/itnext/why-c-needs-a-new-type-qualifier-61ad553cbe71
> 
> I created a fully working prototype of my change in Clang (both simple type-compatibility rules, and static analyzer) . The stack of my commits (many fixing latent bugs in the existing attempt at path-sensitive analysis of null pointers) is here: https://reviews.llvm.org/D142744
> 
> I also started a discussion thread on the LLVM forums here: https://discourse.llvm.org/t/rfc-optional-a-type-qualifier-to-indicate-pointer-nullability/68004
> My initial forum post discusses the necessary changes to Clang in a lot more detail than the WG14 paper does.
> 
> Thanks for reading!


Since the current default of a pointer type is to allow null values, 
wouldn't you need a modifier to say it can't be null, otherwise you 
break all existing code with the change.

[toc] | [prev] | [next] | [standalone]

#169092

On Saturday, 28 January 2023 at 16:31:49 UTC, Richard Damon wrote:
> On 1/28/23 11:15 AM, Christopher Bazley wrote: 
> > Hi all, 
> > 
> > I've just submitted my paper n3089, “_Optional: a type qualifier to indicate pointer nullability” to the WG14 committee. 
> Since the current default of a pointer type is to allow null values, 
> wouldn't you need a modifier to say it can't be null, otherwise you 
> break all existing code with the change.

Hi Richard,

I believe that I addressed that question in the 'Migration of
existing code' part of my proposal:

> Requiring implementations to redefine the constant to which the
> NULL macro expands as ((_Optional void *)0) is unthinkable
> because it would invalidate all existing code. However, it might
> be useful to standardize an alternative macro for use in place
> of NULL. I have not specified such a macro because NULL is
> not a core part of the language.

If your question is "Why create an _Optional qualifier instead of
_Mandatory?" then the answer is twofold:

 1.  Pointers that can be null in function parameters are
 outnumbered by pointers that cannot be null without
provoking undefined behaviour. I believe that a count of
 parameters to functions in the C standard library would
show this, although I haven’t actually done such a count.

2. Assigning a pointer to a _Mandatory-qualified type to
a pointer to an unqualified type would provoke a warning,
whereas a pointer to an unqualified type could be
assigned to a pointer to a _Mandatory-qualified type
without provoking a warning. (This is the opposite of the
required semantics for type-safety.)

Cheers
Christopher

[toc] | [prev] | [next] | [standalone]

#169102

On 1/29/23 4:02 AM, Christopher Bazley wrote:
> On Saturday, 28 January 2023 at 16:31:49 UTC, Richard Damon wrote:
>> On 1/28/23 11:15 AM, Christopher Bazley wrote:
>>> Hi all,
>>>
>>> I've just submitted my paper n3089, “_Optional: a type qualifier to indicate pointer nullability” to the WG14 committee.
>> Since the current default of a pointer type is to allow null values,
>> wouldn't you need a modifier to say it can't be null, otherwise you
>> break all existing code with the change.
> 
> Hi Richard,
> 
> I believe that I addressed that question in the 'Migration of
> existing code' part of my proposal:
> 
>> Requiring implementations to redefine the constant to which the
>> NULL macro expands as ((_Optional void *)0) is unthinkable
>> because it would invalidate all existing code. However, it might
>> be useful to standardize an alternative macro for use in place
>> of NULL. I have not specified such a macro because NULL is
>> not a core part of the language.

The general phylosophy that I have heard about backwards compatibiliyt 
is that existing applications count, existing implementations do not.

Requiring all implementation to conform to the new standard to change 
NULL to have the optional qualifaction is TOTALLY within the history of 
the Standard. Even with some cost counting for testing, that is just 
hours per implementation.

No, the problem is much USER code has pointers that might be NULL, and 
requiring them all to IMMEDIATELY change is the problem. This would be 
worse then the coast correctness poisioning that came out of C90. At 
least with that, until you started to use const objects in your code, 
you could mostly ignore the const modifier (which is why string literals 
are arrays of char not arrays of const char, even if it is UB to modify 
them).

Unless your idea is to just allow the assignement of a null pointer to a 
pointer that is declaired to not allow nulls, but only flag a problem 
for assigning an _Optional pointer to a pointer that is assumed not to 
be NULL (at which point the restricted to not null pointers aren't 
really restricted, but may often be lying).

> 
> If your question is "Why create an _Optional qualifier instead of
> _Mandatory?" then the answer is twofold:
> 
>   1.  Pointers that can be null in function parameters are
>   outnumbered by pointers that cannot be null without
> provoking undefined behaviour. I believe that a count of
>   parameters to functions in the C standard library would
> show this, although I haven’t actually done such a count.

Which points out the high cost to implement this proposal. If the 
library functions that are defined to not allow NULL pointers are going 
to be changed to require pointers typed to be non-null, and functions 
(like malloc) that might return a null pointer typed to do that, then 
all applications are going to need a total review to work with that 
standard, as EVERY pointer is going to need to be inspected to decide if 
it can't be null.

It would seem the safest way to do that is leave the unadorned pointer 
with the current meaning (might be null) and adding a modifier to say 
that it has been checked and verified that it isn't null.

> 
> 2. Assigning a pointer to a _Mandatory-qualified type to
> a pointer to an unqualified type would provoke a warning,
> whereas a pointer to an unqualified type could be
> assigned to a pointer to a _Mandatory-qualified type
> without provoking a warning. (This is the opposite of the
> required semantics for type-safety.)

Assigning a required to not be NULL pointer to a pointer that is allowed 
to be NULL should absolutely NOT generate a warning, that is a perfectly 
safe thing to do. The warning/error would be from a pointer that might 
be NULL to the pointer that CAN'T be NULL, as the pointer might have 
been NULL.

It doesn't matter which one has the extra marking, it matters on which 
is the more permissive. "Type Safety" isn't about denoted vs undenoted 
but premissive vs restrictive. Yes, it says this modifier works the 
opposite of const and volatile, where safe is unmarked to marked, but 
that just says that if this was created 50 years ago, the better would 
have been a "Nullable" modifier. Nothing keeps the language from having 
two types of modifiers that act differently.

Note also, this is different than const and volatile anyway, as there is 
no such thing as a "Optional" object, all objects exist (unless this is 
going to try to put the "weak" declaration from GCC into the standard.



> 
> Cheers
> Christopher

[toc] | [prev] | [next] | [standalone]

#169103

On Sunday, 29 January 2023 at 18:00:59 UTC, Richard Damon wrote:
> On 1/29/23 4:02 AM, Christopher Bazley wrote: 
> >> Requiring implementations to redefine the constant to which the 
> >> NULL macro expands as ((_Optional void *)0) is unthinkable 
> >> because it would invalidate all existing code. However, it might 
> >> be useful to standardize an alternative macro for use in place 
> >> of NULL. I have not specified such a macro because NULL is 
> >> not a core part of the language.
> The general phylosophy that I have heard about backwards compatibiliyt 
> is that existing applications count, existing implementations do not.

Very wise.

> Requiring all implementation to conform to the new standard to change 
> NULL to have the optional qualifaction is TOTALLY within the history of 
> the Standard. Even with some cost counting for testing, that is just 
> hours per implementation. 
> 
> No, the problem is much USER code has pointers that might be NULL, and 
> requiring them all to IMMEDIATELY change is the problem. This would be 
> worse then the coast correctness poisioning that came out of C90. At 

That's the main reason I never proposed doing that, although I've
(surprisingly) found other people willing to advocate it. The other
reason is that C23 has decided to adopt nullptr from C++, which
throws a spanner in the works since C programmers will probably
migrate away from using the NULL macro in future. If they do so, then
redefining the NULL macro would be pointless (for new programs) as
well as destructive (for existing programs).

> Unless your idea is to just allow the assignement of a null pointer to a 
> pointer that is declaired to not allow nulls, but only flag a problem 
> for assigning an _Optional pointer to a pointer that is assumed not to 
> be NULL (at which point the restricted to not null pointers aren't 
> really restricted, but may often be lying).

There's no such thing as a "restricted to not null" pointer in C, and
maybe never will be. A pointer to a type which lacks the _Optional
qualifier merely "should" not be null. That's the price of maintaining
backward compatibility and allowing gradual migration of software
to greater null safety.

I don't think the situation is as bleak as you paint it. A lot of null pointer
values come from function calls (as return values or output parameters)
rather than initializations or assignments. The standard malloc() is a
prime example, but most software has its own functions which can return
null pointers too. Qualifying the return type of such functions is sufficient
for null-safety regardless of what their implementation comprises.

Over time, I'd expect compilers to provide a facility to warn about
assignment of null values to pointers to unqualified types,
and explicit or implicit initialization of such pointers with null,
but such warnings would need to be user-configurable.

Cheers
Christopher

[toc] | [prev] | [next] | [standalone]

#169108

On 1/29/23 3:48 PM, Christopher Bazley wrote:
> On Sunday, 29 January 2023 at 18:00:59 UTC, Richard Damon wrote:
>> On 1/29/23 4:02 AM, Christopher Bazley wrote:
>>>> Requiring implementations to redefine the constant to which the
>>>> NULL macro expands as ((_Optional void *)0) is unthinkable
>>>> because it would invalidate all existing code. However, it might
>>>> be useful to standardize an alternative macro for use in place
>>>> of NULL. I have not specified such a macro because NULL is
>>>> not a core part of the language.
>> The general phylosophy that I have heard about backwards compatibiliyt
>> is that existing applications count, existing implementations do not.
> 
> Very wise.
> 
>> Requiring all implementation to conform to the new standard to change
>> NULL to have the optional qualifaction is TOTALLY within the history of
>> the Standard. Even with some cost counting for testing, that is just
>> hours per implementation.
>>
>> No, the problem is much USER code has pointers that might be NULL, and
>> requiring them all to IMMEDIATELY change is the problem. This would be
>> worse then the coast correctness poisioning that came out of C90. At
> 
> That's the main reason I never proposed doing that, although I've
> (surprisingly) found other people willing to advocate it. The other
> reason is that C23 has decided to adopt nullptr from C++, which
> throws a spanner in the works since C programmers will probably
> migrate away from using the NULL macro in future. If they do so, then
> redefining the NULL macro would be pointless (for new programs) as
> well as destructive (for existing programs).
> 
>> Unless your idea is to just allow the assignement of a null pointer to a
>> pointer that is declaired to not allow nulls, but only flag a problem
>> for assigning an _Optional pointer to a pointer that is assumed not to
>> be NULL (at which point the restricted to not null pointers aren't
>> really restricted, but may often be lying).
> 
> There's no such thing as a "restricted to not null" pointer in C, and
> maybe never will be. A pointer to a type which lacks the _Optional
> qualifier merely "should" not be null. That's the price of maintaining
> backward compatibility and allowing gradual migration of software
> to greater null safety.

IF creating such a type isn't part of the purpose of _Optional, then why 
do it? If the lack of that modifier doesn't mean that, what does 
_Optional actually due to a type?

IF this is just about warning control, maybe C should adopt something 
line the C++ [[ ]] attributes, with an attribute to indicate that this 
pointer is exprect to be able to have a null value.

This puts it on the line with something like [[fallthrough]] which 
allows marking valid, but perhaps questionable, code to suppress warnings.

> 
> I don't think the situation is as bleak as you paint it. A lot of null pointer
> values come from function calls (as return values or output parameters)
> rather than initializations or assignments. The standard malloc() is a
> prime example, but most software has its own functions which can return
> null pointers too. Qualifying the return type of such functions is sufficient
> for null-safety regardless of what their implementation comprises.

And if malloc returns an _Optional pointer, and that generates a 
diagnostic (as the pointer it is assigned to isn't marked with the 
_Optional attribue, you have just broken a lot of programs.

IF your whole idea is that an implementation can trace from source of 
data to usage and INFER which pointers might be NULL (even if not marked 
_Optional) and which can't (even if marked _Optional) then that isn't 
really the job of the compiler, but of the Linter.

> 
> Over time, I'd expect compilers to provide a facility to warn about
> assignment of null values to pointers to unqualified types,
> and explicit or implicit initialization of such pointers with null,
> but such warnings would need to be user-configurable.

IF the lack of the _Optional doesn't generate a Diagnostic on the 
assignement, then it isn't really doing anything to the language.

What you might as well do is add a " #define _Optional " to you program 
(maybe by a compiler option, and add that functionality to your linter, 
not the compiler.

It really sounds like what you actually want is to improve linting, to 
detect the issue, adding 'cruft" to the language that might be able to 
be made to do something in a decade doesn't sound like the path to go.

Adding something like [[nullable]] on return values/definitions as an 
advisory for a linter, might be useful. It likely would need enough 
definition to allow a standardization of how "smart" a linter is 
expected to be to figure out what should get a warning.

> 
> Cheers
> Christopher

[toc] | [prev] | [next] | [standalone]

#169116

On Sunday, 29 January 2023 at 21:37:51 UTC, Richard Damon wrote:
> On 1/29/23 3:48 PM, Christopher Bazley wrote: 
> > There's no such thing as a "restricted to not null" pointer in C, and 
> > maybe never will be. A pointer to a type which lacks the _Optional 
> > qualifier merely "should" not be null. That's the price of maintaining 
> > backward compatibility and allowing gradual migration of software 
> > to greater null safety.
> IF creating such a type isn't part of the purpose of _Optional, then why 
> do it? If the lack of that modifier doesn't mean that, what does 
> _Optional actually due to a type?

* It causes a warning when a pointer to a qualified type is passed
  to a function that isn't declared as accepting a so-qualified type
  (just like 'const' or 'volatile').
* It causes a warning when a pointer to a qualified type is assigned
  to an object that isn't declared as a pointer to a so-qualified type
  (just like 'const' or 'volatile').
* It causes a warning when an object that isn't declared as a pointer
  to a qualified type is initialized with a pointer of the qualified type
  (just like 'const' or 'volatile').
* It causes a warning when a parameter declared as pointer to a
  qualified type in the definition of a function is not declared as a
   pointer to the same-qualified type in every visible declaration of
   the same function (just like 'const' or 'volatile').
* It tells static analyzers to explore all program states that would
   result from a qualified parameter value being null, regardless of
   whether any callers of that function are visible or not.
* It tells static analyzers to explore all program states that would
   result from a qualified return value being null, regardless of whether
   any definitions of the called function are visible or not.
 * It allows static analyzers to warn about undefined behaviour
   resulting from use of a qualified type, even in situations when the
   behaviour might otherwise be permitted (e.g. because there is no
   load or store in the generated code).

> IF this is just about warning control, maybe C should adopt something 
> line the C++ [[ ]] attributes, with an attribute to indicate that this 
> pointer is exprect to be able to have a null value. 

I think they already did (adopt [[ ]] attributes).

> IF your whole idea is that an implementation can trace from source of 
> data to usage and INFER which pointers might be NULL (even if not marked 
> _Optional) and which can't (even if marked _Optional) then that isn't 
> really the job of the compiler, but of the Linter.

It isn't. My idea is to support usage of a simple, fast, compiler
which only has visibility of one source file (and #included header files)
at a time, and relies on the type system to check its interactions with
other compilation units valid.

> > Over time, I'd expect compilers to provide a facility to warn about 
> > assignment of null values to pointers to unqualified types, 
> > and explicit or implicit initialization of such pointers with null, 
> > but such warnings would need to be user-configurable.
> IF the lack of the _Optional doesn't generate a Diagnostic on the 
> assignement, then it isn't really doing anything to the language. 

It would generate a diagnostic on the assignment, if the appropriate
warning were enabled.

Effectively every unique combination of -W.. and -Wno.. options (for
gcc and compatible compilers) defines a unique flavour of C.
A lot of things which are warnings in C are errors in C++ (from the
same compiler) but from my point of view, the distinction isn't really
important. My employer uses -Werror anyway.

> It really sounds like what you actually want is to improve linting, to 
> detect the issue, adding 'cruft" to the language that might be able to 
> be made to do something in a decade doesn't sound like the path to go. 

It isn't "made to do something in a decade"; it works now. That's why
I've been urging people to actually try using my prototype instead of
discussing it (and theoretical alternatives) in the abstract.

Cheers,
Christopher

[toc] | [prev] | [next] | [standalone]

#169120

On 1/29/23 5:18 PM, Christopher Bazley wrote:
> On Sunday, 29 January 2023 at 21:37:51 UTC, Richard Damon wrote:
>> On 1/29/23 3:48 PM, Christopher Bazley wrote:
>>> There's no such thing as a "restricted to not null" pointer in C, and
>>> maybe never will be. A pointer to a type which lacks the _Optional
>>> qualifier merely "should" not be null. That's the price of maintaining
>>> backward compatibility and allowing gradual migration of software
>>> to greater null safety.
>> IF creating such a type isn't part of the purpose of _Optional, then why
>> do it? If the lack of that modifier doesn't mean that, what does
>> _Optional actually due to a type?
> 
> * It causes a warning when a pointer to a qualified type is passed
>    to a function that isn't declared as accepting a so-qualified type
>    (just like 'const' or 'volatile').
> * It causes a warning when a pointer to a qualified type is assigned
>    to an object that isn't declared as a pointer to a so-qualified type
>    (just like 'const' or 'volatile').

So will generate a call to ALL calls to malloc and related functions in 
existing programs.

Note, current the C standard does NOT have a concept of warnings, only 
required diagnositcs, the generation of which means it is UB to attempt 
to run the program generated (Unless something major has changed recently)

> * It causes a warning when an object that isn't declared as a pointer
>    to a qualified type is initialized with a pointer of the qualified type
>    (just like 'const' or 'volatile').

So just fixing the pointers that we assign to malloc won't be enough.

If that value will eventually be passed to a function with the 
unqualified type, at some point we will be REQUIRED to add a cast to 
remove the qualification (or your hack that is effectively the cast)

> * It causes a warning when a parameter declared as pointer to a
>    qualified type in the definition of a function is not declared as a
>     pointer to the same-qualified type in every visible declaration of
>     the same function (just like 'const' or 'volatile').
> * It tells static analyzers to explore all program states that would
>     result from a qualified parameter value being null, regardless of
>     whether any callers of that function are visible or not.

Static analyzer is NOT required, remember that. Thus ALL uses of the 
qualified type are considered to be that qualified type, so even after 
testing for not-null, the type qualification still exists.

> * It tells static analyzers to explore all program states that would
>     result from a qualified return value being null, regardless of whether
>     any definitions of the called function are visible or not.
>   * It allows static analyzers to warn about undefined behaviour
>     resulting from use of a qualified type, even in situations when the
>     behaviour might otherwise be permitted (e.g. because there is no
>     load or store in the generated code).

But your previous rules don't need this, since the function is declared 
to return a qualified pointer, the uses of it are already warned about 
from above.

> 
>> IF this is just about warning control, maybe C should adopt something
>> line the C++ [[ ]] attributes, with an attribute to indicate that this
>> pointer is exprect to be able to have a null value.
> 
> I think they already did (adopt [[ ]] attributes).

They might have (I haven't studied the latest standard in much detail), 
at which point a [[nullable]] or [[notnull]] attribute would seem to get 
you exactly what you want. THe hooks to allow a static analyzer to 
generate your warnings, but not require the compiler to generate a 
diagnostic.
> 
>> IF your whole idea is that an implementation can trace from source of
>> data to usage and INFER which pointers might be NULL (even if not marked
>> _Optional) and which can't (even if marked _Optional) then that isn't
>> really the job of the compiler, but of the Linter.
> 
> It isn't. My idea is to support usage of a simple, fast, compiler
> which only has visibility of one source file (and #included header files)
> at a time, and relies on the type system to check its interactions with
> other compilation units valid.

so this will generate a diagnostic, and make running the program undefined?

void fun1(int *ptr);

void fun2(int _Optional* ptr) {
    if(ptr)  fun1(ptr);
}

The type of the pointer give to fun1 is qualified, so if that is 
required to generate a diagnostic, running the resulting program (if 
possible) is Undefined Behavior.

If no diagnostic is requires, what does the _Optional due. Either 
dropping the attribut IS or it ISN'T an error.

If it does anything, it breaks most programs.
> 
>>> Over time, I'd expect compilers to provide a facility to warn about
>>> assignment of null values to pointers to unqualified types,
>>> and explicit or implicit initialization of such pointers with null,
>>> but such warnings would need to be user-configurable.
>> IF the lack of the _Optional doesn't generate a Diagnostic on the
>> assignement, then it isn't really doing anything to the language.
> 
> It would generate a diagnostic on the assignment, if the appropriate
> warning were enabled.

WHAT OPTION? The standard doesn't talk about options like that.

Either the standard mandates a diagnostic, or it doesn't, there is no 
optional by invocation.

The closes that I know of the standard talking about something like that 
is the conditionality of <assert.h> on the NDEBUG macro that is normally 
defined as a compiler option, or the compiler, as an extension, allowing 
the insertion of pragmas to the beginning of all translation units.

> 
> Effectively every unique combination of -W.. and -Wno.. options (for
> gcc and compatible compilers) defines a unique flavour of C.
> A lot of things which are warnings in C are errors in C++ (from the
> same compiler) but from my point of view, the distinction isn't really
> important. My employer uses -Werror anyway.

Rmember, C, by the standard, has no "warnings" only "Diagnostics". ANY 
required diagnostic makes the use of the program (if generated) undefined.

> 
>> It really sounds like what you actually want is to improve linting, to
>> detect the issue, adding 'cruft" to the language that might be able to
>> be made to do something in a decade doesn't sound like the path to go.
> 
> It isn't "made to do something in a decade"; it works now. That's why
> I've been urging people to actually try using my prototype instead of
> discussing it (and theoretical alternatives) in the abstract.

It either immediately breaks most programs, or it officially does nothing.

At best it is a standardized hook for an implementation defined 
extension if it does anything meaning full.

Remember, (unless they have changed somthing) C doesn't define a 
"warning" only "Required Diagnostics", any of which make the use of the 
progtram ill defined.

Some implementation take a "Required Diagnostic" and "down grade" it to 
a warning by defining the request, but that is an EXTENSION to the standard.

> 
> Cheers,
> Christopher

[toc] | [prev] | [next] | [standalone]

#169124

Christopher Bazley <cs99cjb@gmail.com> writes:

> On Sunday, 29 January 2023 at 21:37:51 UTC, Richard Damon wrote:
>> On 1/29/23 3:48 PM, Christopher Bazley wrote: 
>> > There's no such thing as a "restricted to not null" pointer in C, and 
>> > maybe never will be. A pointer to a type which lacks the _Optional 
>> > qualifier merely "should" not be null. That's the price of maintaining 
>> > backward compatibility and allowing gradual migration of software 
>> > to greater null safety.
>> IF creating such a type isn't part of the purpose of _Optional, then why 
>> do it? If the lack of that modifier doesn't mean that, what does 
>> _Optional actually due to a type?
>
> * It causes a warning when a pointer to a qualified type is passed
>   to a function that isn't declared as accepting a so-qualified type
>   (just like 'const' or 'volatile').
> * It causes a warning when a pointer to a qualified type is assigned
>   to an object that isn't declared as a pointer to a so-qualified type
>   (just like 'const' or 'volatile').

The talk of warnings is going to generate a lot of replies and, from the
point of view of backwards compatibility, they don't really matter as
one can usually turn them off.  From that point of view, what matters is
that this new type qualifier behaves like all the rest so the cases you
describe are /constraint violations/ and result in the program's
behaviour being undefined.

Unfortunately you don't say if the standard library is to use this new
qualifier or, to be more accurate, it does not say it will but some
people will assume you would want it to.  That would mean that every
line of code that does something like this:

  char *cp = malloc(42);

causes the program to violate a constraint and have undefined behaviour.
That would be a major change!

I think you are proposing a qualifier that programmers can slowly
introduce to their code base to get better static analysis, so you
should probably make it plain that malloc (etc.) will /not/ be declared

  _Optional void *malloc(size_t);

anytime soon -- even if the proposal were to be accepted.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#169142

Hi Ben,

On Monday, 30 January 2023 at 00:00:56 UTC, Ben Bacarisse wrote:
> Unfortunately you don't say if the standard library is to use this new 
> qualifier or, to be more accurate, it does not say it will but some 
> people will assume you would want it to. That would mean that every

I did imply that it would be possible to change the
definition of standard library functions like free() immediately,
so that they would accept pointer-to-_Optional. I'd be delighted
with that outcome, but it isn't required to make the new feature
useful, so it isn't explicitly proposed.

> line of code that does something like this: 
> 
> char *cp = malloc(42); 
> 
> causes the program to violate a constraint and have undefined behaviour. 
> That would be a major change! 

Indeed, such a change to standard functions which *output*
pointers is impossible. I'm sure the committee understand that.

> I think you are proposing a qualifier that programmers can slowly 
> introduce to their code base to get better static analysis, so you 

Exactly.

> should probably make it plain that malloc (etc.) will /not/ be declared 
> 
> _Optional void *malloc(size_t); 
> 
> anytime soon -- even if the proposal were to be accepted. 

I thought it would be clear enough from the content of the
'Migration of existing code' subsection that such changes
to standard functions are not feasible and never will be, but
you are probably right that some people will misinterpret it.

Cheers,
Christopher

[toc] | [prev] | [next] | [standalone]

#169145

On 2023-01-30, Christopher Bazley <cs99cjb@gmail.com> wrote:
> I did imply that it would be possible to change the
> definition of standard library functions like free() immediately,
> so that they would accept pointer-to-_Optional. I'd be delighted
> with that outcome, but it isn't required to make the new feature
> useful, so it isn't explicitly proposed.

Umm, no. Code like this would break:

  struct widget {
    // ...
    void (*destructor_fn)(void *);
  }

Where destructor_fn is set to free by default, or else to a
custom function.

You'd have to introduce _Optional in such a way that it doesn't
make a difference to the type of free, e.g.

  void free(void *_Optional ptr);

where it is understood not to make a difference to the type of
the parameter, similarlly to 

  void free(void * const);

If the declaration looks like this:

  void free(void _Optional *ptr);

and yet is compatible with

  void (*destructor_fn)(void *);

then I would say that is a uselessly castrated implementation of _Optional.

It must change the type, must like a const or volatile qualfier,
and so those function types must be incompatible.

This must be a constraint violation:

  __Optional void *opt_qualified = 0;

  void *unqualified = opt_qualified; // stripping _Optional without cast

You basically need an alternative entry point into free under a
different name.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#169148

On Monday, 30 January 2023 at 23:28:50 UTC, Kaz Kylheku wrote:
> On 2023-01-30, Christopher Bazley <cs9...@gmail.com> wrote: 
> > I did imply that it would be possible to change the 
> > definition of standard library functions like free() immediately, 
> > so that they would accept pointer-to-_Optional. I'd be delighted 
> > with that outcome, but it isn't required to make the new feature 
> > useful, so it isn't explicitly proposed.
> Umm, no. Code like this would break: 
> 
> struct widget { 
> // ... 
> void (*destructor_fn)(void *); 
> } 
> 
> Where destructor_fn is set to free by default, or else to a 
> custom function. 

Good point. I should have thought of that, because I've solved
problems like that in the past when replacing functions
with macros which capture the calling location in the source
code.

I've seen it claimed that *any* standard library function may
be defined as a macro, which would also invalidate your example,
but I don't think that is a strong argument for breaking existing
code.

It makes me doubly glad that I didn't specify any changes
to the standard library.

Cheers,
Christopher

[toc] | [prev] | [next] | [standalone]

#169152

On 1/31/23 02:39, Christopher Bazley wrote:
> On Monday, 30 January 2023 at 23:28:50 UTC, Kaz Kylheku wrote:
>> On 2023-01-30, Christopher Bazley <cs9...@gmail.com> wrote: 
>>> I did imply that it would be possible to change the 
>>> definition of standard library functions like free() immediately, 
>>> so that they would accept pointer-to-_Optional. I'd be delighted 
>>> with that outcome, but it isn't required to make the new feature 
>>> useful, so it isn't explicitly proposed.
>> Umm, no. Code like this would break: 
>>
>> struct widget { 
>> // ... 
>> void (*destructor_fn)(void *); 
>> } 
>>
>> Where destructor_fn is set to free by default, or else to a 
>> custom function. 
> 
> Good point. I should have thought of that, because I've solved
> problems like that in the past when replacing functions
> with macros which capture the calling location in the source
> code.
> 
> I've seen it claimed that *any* standard library function may
> be defined as a macro, ...

That claim is correct. From 7.1.4, which describes the "Use of [C
standard] library functions", the first paragraph says:

> Each of the following statements applies unless explicitly stated otherwise in the detailed descrip-
> tions that follow:
...
> — Any function declared in a header may be additionally implemented as a function-like macro
> defined in the header, so if a library function is declared explicitly when its header is included,
> one of the techniques shown below can be used to ensure the declaration is not affected by
> such a macro. Any macro definition of a function can be suppressed locally by enclosing
> the name of the function in parentheses, because the name is then not followed by the left
> parenthesis that indicates expansion of a macro function name. For the same syntactic reason,
> it is permitted to take the address of a library function even if it is also defined as a macro. 201)
> The use of #undef to remove any macro definition will also ensure that an actual function is
> referred to.
> — Any invocation of a library function that is implemented as a macro shall expand to code that
> evaluates each of its arguments exactly once, fully protected by parentheses where necessary,
> so it is generally safe to use arbitrary expressions as arguments. 202)
> — Likewise, those function-like macros described in the following subclauses may be invoked in
> an expression anywhere a function with a compatible return type could be called. 203)


The part about "unless explicitly stated otherwise" mainly refers to
cases where features of the C standard library are explicitly required
to be implemented using function-like macros, in which case there is no
actual function with the same name as the macro.

> ... which would also invalidate your example,

I'm not sure I follow that. If free(), for instance, is implemented as a
function like macro, the line

	my_widget.destructor_fn = free;

will NOT invoke the macro definition, because invocations of a
function-like macro must be immediately followed by a '('. Since the
macro definition is in addition to the definition as an actual function,
not a replacement for it, in any context where the macro is not invoked,
the identifier will be resolved as referring to the actual function.

[toc] | [prev] | [next] | [standalone]

#169154

On Tuesday, 31 January 2023 at 17:19:13 UTC, james...@alumni.caltech.edu wrote:
> On 1/31/23 02:39, Christopher Bazley wrote: 
> > I've seen it claimed that *any* standard library function may
> > be defined as a macro, ... 
> 
> That claim is correct. From 7.1.4, which describes the "Use of [C 
> standard] library functions", the first paragraph says: 
...
Thank you, this was useful information.

> > ... which would also invalidate your example, 
> 
> I'm not sure I follow that. If free(), for instance, is implemented as a 
> function like macro, the line 
> 
> my_widget.destructor_fn = free; 
> 
> will NOT invoke the macro definition, because invocations of a 
> function-like macro must be immediately followed by a '('. Since the 
> macro definition is in addition to the definition as an actual function, 
> not a replacement for it, in any context where the macro is not invoked, 
> the identifier will be resolved as referring to the actual function.

I stand corrected. I didn't know the rule that the macro definition
must be shadowed by a function of the same name.

I originally encountered the caveat about standard library
functions potentially being defined as function-like macros
in the context of a discussion about the requirement to use
brackets around compound literals to avoid them being
misinterpreted as separate arguments to a function-like macro.

Cheers
Christopher

[toc] | [prev] | [next] | [standalone]

#169159

On 2023-01-31, Christopher Bazley <cs99cjb@gmail.com> wrote:
> On Monday, 30 January 2023 at 23:28:50 UTC, Kaz Kylheku wrote:
>> On 2023-01-30, Christopher Bazley <cs9...@gmail.com> wrote: 
>> > I did imply that it would be possible to change the 
>> > definition of standard library functions like free() immediately, 
>> > so that they would accept pointer-to-_Optional. I'd be delighted 
>> > with that outcome, but it isn't required to make the new feature 
>> > useful, so it isn't explicitly proposed.
>> Umm, no. Code like this would break: 
>> 
>> struct widget { 
>> // ... 
>> void (*destructor_fn)(void *); 
>> } 
>> 
>> Where destructor_fn is set to free by default, or else to a 
>> custom function. 
>
> Good point. I should have thought of that, because I've solved
> problems like that in the past when replacing functions
> with macros which capture the calling location in the source
> code.
>
> I've seen it claimed that *any* standard library function may
> be defined as a macro, which would also invalidate your example,

That simply isn't true. This the following has to work, regardless of
the existence of a free macro, whether object-like or function-like:

   #include <stddef.h>

   //

   void (*pfree)(void *) = free; // or &free

The macro cannot be defined such that this doesn't work. Furthermore,
any macro definition of a standard library function may be suppressed
by #undef.

There has to be a declaration there, and a real function available for
linkage under the unsubstituted symbol.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#169146

On 1/30/23 5:57 PM, Christopher Bazley wrote:
> Hi Ben,
> 
> On Monday, 30 January 2023 at 00:00:56 UTC, Ben Bacarisse wrote:
>> Unfortunately you don't say if the standard library is to use this new
>> qualifier or, to be more accurate, it does not say it will but some
>> people will assume you would want it to. That would mean that every
> 
> I did imply that it would be possible to change the
> definition of standard library functions like free() immediately,
> so that they would accept pointer-to-_Optional. I'd be delighted
> with that outcome, but it isn't required to make the new feature
> useful, so it isn't explicitly proposed.
> 
>> line of code that does something like this:
>>
>> char *cp = malloc(42);
>>
>> causes the program to violate a constraint and have undefined behaviour.
>> That would be a major change!
> 
> Indeed, such a change to standard functions which *output*
> pointers is impossible. I'm sure the committee understand that.
> 
>> I think you are proposing a qualifier that programmers can slowly
>> introduce to their code base to get better static analysis, so you
> 
> Exactly.
> 
>> should probably make it plain that malloc (etc.) will /not/ be declared
>>
>> _Optional void *malloc(size_t);
>>
>> anytime soon -- even if the proposal were to be accepted.
> 
> I thought it would be clear enough from the content of the
> 'Migration of existing code' subsection that such changes
> to standard functions are not feasible and never will be, but
> you are probably right that some people will misinterpret it.
> 
> Cheers,
> Christopher

The problem is that the migration path basically says we can never 
migrate to the point where the lack of _Optional ever actually means 
something.

This is different than the old const issue. With const, while string 
constants couldn't be made to have const type due to code breakage, a 
compiler/linter could ALWAYS detect the condition and warn about it, so 
once you adopt a non-acceptance of that warning appearing, you could 
make non-const actually mean that you can generally assume it is writable.

With _Optional, since you are effectively admitting that major APIs 
can't mark return pointers as _Optional as it breaks old code, there is 
nothiing you can do to actually transition to deciding that YOUR code 
will be _Optional clean, since the implementation when looking at your 
code has no way to know which returned pointers should have been marked 
optional.

Remember, if the type incompatibility is a required diagnostic, the 
program is illdefined, and if not, it really isn't a part of the pointer 
type.

Compare that to the attribute, which by definition doesn't affect 
program correctness, but allows implementation to generate non-fatal 
warnings if desired, which seems to match the goal.

[toc] | [prev] | [next] | [standalone]

#169149

On Tuesday, 31 January 2023 at 02:06:06 UTC, Richard Damon wrote:
> On 1/30/23 5:57 PM, Christopher Bazley wrote: 
> > I thought it would be clear enough from the content of the 
> > 'Migration of existing code' subsection that such changes 
> > to standard functions are not feasible and never will be, but 
> > you are probably right that some people will misinterpret it. 
> The problem is that the migration path basically says we can never 
> migrate to the point where the lack of _Optional ever actually means 
> something. 

Based on my own experience of migrating code, I don't agree
that the lack of _Optional means nothing. It means either:
1. This pointer declaration has not been migrated yet, or
2. This pointer cannot be null.

I'm sorry you find that an unsatisfying answer.
I don't believe that the 'const' qualifier is used on every
declaration in the world that should use it.
 
The lack of 'const' means either:
1. This pointer declaration has not been migrated yet, or
2. This is a pointer to a writable object.

> This is different than the old const issue. With const, while string 
> constants couldn't be made to have const type due to code breakage, a 
> compiler/linter could ALWAYS detect the condition and warn about it, so 
> once you adopt a non-acceptance of that warning appearing, you could 
> make non-const actually mean that you can generally assume it is writable. 

I assume that "the condition" you refer to is assignment to a
'const'-qualified value, which generates an error in Clang. I would
argue that the warnings generated for incompatible assignments
and function argument types are equally important, if not more so,
given that functions typically have more callers than definitions.

I understand that there is a distinction between those two
scenarios for language lawyers, but the average user doesn't care.
All they care about is that the compiler is telling them they made
a mistake.

> With _Optional, since you are effectively admitting that major APIs 
> can't mark return pointers as _Optional as it breaks old code, there is 
> nothiing you can do to actually transition to deciding that YOUR code 
> will be _Optional clean, since the implementation when looking at your 
> code has no way to know which returned pointers should have been marked 
> optional. 

There is something very simple you can do to transition: assign
the return value of a function such as malloc() to an pointer-to_Optional type.
Based on my experience, that works perfectly well. Nobody complains that
the return type of malloc() isn't a pointer-to-int or whatever they want it to be.

> Remember, if the type incompatibility is a required diagnostic, the 
> program is illdefined, and if not, it really isn't a part of the pointer 
> type. 

Assignment of 'void *' to '_Optional char *' isn't a type incompatibility,
any more than assignment of 'void *' to 'const char *' is a type incompatibility.
An implementation has no business reasoning about what it thinks the
return type of a function "should have been".

> Compare that to the attribute, which by definition doesn't affect 
> program correctness, but allows implementation to generate non-fatal 
> warnings if desired, which seems to match the goal.

Compilers are free to ignore attributes and they seem to have ill-defined
semantics, which certainly wasn't my goal. I concede I'm not an expert
in this area though.

Cheers
Christopher

[toc] | [prev] | [next] | [standalone]

#169134

On 1/29/23 17:18, Christopher Bazley wrote:
> On Sunday, 29 January 2023 at 21:37:51 UTC, Richard Damon wrote:
>> On 1/29/23 3:48 PM, Christopher Bazley wrote:
>>> There's no such thing as a "restricted to not null" pointer in C,
>>> and maybe never will be. A pointer to a type which lacks the
>>> _Optional qualifier merely "should" not be null. That's the price of
>>> maintaining backward compatibility and allowing gradual migration of
>>> software to greater null safety.
>> IF creating such a type isn't part of the purpose of _Optional, then
>> why do it? If the lack of that modifier doesn't mean that, what does
>> _Optional actually due to a type?
>
> * It causes a warning when a pointer to a qualified type is passed
> to a function that isn't declared as accepting a so-qualified type
> (just like 'const' or 'volatile').
> * It causes a warning when a pointer to a qualified type is assigned
> to an object that isn't declared as a pointer to a so-qualified type
> (just like 'const' or 'volatile').
> * It causes a warning when an object that isn't declared as a pointer
> to a qualified type is initialized with a pointer of the qualified type
> (just like 'const' or 'volatile').
> * It causes a warning when a parameter declared as pointer to a
> qualified type in the definition of a function is not declared as a
> pointer to the same-qualified type in every visible declaration of
> the same function (just like 'const' or 'volatile').

The committee has very carefully avoided specifying warnings. It only
specifies when diagnostics are mandatory (they are NEVER prohibited).

An implementation can issue a non-mandatory diagnostic for any reason it
wants (for instance, because the code fails to use taboo words as
identifiers), so long as it also produces the corresponding required
behavior.

The #error directive specifies a diagnostic message which must be
generated if it survives conditional compilation. If that happens, a
conforming implementation of C is prohibited from completing translation
of the program.
In all other cases where a diagnostic is mandatory, the behavior of the
code is undefined. This is not required or specified by the standard,
it's simply something the committee decided to make true. This means
that, after issuing the required diagnostic, an implementation can
accept such code, giving the translated program any behavior it wishes,
but it is not required to do so.

If you want this to be a non-mandatory diagnostic, the standard need not
even mention it. If you want this to be a mandatory diagnostic, it must
not be triggered by code that is meant to be portable, because it might
need to be ported to a system that will reject that code.

[toc] | [prev] | [next] | [standalone]

#169113

On 2023-01-29, Christopher Bazley <cs99cjb@gmail.com> wrote:
>
> There's no such thing as a "restricted to not null" pointer in C, and
> maybe never will be. A pointer to a type which lacks the _Optional
> qualifier merely "should" not be null. That's the price of maintaining
> backward compatibility and allowing gradual migration of software
> to greater null safety.

That's my impression, essentially this comes down to a design by
contract issue.  Unless you have some form of runtime checking,
which I would argue is against the spirit of C, how is this to be
enforced?  In C types are fungible and you can't really hide that
fact, there is always an escape route out of the typing system.
There are languages where this does make sense, e.g. I believe VB
allows for nullable types and modern PHP is the same, but that is
in the context of a much bigger runtime system and far more
handholding to the extent pointers as we know them don't exist,
it's a different animal to C.

The traditional C approach is a simple assert(p != NULL) and hope
it comes up in testing if it is an issue at all.  An approach that
works for any constraint, not only this, and imposes no penalty on
production code.

-- 
Andrew Smallshaw
andrews@sdf.org

[toc] | [prev] | [next] | [standalone]

#169119

On Sunday, 29 January 2023 at 21:52:13 UTC, Andrew Smallshaw wrote:
> On 2023-01-29, Christopher Bazley <cs9...@gmail.com> wrote: 
> > 
> > There's no such thing as a "restricted to not null" pointer in C, and 
> > maybe never will be. A pointer to a type which lacks the _Optional 
> > qualifier merely "should" not be null. That's the price of maintaining 
> > backward compatibility and allowing gradual migration of software 
> > to greater null safety.
> That's my impression, essentially this comes down to a design by 
> contract issue. Unless you have some form of runtime checking, 
> which I would argue is against the spirit of C, how is this to be 
> enforced? In C types are fungible and you can't really hide that 
> fact, there is always an escape route out of the typing system. 

C programs already incorporate runtime checking to avoid null
pointer dereferences. My proposal does not change that: exactly the
same runtime checking code can be used to avoid dereferencing
pointers to _Optional-qualified types, instead of mandating use of a
library function (which really would be against the spirit of C as a
standalone language suitable for the tiniest embedded systems) to
check for null values and (somehow?!) either return an unqualified
pointer or indicate that its return value isn't valid.

Cheers,
Christopher

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web