Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #169082 > unrolled thread
| Started by | Christopher Bazley <cs99cjb@gmail.com> |
|---|---|
| First post | 2023-01-28 08:15 -0800 |
| Last post | 2023-01-31 18:07 -0800 |
| Articles | 6 on this page of 66 — 15 participants |
Back to article view | Back to comp.lang.c
[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 4 of 4 — ← Prev page 1 2 3 [4]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-01-31 18:00 -0500 |
| Message-ID | <trc6i5$lpp$1@dont-email.me> |
| In reply to | #169153 |
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]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-01-31 15:52 -0800 |
| Message-ID | <1fb292d6-bc04-440a-be53-9ca2b42bccadn@googlegroups.com> |
| In reply to | #169156 |
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]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-02-01 00:04 +0000 |
| Message-ID | <87357qntdz.fsf@bsb.me.uk> |
| In reply to | #169157 |
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-02-01 09:29 +0100 |
| Message-ID | <trd7sh$8o9v$1@dont-email.me> |
| In reply to | #169158 |
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]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-02-01 02:31 -0800 |
| Message-ID | <9a959422-f5db-416a-a228-cf2bfada6d0dn@googlegroups.com> |
| In reply to | #169161 |
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]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2023-01-31 18:07 -0800 |
| Message-ID | <chine.bleu-EC5ED4.18072431012023@news.eternal-september.org> |
| In reply to | #169082 |
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