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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-05 08:30 -0700
          Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Po Lu <luangruo@yahoo.com> - 2023-04-06 12:06 +0800
            Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-05 21:35 -0700
              Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Po Lu <luangruo@yahoo.com> - 2023-04-13 20:24 +0800
              Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Po Lu <luangruo@yahoo.com> - 2023-04-13 20:25 +0800
    Re: [RFC] _Optional: a type qualifier to indicate pointer nullability Siri Cruise <chine.bleu@yahoo.com> - 2023-01-31 18:07 -0800

Page 4 of 4 — ← Prev page 1 2 3 [4]

#169156

On 1/31/23 12:25, Christopher Bazley wrote:
> On Tuesday, 31 January 2023 at 15:54:44 UTC, Tim Rentsch wrote:
>> rejected. Breaking existing code is an absolute deal breaker. But the
>> other alternative is useless, because there are no consequences; any
>> warnings produced can be safely ignored, and that's what people will
>> do, and compilers will have an option to suppress the warnings. 
>
> Nobody ignores warnings at my place of employment because the
> compiler (either gcc or clang) is invoked with -Werror. I don't think that
> is particularly unusual either. I've never seen anyone (until you)
> advocating
> ignoring warnings, so if that's the basis of your argument then I'm not
> inclined to give the rest of it much credence. Presumably you also
> dismiss the value of any static analysis tools, since their use is not
> mandated by the C standard. I can't imagine how awful the code that
> would result from such an attitude might be.

Implementations of C are allowed to complain about anything they wish,
and many of them will complain about things that are not actually
problems. Keep in mind that warnings are for cases where there's
ambiguity about whether or not something needs to be fixed. If it's
unambiguous about whether it should be fixed, it should be an error
message that prevents compilation. I see that as sufficient
justification to not compile with -Werror. I don't ignore warning
messages, but I always review them for validity, something that -Werror
prevents.


I've even seen different compilers complain about things in a mutually
incompatible way, such that a piece of perfectly valid C code could be
written in a way that turns off one compiler's error message, or in a
way that turns off the other compiler's message, but not both. I can't
remember the details of that case, so feel free to not believe me, but I
have seen it.

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

#169157

On Tuesday, 31 January 2023 at 23:00:35 UTC, james...@alumni.caltech.edu wrote:
> On 1/31/23 12:25, Christopher Bazley wrote: 
> > On Tuesday, 31 January 2023 at 15:54:44 UTC, Tim Rentsch wrote: 
> >> rejected. Breaking existing code is an absolute deal breaker. But the 
> >> other alternative is useless, because there are no consequences; any 
> >> warnings produced can be safely ignored, and that's what people will 
> >> do, and compilers will have an option to suppress the warnings. 
> > 
> > Nobody ignores warnings at my place of employment because the 
> > compiler (either gcc or clang) is invoked with -Werror. I don't think that 
> > is particularly unusual either. I've never seen anyone (until you) 
> > advocating 
> > ignoring warnings, so if that's the basis of your argument then I'm not 
> > inclined to give the rest of it much credence. Presumably you also 
> > dismiss the value of any static analysis tools, since their use is not 
> > mandated by the C standard. I can't imagine how awful the code that 
> > would result from such an attitude might be.
> Implementations of C are allowed to complain about anything they wish, 
> and many of them will complain about things that are not actually 
> problems. Keep in mind that warnings are for cases where there's 
> ambiguity about whether or not something needs to be fixed. If it's 
> unambiguous about whether it should be fixed, it should be an error 
> message that prevents compilation. I see that as sufficient 
> justification to not compile with -Werror. I don't ignore warning 
> messages, but I always review them for validity, something that -Werror 
> prevents. 
> 
> 
> I've even seen different compilers complain about things in a mutually 
> incompatible way, such that a piece of perfectly valid C code could be 
> written in a way that turns off one compiler's error message, or in a 
> way that turns off the other compiler's message, but not both. I can't 
> remember the details of that case, so feel free to not believe me, but I 
> have seen it.
>
The classic case is when you have a function pointer, e.g. to pass to a minimiser.
It might have the signature double (*f)(const double *x, int N, void *context);

The context pointer is virtually essential if you have a complex function and
wish to avoid globals. But if the function is simple, it might not be useful.

Now if you don't use the argument "context", some compilers will warn about
an unused argument. You can usually shut these compilers up with a hack like
void *dummy = context; However other compilers will then complain "assignment
to dummy has no effect".
There's a semi standard ARGSUSED macro to avoid this problem. But of course 
then you're effectively adding features to the language.
  

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

#169158

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> The classic case is when you have a function pointer, e.g. to pass to
> a minimiser.  It might have the signature double (*f)(const double *x,
> int N, void *context);
>
> The context pointer is virtually essential if you have a complex function and
> wish to avoid globals. But if the function is simple, it might not be useful.
>
> Now if you don't use the argument "context", some compilers will warn about
> an unused argument. You can usually shut these compilers up with a hack like
> void *dummy = context; However other compilers will then complain "assignment
> to dummy has no effect".

> There's a semi standard ARGSUSED macro to avoid this problem. But of
> course then you're effectively adding features to the language.

C2x (C23?) will add an attribute [[maybe_unused]].

-- 
Ben.

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

#169161

On 01/02/2023 01:04, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> 
>> The classic case is when you have a function pointer, e.g. to pass to
>> a minimiser.  It might have the signature double (*f)(const double *x,
>> int N, void *context);
>>

I can't imagine why this particular niche situation could be called "the 
classic case", but certainly unused arguments is a fair example of 
something compilers may warn about, though the code may be perfectly good.

>> The context pointer is virtually essential if you have a complex function and
>> wish to avoid globals. But if the function is simple, it might not be useful.
>>
>> Now if you don't use the argument "context", some compilers will warn about
>> an unused argument. You can usually shut these compilers up with a hack like
>> void *dummy = context; However other compilers will then complain "assignment
>> to dummy has no effect".
> 
>> There's a semi standard ARGSUSED macro to avoid this problem. But of
>> course then you're effectively adding features to the language.
> 
> C2x (C23?) will add an attribute [[maybe_unused]].
> 

Yes.  Until then (and perhaps after that), the standard method is a cast 
to void "(void) context;" - perhaps with a comment.

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

#169163

On Wednesday, 1 February 2023 at 08:29:19 UTC, David Brown wrote:
> On 01/02/2023 01:04, Ben Bacarisse wrote: 
> > Malcolm McLean <malcolm.ar...@gmail.com> writes: 
> > 
> >> The classic case is when you have a function pointer, e.g. to pass to 
> >> a minimiser. It might have the signature double (*f)(const double *x, 
> >> int N, void *context); 
> >>
> I can't imagine why this particular niche situation could be called "the 
> classic case", but certainly unused arguments is a fair example of 
> something compilers may warn about, though the code may be perfectly good.
>
It's not niche. You might see it as niche if you write code which seldom uses
function pointers. But a lot of problem domains tend to make very heavy
use of function pointers. All functions passed in the pointer need the same
signature, which means that you really need to provide a "context" pointer
to pass back, to allow the function to access arbitrary local data. However
you won't always use it, either all the data you need is in the explicit parameters,
or it's easier to use globals..

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

#169833

Christopher Bazley <cs99cjb@gmail.com> writes:

> On Tuesday, 31 January 2023 at 15:54:44 UTC, Tim Rentsch wrote:
>
>> rejected.  Breaking existing code is an absolute deal breaker.  But
>> the other alternative is useless, because there are no consequences;
>> any warnings produced can be safely ignored, and that's what people
>> will do, and compilers will have an option to suppress the warnings.
>
> Nobody ignores warnings at my place of employment because the
> compiler (either gcc or clang) is invoked with -Werror.  I don't
> think that is particularly unusual either.  I've never seen anyone
> (until you) advocating ignoring warnings,

I'm not advocating anything.  I am simply stating what people will
do, based on my own empirical experience.

> so if that's the basis of your argument then I'm not inclined to
> give the rest of it much credence.

There is a point that you may want to consider, namely, since you
are the one who is proposing a language change, it is up to you to
convince other people of the value of said change, not the other way
around.

> Presumably you also dismiss the value of any static analysis
> tools, since their use is not mandated by the C standard. [...]

Your logic here is faulty, and the conclusion given is wrong.  I
suggest that it is worth your while to put more effort into
discovering what other people actually think, before moving ahead to
any conclusions.

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

#169847

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Christopher Bazley <cs99cjb@gmail.com> writes:
>
>> On Tuesday, 31 January 2023 at 15:54:44 UTC, Tim Rentsch wrote:
>>
>>> rejected.  Breaking existing code is an absolute deal breaker.  But
>>> the other alternative is useless, because there are no
>>> consequences;
>>> any warnings produced can be safely ignored, and that's what people
>>> will do, and compilers will have an option to suppress the
>>> warnings.
>>
>> Nobody ignores warnings at my place of employment because the
>> compiler (either gcc or clang) is invoked with -Werror.  I don't
>> think that is particularly unusual either.  I've never seen anyone
>> (until you) advocating ignoring warnings,

And -Werror is part of the Standard?

GCC and Clang are not all the world, and the semantics they associate
with their diagnostic messages have no place being specified in a
implementation-neutral standard.

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

#169849

Po Lu <luangruo@yahoo.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Christopher Bazley <cs99cjb@gmail.com> writes:
>>
>>> On Tuesday, 31 January 2023 at 15:54:44 UTC, Tim Rentsch wrote:
>>>
>>>> rejected.  Breaking existing code is an absolute deal breaker.  But
>>>> the other alternative is useless, because there are no
>>>> consequences;
>>>> any warnings produced can be safely ignored, and that's what people
>>>> will do, and compilers will have an option to suppress the
>>>> warnings.
>>>
>>> Nobody ignores warnings at my place of employment because the
>>> compiler (either gcc or clang) is invoked with -Werror.  I don't
>>> think that is particularly unusual either.  I've never seen anyone
>>> (until you) advocating ignoring warnings,
>
> And -Werror is part of the Standard?
>
> GCC and Clang are not all the world, and the semantics they
> associate with their diagnostic messages have no place being
> specified in a implementation-neutral standard.

I don't know why you're responding to my posting.  The
comment about -Werror is not something I said;  it is
something Christopher Bazley said, as the quoted material
indicates.

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

#170004

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Christopher Bazley <cs99cjb@gmail.com> writes:
>>>
>>>> On Tuesday, 31 January 2023 at 15:54:44 UTC, Tim Rentsch wrote:
>>>>
>>>>> rejected.  Breaking existing code is an absolute deal breaker.
>>>>> But
>>>>> the other alternative is useless, because there are no
>>>>> consequences;
>>>>> any warnings produced can be safely ignored, and that's what
>>>>> people
>>>>> will do, and compilers will have an option to suppress the
>>>>> warnings.
>>>>
>>>> Nobody ignores warnings at my place of employment because the
>>>> compiler (either gcc or clang) is invoked with -Werror.  I don't
>>>> think that is particularly unusual either.  I've never seen anyone
>>>> (until you) advocating ignoring warnings,
>>
>> And -Werror is part of the Standard?
>>
>> GCC and Clang are not all the world, and the semantics they
>> associate with their diagnostic messages have no place being
>> specified in a implementation-neutral standard.
>
> I don't know why you're responding to my posting.  The
> comment about -Werror is not something I said;  it is
> something Christopher Bazley said, as the quoted material
> indicates.

Sorry, I wasn't reading very carefully.  :-(

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

#170005

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Christopher Bazley <cs99cjb@gmail.com> writes:
>>>
>>>> On Tuesday, 31 January 2023 at 15:54:44 UTC, Tim Rentsch wrote:
>>>>
>>>>> rejected.  Breaking existing code is an absolute deal breaker.
>>>>> But
>>>>> the other alternative is useless, because there are no
>>>>> consequences;
>>>>> any warnings produced can be safely ignored, and that's what
>>>>> people
>>>>> will do, and compilers will have an option to suppress the
>>>>> warnings.
>>>>
>>>> Nobody ignores warnings at my place of employment because the
>>>> compiler (either gcc or clang) is invoked with -Werror.  I don't
>>>> think that is particularly unusual either.  I've never seen anyone
>>>> (until you) advocating ignoring warnings,
>>
>> And -Werror is part of the Standard?
>>
>> GCC and Clang are not all the world, and the semantics they
>> associate with their diagnostic messages have no place being
>> specified in a implementation-neutral standard.
>
> I don't know why you're responding to my posting.  The
> comment about -Werror is not something I said;  it is
> something Christopher Bazley said, as the quoted material
> indicates.

Sorry, I wasn't reading very carefully.  :-(

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

#169160

In article 
<fb1cd912-ae01-41eb-b21a-2d2af7aa1405n@googlegroups.com>,
 Christopher Bazley <cs99cjb@gmail.com> wrote:

> 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.

Unless you are proposing changes in how programs are 
interpretted, you can do on your own with

#define _Optional

You can do that with other things like _Noreturn or _Fallthrough. 
Anyone can add the #defines to existing code, and if the 
qualifiers prove popular, they will be encouraged.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
Discordia: not just a religion but also a parody. This post         / \
I am an Andrea Chen sockpuppet.                  insults Islam.  Mohammed

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

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

csiph-web