Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #120068 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2017-09-19 14:23 -0700 |
| Last post | 2017-09-20 15:30 -0700 |
| Articles | 20 on this page of 183 — 28 participants |
Back to article view | Back to comp.lang.c
Set the result of void function Thiago Adams <thiago.adams@gmail.com> - 2017-09-19 14:23 -0700
Re: Set the result of void function Thiago Adams <thiago.adams@gmail.com> - 2017-09-19 14:38 -0700
Re: Set the result of void function gordonb.tfand@burditt.org (Gordon Burditt) - 2017-09-19 17:16 -0500
Re: Set the result of void function "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-09-20 00:39 +0200
Re: Set the result of void function James Kuyper <jameskuyper@verizon.net> - 2017-09-19 22:06 -0400
Re: Set the result of void function "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-09-20 06:51 +0200
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-20 10:55 +0100
Re: Set the result of void function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-20 12:11 +0100
Re: Set the result of void function fir <profesor.fir@gmail.com> - 2017-09-20 07:17 -0700
Re: Set the result of void function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-20 11:28 +0100
Re: Set the result of void function mark.bluemel@gmail.com - 2017-09-20 03:30 -0700
Re: Set the result of void function fir <profesor.fir@gmail.com> - 2017-09-20 06:53 -0700
Re: Set the result of void function Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-09-21 03:50 -0500
Re: Set the result of void function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-21 11:00 +0100
Re: Set the result of void function scott@slp53.sl.home (Scott Lurndal) - 2017-09-21 12:39 +0000
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-21 14:12 +0100
Re: Set the result of void function scott@slp53.sl.home (Scott Lurndal) - 2017-09-21 13:51 +0000
Re: Set the result of void function Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-09-21 08:36 -0600
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-21 17:51 +0100
Re: Set the result of void function supercat@casperkitty.com - 2017-09-21 10:06 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-22 08:51 +0200
Plunging innocent people into poverty (Was: Set the result of void function) gazelle@shell.xmission.com (Kenny McCormack) - 2017-09-23 09:31 +0000
Re: Plunging innocent people into poverty (Was: Set the result of void function) David Brown <david.brown@hesbynett.no> - 2017-09-23 12:09 +0200
Re: Plunging innocent people into poverty (Was: Set the result of void function) gazelle@shell.xmission.com (Kenny McCormack) - 2017-09-23 10:25 +0000
Re: Plunging innocent people into poverty Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-09-23 10:43 -0600
Re: Plunging innocent people into poverty supercat@casperkitty.com - 2017-09-23 10:41 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-22 09:37 +0200
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-22 11:27 +0100
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-22 14:42 +0200
Re: Set the result of void function Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-24 12:09 +0000
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-25 08:31 +0200
Re: Set the result of void function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-25 03:52 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-25 13:25 +0200
Re: Set the result of void function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-25 04:58 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-25 14:20 +0200
Re: Set the result of void function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 13:44 +0100
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-25 15:09 +0200
Re: Set the result of void function Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 05:44 -0700
Re: Set the result of void function Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 05:58 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-25 15:15 +0200
Re: Set the result of void function Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 06:46 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-25 16:01 +0200
Re: Set the result of void function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-25 07:18 -0700
Re: Set the result of void function Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 07:55 -0700
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-25 08:49 -0700
Re: Set the result of void function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-25 09:21 -0700
Re: Set the result of void function supercat@casperkitty.com - 2017-09-25 09:51 -0700
Re: Set the result of void function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 21:57 +0100
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-25 15:03 -0700
Re: Set the result of void function Öö Tiib <ootiib@hot.ee> - 2017-09-25 21:34 -0700
Re: Set the result of void function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-26 04:28 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-27 08:26 +0200
Re: Set the result of void function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-27 11:48 -0400
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-28 08:54 +0200
Re: Set the result of void function gordonb.iddsu@burditt.org (Gordon Burditt) - 2017-09-28 23:33 -0500
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-27 09:15 -0700
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-27 17:50 +0100
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-27 10:35 -0700
Re: Set the result of void function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-27 18:47 +0100
Re: Set the result of void function supercat@casperkitty.com - 2017-09-27 10:52 -0700
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-27 11:10 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-28 09:10 +0200
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-27 11:06 -0700
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-27 20:01 +0100
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-27 12:26 -0700
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-27 20:38 +0100
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-27 13:00 -0700
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-27 21:54 +0100
Re: Set the result of void function supercat@casperkitty.com - 2017-09-27 14:12 -0700
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-27 14:34 -0700
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-27 23:16 +0100
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-27 16:09 -0700
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-28 01:12 +0100
Re: Set the result of void function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-28 02:03 +0100
Re: Set the result of void function Ian Collins <ian-news@hotmail.com> - 2017-09-28 17:31 +1300
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-28 09:55 +0200
Re: Set the result of void function Ian Collins <ian-news@hotmail.com> - 2017-09-28 21:00 +1300
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-28 10:48 +0100
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-28 13:20 +0200
Re: Set the result of void function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-28 11:29 +0100
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-27 20:27 -0700
Re: Set the result of void function Gareth Owen <gwowen@gmail.com> - 2017-09-29 19:30 +0100
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-29 19:45 +0100
Re: Set the result of void function Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-29 14:49 -0400
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-27 15:07 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-28 09:42 +0200
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-28 13:55 +0100
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-28 17:22 +0200
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-28 09:14 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-28 20:13 +0200
Re: Set the result of void function Gareth Owen <gwowen@gmail.com> - 2017-09-29 19:42 +0100
Re: Set the result of void function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-28 09:14 -0700
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-28 09:25 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-28 20:17 +0200
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-28 17:39 +0100
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-28 10:10 -0700
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-28 19:05 +0100
Re: Set the result of void function "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-28 14:20 -0400
Re: Set the result of void function Ian Collins <ian-news@hotmail.com> - 2017-09-29 07:52 +1300
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-28 11:59 -0700
Re: Set the result of void function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-28 18:50 +0100
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-28 19:47 +0100
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-28 21:57 +0200
Re: Set the result of void function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-28 16:14 -0400
Re: Set the result of void function supercat@casperkitty.com - 2017-09-28 13:17 -0700
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-28 21:23 +0100
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-28 13:55 -0700
Re: Set the result of void function Gareth Owen <gwowen@gmail.com> - 2017-09-29 19:50 +0100
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-28 13:57 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-28 23:18 +0200
Re: Set the result of void function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-28 17:38 -0400
Re: Set the result of void function supercat@casperkitty.com - 2017-09-28 15:54 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-29 08:59 +0200
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-28 14:43 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-29 10:43 +0200
Re: Set the result of void function supercat@casperkitty.com - 2017-09-29 07:43 -0700
Re: Set the result of void function Gareth Owen <gwowen@gmail.com> - 2017-09-30 19:21 +0100
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-30 19:45 +0100
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-28 13:31 -0700
Re: Set the result of void function supercat@casperkitty.com - 2017-09-28 13:41 -0700
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-28 14:07 -0700
Re: Set the result of void function David Kleinecke <dkleinecke@gmail.com> - 2017-09-28 16:25 -0700
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-28 18:45 -0700
Re: Set the result of void function David Kleinecke <dkleinecke@gmail.com> - 2017-09-28 19:54 -0700
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-28 20:51 -0700
Re: Set the result of void function David Kleinecke <dkleinecke@gmail.com> - 2017-09-28 22:39 -0700
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-29 09:16 -0700
Re: Set the result of void function gazelle@shell.xmission.com (Kenny McCormack) - 2017-09-29 16:17 +0000
Re: Set the result of void function David Kleinecke <dkleinecke@gmail.com> - 2017-09-29 11:05 -0700
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-29 11:23 -0700
Re: Set the result of void function supercat@casperkitty.com - 2017-09-29 12:15 -0700
Re: Set the result of void function David Kleinecke <dkleinecke@gmail.com> - 2017-09-29 16:04 -0700
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-29 16:44 -0700
Re: Set the result of void function David Kleinecke <dkleinecke@gmail.com> - 2017-09-30 10:04 -0700
Re: Set the result of void function supercat@casperkitty.com - 2017-09-30 10:33 -0700
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-29 11:26 -0700
Re: Set the result of void function David Kleinecke <dkleinecke@gmail.com> - 2017-09-29 16:03 -0700
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-29 09:44 -0700
Re: Set the result of void function David Kleinecke <dkleinecke@gmail.com> - 2017-09-29 11:15 -0700
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-29 11:35 -0700
Re: Set the result of void function David Kleinecke <dkleinecke@gmail.com> - 2017-09-29 16:11 -0700
Re: Set the result of void function David Kleinecke <dkleinecke@gmail.com> - 2017-09-29 16:14 -0700
Re: Set the result of void function supercat@casperkitty.com - 2017-09-30 08:55 -0700
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-29 11:36 -0700
Re: Set the result of void function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-29 12:05 +0100
Re: Set the result of void function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-29 12:17 +0100
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-29 09:15 -0700
Re: Set the result of void function Ian Collins <ian-news@hotmail.com> - 2017-09-29 09:42 +1300
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-28 21:55 +0100
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-28 14:12 -0700
Re: Set the result of void function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-28 17:22 -0400
Re: Set the result of void function Gareth Owen <gwowen@gmail.com> - 2017-09-29 19:50 +0100
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-28 09:00 -0700
Re: Set the result of void function supercat@casperkitty.com - 2017-09-28 09:35 -0700
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-28 10:57 -0700
Re: Set the result of void function Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 10:35 -0700
Re: Set the result of void function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-25 06:57 -0700
Re: Set the result of void function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 16:32 +0100
Re: Set the result of void function Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-25 08:43 -0700
Re: Set the result of void function Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 22:12 +0100
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-25 09:03 -0700
Re: Set the result of void function Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-25 14:17 +0000
Re: Set the result of void function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-20 11:32 -0400
Re: Set the result of void function fir <profesor.fir@gmail.com> - 2017-09-20 01:50 -0700
Re: Set the result of void function David Kleinecke <dkleinecke@gmail.com> - 2017-09-20 15:56 -0700
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-19 23:01 +0100
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-20 15:40 +0200
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-20 08:50 -0700
Re: Set the result of void function David Brown <david.brown@hesbynett.no> - 2017-09-20 22:52 +0200
Re: Set the result of void function supercat@casperkitty.com - 2017-09-20 15:04 -0700
Re: Set the result of void function supercat@casperkitty.com - 2017-09-20 07:39 -0700
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-19 15:18 -0700
Re: Set the result of void function bartc <bc@freeuk.com> - 2017-09-20 01:21 +0100
Re: Set the result of void function jameskuyper@verizon.net - 2017-09-19 19:40 -0700
Re: Set the result of void function rockbrentwood@gmail.com - 2017-09-19 16:36 -0700
Re: Set the result of void function James Kuyper <jameskuyper@verizon.net> - 2017-09-19 22:13 -0400
Re: Set the result of void function gazelle@shell.xmission.com (Kenny McCormack) - 2017-09-22 01:48 +0000
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-19 19:36 -0700
Re: Set the result of void function mark.bluemel@gmail.com - 2017-09-20 01:00 -0700
Re: Set the result of void function fir <profesor.fir@gmail.com> - 2017-09-20 02:01 -0700
Re: Set the result of void function Keith Thompson <kst-u@mib.org> - 2017-09-20 08:36 -0700
Re: Set the result of void function "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-20 11:36 -0400
Re: Set the result of void function John Bode <jfbode1029@gmail.com> - 2017-09-20 15:30 -0700
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-09-27 20:27 -0700 |
| Message-ID | <76d095aa-d7bc-4bed-bd8e-e6f7f944847f@googlegroups.com> |
| In reply to | #120414 |
On Wednesday, September 27, 2017 at 8:12:21 PM UTC-4, Bart wrote:
> On 28/09/2017 00:09, jameskuyper@verizon.net wrote:
> > On Wednesday, September 27, 2017 at 6:16:09 PM UTC-4, Bart wrote:
...
> >> Unusually, we're not talking about a proposed change to C this time.
> >
> > No, we're not, and I'd prefer that we were. What would have to be changed in C
> > for you to admit that it does have subroutines? Are you suggesting, for
> > instance, that replacing
> >
> > void f(void);
> >
> > with
> >
> > subroutine f(void);
> >
> > is necessary in order for f() to be considered a subroutine?
>
> That's a good start. It's the sort of distinction I prefer. ...
I can understand why you might prefer a different syntax - but I don't
understand how the question of whether or not f() qualifies as a subroutine can
depend upon whether the relevant keyword is "subroutine" rather than "void". .
If the keyword "banana" were added as a new declaration specifier to the C
language, would that make functions declared with that keyword bananas,
regardless of what the semantics of that keyword were?
...
> > No, part of the fact that implementations are free to do what they like is that
> > you insist on including non-conforming implementations when talking about C.
> > Even if C had made a distinction between functions and subroutines, exactly the
> > way you want it to, from the very beginning, non-conforming implementations
> > would still be exactly as free as they are today, to do whatever they wanted to
> > do. Until you learn how to put your compilers into conforming mode, and until
> > you overcome your ridiculous refusal to invoke them in conforming mode, you're
> > going to continue getting ridiculously variable results from different
> > compilers.
>
> OK, start with this module:
>
> int fred(void) {}
> void bill(void) {return 123;}
>
> Running gcc, it says nothing about line 1, and gives a warning on line
> 2. Are you telling me gcc is non-conforming? ...
No, You reported observing the following behavior:
> >> Return X seen in a Subroutine:
> >> C Ignored or warning
> >> non-C ERROR
"Ignored" would be non-conforming behavior for a C compiler. I was explaining
how the fact that you routinely invoke compilers in non-conforming mode is the
most likely explanation for your observation of the "Ignored" results. However,
as you yourself point out, gcc does warn about about line 2, which is conforming
behavior. I'm not sure how you misinterpreted what I said so as to reach the
opposite conclusion.
> ... If I give it -std=c99, it's
> the same. Only when I give it all this:
>
> -std=c11 -Wextra -Wall -Wpedantic
>
> then I get warnings on both. But still only warnings! Now, if you were
> doing a code review on this, is there any way there you would pass this
> code, ever? (Assume the functions - or the function and subroutine - do
> a necessary job other than missing out one return value and adding one
> extraneous one.)
>
> And if you wouldn't pass it, why shouldn't the compiler give a hard
> error? Or do you expect every single programmer that uses gcc to add a
> set of options to it to diagnose such problems?
Yes, I do. I don't approve of the fact that gcc, be default, is non-conforming
and provides lousy diagnostics. However, it can be commanded to be conforming
and to provide better diagnostics - and if so commanded, it obeys. If it were
the only compiler to behave this way, I'd switch to a better compiler. However,
for reasons best known to the implementors, most compilers I've ever seen are
non-conforming and provide lousy diagnostics in default mode, so I have to learn
to live with this. You have decided to complain about it endless to us, who have
no power to change that fact. I'd prefer it if you would devote that same energy
to complaining to the implementors, instead. You might not get any better
response from them than you could get from us, but they actually have the power
to change what you're complaining about - we don't.
...
> Same two lines:
>
> int fred(void) {}
> void bill(void) {return 123;}
>
> My compiler says this:
>
> "Missing return statement in function"
>
> for the first line. When fixed or commented (as it will abort at that
> point), it would then say:
>
> "Can't return value in void function"
>
> for the second line. Both hard errors.
Which means your compiler is non-conforming, and not backwards compatible with
code written before the invention of the 'void' keyword. That doesn't matter to
you, which is fine. It does matter to the C committee, which is also fine. You
have different objectives from the C committee.
...
> functions deep inside expressions, led me to say this in my first post
> on the subject:
>
> "It [C] emulates subroutines, which are procedures that don't return
> values, with functions returning a special 'void' value."
Which remains just as incorrect as it ever was. There is a special void type,
but there's no such thing as a value of that type, and when used as the nominal
"return type" for a function, it doesn't mean that the function returns a value
of type void, it means that he function doesn't return any value at all.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-09-29 19:30 +0100 |
| Message-ID | <87efqpuzlu.fsf@gmail.com> |
| In reply to | #120413 |
jameskuyper@verizon.net writes: > No, we're not, and I'd prefer that we were. What would have to be changed in C > for you to admit that it does have subroutines? Are you suggesting, for > instance, that replacing > > void f(void); > > with > > subroutine f(void); > > is necessary in order for f() to be considered a subroutine? What you must recall when asking these questions of Bart is that he has repeatedly proved himself to be dumber than a box of rocks. I suggest you keep that in mind when deciding whether to pursue this debate.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-29 19:45 +0100 |
| Message-ID | <2xwzB.1327692$ji4.201296@fx10.am4> |
| In reply to | #120568 |
On 29/09/2017 19:30, Gareth Owen wrote: > jameskuyper@verizon.net writes: > >> No, we're not, and I'd prefer that we were. What would have to be changed in C >> for you to admit that it does have subroutines? Are you suggesting, for >> instance, that replacing >> >> void f(void); >> >> with >> >> subroutine f(void); >> >> is necessary in order for f() to be considered a subroutine? > > What you must recall when asking these questions of Bart is that he has > repeatedly proved himself to be dumber than a box of rocks. > > I suggest you keep that in mind when deciding whether to pursue this debate. > I see you've just crawled out from under your rock again. You can fuck off back under there I think.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-09-29 14:49 -0400 |
| Message-ID | <oqm4jj$gds$1@jstuckle.eternal-september.org> |
| In reply to | #120568 |
On 9/29/2017 2:30 PM, Gareth Owen wrote: > > What you must recall when asking these questions of Bart is that he has > repeatedly proved himself to be dumber than a box of rocks. > What do you have against a box of rocks, Gareth? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-27 15:07 -0700 |
| Message-ID | <lntvznyewl.fsf@kst-u.example.com> |
| In reply to | #120408 |
bartc <bc@freeuk.com> writes:
> On 27/09/2017 21:00, jameskuyper@verizon.net wrote:
>> On Wednesday, September 27, 2017 at 3:38:18 PM UTC-4, Bart wrote:
>> ...
>>> I thought I'd made my position clear: C's subroutines are only
>>> lookalikes ...
>>
>> No, it's very unclear how they fail (in your mind, if nowhere else) to qualify
>> as subroutines. You had to invoke the non-existent concept of a void value to
>> explain your objection. That concept is so central to your objection that it's
>> not at all clear what it would look like if you re-wrote it to correct that
>> error.
>>
>>> ... and only mildly enforced by the language.
>>
>> They're as strongly enforced as any other feature of the language: a diagnostic
>> is mandatory, successful translation of the code is not, and if the
>> implementation chooses to translate the code and the user chooses to ignore the
>> diagnostic and execute the resulting program anyway, the behavior is undefined.
>> C doesn't enforce any requirement more strongly than that.
>
> This is very difficult for me to argue.
As it should be, since James is absolutely correct.
> If I say a compiler says nothing
> about something that it should, you will say it's non-conforming.
Of course.
> If I it only warns, then you will say it's conforming, and it's the
> user's fault if they ignore it, or if they can't figure how to tell the
> compiler to do its job.
I would say the compiler is non-conforming. I might or might not say
anything beyond that.
> Anything except admit that the language should been far more explicit!
And there's the problem.
James and I are both telling you what the C language standard actually
says, and what it implies about how a conforming implementation must
behave. We do not always express a personal opinion about what the C
standard *should* say. Explaining what the standard says does not imply
that anyone thinks it's perfect, or even necessarily that it's good.
Do you understand the distinction?
You want to discuss personal opinion? Fine, here's mine. I would
prefer it if the C standard stated that diagnostics for violations of
constraints and syntax rules must be fatal errors. More precisely,
where it now says (N1570 5.1.1.3 Diagnostics):
A conforming implementation shall produce at least one diagnostic
message (identified in an implementation-defined manner) if a
preprocessing translation unit or translation unit contains a
violation of any syntax rule or constraint, [...]
I'd like to see added wording something like:
... and shall not successfully translate such a preprocessing
translation unit or translation unit.
(some wording borrowed from 4p4 which discusses #error).
From what you've said, I suspect you and I are largely in agreement on
that point.
I do not particularly expect any such change to happen in a future
standard, and I don't spend a lot of time worrying about it.
As it happens, at least some compilers have options (like "gcc
-pedantic-errors") that cause them to behave that way already.
"gcc -pedantic" issues warnings for some constraint violations, which
is still conforming but IMHO less than ideal. "gcc -pedantic-errors"
treats constraint violations as fatal errors, which is also
conforming. (Syntax errors are usually fatal in any case.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-28 09:42 +0200 |
| Message-ID | <oqi94p$jl4$1@dont-email.me> |
| In reply to | #120408 |
On 27/09/17 22:54, bartc wrote: > On 27/09/2017 21:00, jameskuyper@verizon.net wrote: >> On Wednesday, September 27, 2017 at 3:38:18 PM UTC-4, Bart wrote: >> ... >>> I thought I'd made my position clear: C's subroutines are only >>> lookalikes ... >> >> No, it's very unclear how they fail (in your mind, if nowhere else) to >> qualify >> as subroutines. You had to invoke the non-existent concept of a void >> value to >> explain your objection. That concept is so central to your objection >> that it's >> not at all clear what it would look like if you re-wrote it to correct >> that >> error. >> >>> ... and only mildly enforced by the language. >> >> They're as strongly enforced as any other feature of the language: a >> diagnostic >> is mandatory, successful translation of the code is not, and if the >> implementation chooses to translate the code and the user chooses to >> ignore the >> diagnostic and execute the resulting program anyway, the behavior is >> undefined. >> C doesn't enforce any requirement more strongly than that. > > This is very difficult for me to argue. If I say a compiler says nothing > about something that it should, you will say it's non-conforming. > > If I it only warns, then you will say it's conforming, and it's the > user's fault if they ignore it, or if they can't figure how to tell the > compiler to do its job. > As Keith explained, a "diagnostic" can be just a warning. And like Keith, I would /prefer/ such cases to be hard errors. It is not a problem for /my/ coding - I use "-Wall -Wextra -Werror" and such mistakes will give hard errors. But I have had to deal with other people's code when the programmer thought "it's only a warning - I can ignore warnings". It would be nice if the standards were harsher here. However, as Supercat said, backwards compatibility is important - even when the old code was poorly written. As users, there is an easy solution to all this - we can make the language stricter by using decent compilers and using good compiler options, at least while developing code. > Anything except admit that the language should been far more explicit! > > Here's a brief comparison of subroutines and functions between C, and a > typical other language where they are more distinct; I've used mine as > an example: > And here is some results from a brief test with gcc - without /any/ options other than "-std=c11". > Subroutine designation: > > C void name // or 'T name' when T is void > non-C PROC name > > Function designation: > > C T name // when T is not void > non-C FUNCTION name > > Return X seen in a Subroutine: > > C Ignored or warning A diagnostic (warning or error) is mandatory - the compiler may not ignore this. gcc: warning: 'return' with a value, in function returning void > non-C ERROR > > Return with no value seen in a Function: > > C Ignored or warning A diagnostic (warning or error) is mandatory - the compiler may not ignore this. gcc: warning: 'return' with no value, in function returning non-void > non-C ERROR > > Run into end of a Function: > > C Ignored or warning That is allowed in C (6.9.1p12), but /using/ the value returned is undefined behaviour. gcc gives no diagnostic here by default (after all, it is legal C). (In my opinion, it would be better to have a hard error - it's C's backward compatibility again.) > non-C ERROR > > Appear in ?: expression, example x?y:Subroutine(); : > > C Ignored (assuming at statement/expr level) Assuming "x" is not an expression of void type, this is a constraint violation (6.5.15p3) and requires a diagnostic. gcc: error: void value not ignored as it ought to be > non-C ERROR (?: must return a value) > > Notice that the non-C is, in all cases, completely unequivocal about > what is a subroutine, and what is a function. Notice that in almost all cases here, you are wrong about what the C standards say. And the simple application of common flags "-Wall -Werror" (along with "-Wpedantic" if you like) gives you the errors you want from gcc, rather than just warnings. Other compilers of any reasonable quality will do the same - perhaps without needing flags. (The case of hitting the end of a non-void function is a little different, because it is legal C.) > > While C's attitude is much more laid-back: yes, it's a subroutine > provided T (defined several headers deep) is void. Run into the end of a > function with no 'return X;'? No problem, man! > >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-28 13:55 +0100 |
| Message-ID | <ej6zB.1196081$ik4.742321@fx38.am4> |
| In reply to | #120428 |
On 28/09/2017 08:42, David Brown wrote: > On 27/09/17 22:54, bartc wrote: >> Return with no value seen in a Function: >> >> C Ignored or warning > > A diagnostic (warning or error) is mandatory - the compiler may not > ignore this. > > gcc: warning: 'return' with no value, in function returning non-void That's what I said: Ignored or warning. My tests with C weren't exhaustive. Tiny C ignored it. Gcc (even with -std=c11, -Wall etc) gave a warning, as did MSVC. Three lesser compilers gave an error. But it shows how hit and miss these things are. Mainstream compilers will gave a warning unless you use some brute force (eg. -Werror) to make every warning, even a harmless one, a fatal error. >> non-C ERROR >> >> Run into end of a Function: >> >> C Ignored or warning > > That is allowed in C (6.9.1p12), but /using/ the value returned is > undefined behaviour. > > gcc gives no diagnostic here by default (after all, it is legal C). My gcc, with all the options, said 'control reaches end of non-void function'. If -Werror was used (the same -Werror as used to make the above issue a fatal error), then this would fail a program that you said above is legal. >> Appear in ?: expression, example x?y:Subroutine(); : >> >> C Ignored (assuming at statement/expr level) > > Assuming "x" is not an expression of void type, this is a constraint > violation (6.5.15p3) and requires a diagnostic. > > gcc: error: void value not ignored as it ought to be I got "ISO C forbids conditional expression with only one void side" (a warning). If the void function is on both branches of ?:, then it's ignored. But then, ?: is merely being used to do the job of if-else. ?: is presumably intended to allow if-else on values in expressions, which is impossible otherwise. >> non-C ERROR (?: must return a value) >> >> Notice that the non-C is, in all cases, completely unequivocal about >> what is a subroutine, and what is a function. > > Notice that in almost all cases here, you are wrong about what the C > standards say. Sometimes you have to use common sense. Tell, me, under what circumstances would running off the end of a non-void function, not returning a value from a non-void function, or returning a value in a void function, ever pass a code review? If the answer is 'never', then what is the language and/or compiler playing at in letting them through as warnings? Why do they have to be told to make them errors? If the answer is backwards compatibility with old software (although you'd have to ask why it contains such code in the first place), then the obvious solution is to either fix the software, or make such options work the other way: you have to tell the compiler to allow through such dubious constructs. The answer isn't for Bart to brush up on his compiler-options knowledge; that benefits no one and changes nothing. In the case of allowing void-functions inside top-level ?: operators, what would be the implications of not allowing it? That you'd have to use if-else instead? That would be a good thing! (BTW notice how we have to keep saying void-functions and non-void functions, instead of Subroutine and Functions. I don't know about you but for me there's a fraction of a second delay as I translate that into 'Proc' or 'Function'. Having Subroutine and Function as separate concepts is more helpful than having them as two attributes of the same concept. But I said I was done on that topic...) > And the simple application of common flags "-Wall -Werror" (along with > "-Wpedantic" if you like) gives you the errors you want from gcc, rather > than just warnings. See above. The answer isn't just piling on option after option. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-28 17:22 +0200 |
| Message-ID | <oqj43k$g9l$1@dont-email.me> |
| In reply to | #120440 |
On 28/09/17 14:55, bartc wrote: > On 28/09/2017 08:42, David Brown wrote: >> On 27/09/17 22:54, bartc wrote: > > >>> Return with no value seen in a Function: >>> >>> C Ignored or warning >> >> A diagnostic (warning or error) is mandatory - the compiler may not >> ignore this. >> >> gcc: warning: 'return' with no value, in function returning non-void > > > That's what I said: Ignored or warning. "Ignored" is not an option for a conforming compiler. And while most compilers are not entirely conforming by default, compilers of any quality are going to give either a warning or an error in cases where the standards require a diagnostic. > My tests with C weren't > exhaustive. Tiny C ignored it. Gcc (even with -std=c11, -Wall etc) gave > a warning, as did MSVC. Three lesser compilers gave an error. "Tiny C" is an experiment in trying to make a vaguely C-like compiler which is as small as possible. Counting its behaviour when looking at "a selection of C compilers" is like telling us that cars generally have 3 or 4 wheels because your sample of cars includes a Reliant Robin. > > But it shows how hit and miss these things are. Mainstream compilers > will gave a warning unless you use some brute force (eg. -Werror) to > make every warning, even a harmless one, a fatal error. No, it shows that the mainstream compilers do what the C language requires - they issue a diagnostic. There is no hit and miss about it. If you really want to make this particular case a hard error while leaving some other warnings as warnings, then mainstream compilers provide for that. The details are left as a homework exercise. > >>> non-C ERROR >>> >>> Run into end of a Function: >>> >>> C Ignored or warning >> >> That is allowed in C (6.9.1p12), but /using/ the value returned is >> undefined behaviour. >> >> gcc gives no diagnostic here by default (after all, it is legal C). > > My gcc, with all the options, said 'control reaches end of non-void > function'. If -Werror was used (the same -Werror as used to make the > above issue a fatal error), then this would fail a program that you said > above is legal. You are trolling, right? You can't /still/ be misunderstanding that you need appropriate options to make a compiler conforming? If you use options like -Wall -Wextra -Werror, then the compiler will reject some programs that have legal C because the code uses constructs that are legal, but may be considered questionable. For example, those options would reject code that had "while (c = *p++)", because it is includes a warning (and therefore, with -Werror, an error) about possible incorrect use of "=" instead of "==". > >>> Appear in ?: expression, example x?y:Subroutine(); : >>> >>> C Ignored (assuming at statement/expr level) >> >> Assuming "x" is not an expression of void type, this is a constraint >> violation (6.5.15p3) and requires a diagnostic. >> >> gcc: error: void value not ignored as it ought to be > > I got "ISO C forbids conditional expression with only one void side" (a > warning). The details may vary according to the version of gcc. Use godbolt.org if you are interested. > > If the void function is on both branches of ?:, then it's ignored. It is not "ignored" - it is simply perfectly good C code. 6.5.15p3 again - I give these references so that you can read them in the standards. > But > then, ?: is merely being used to do the job of if-else. ?: is presumably > intended to allow if-else on values in expressions, which is impossible > otherwise. > Whether you like using ?: like that or not is up to you. >>> non-C ERROR (?: must return a value) >>> >>> Notice that the non-C is, in all cases, completely unequivocal about >>> what is a subroutine, and what is a function. >> >> Notice that in almost all cases here, you are wrong about what the C >> standards say. > > Sometimes you have to use common sense. Yes - try it. Common sense would suggest that if you want to know what the C language says about these cases, you could look it up in the standards rather than guessing what you think it out to say. > > Tell, me, under what circumstances would running off the end of a > non-void function, not returning a value from a non-void function, or > returning a value in a void function, ever pass a code review? > It would never pass one of /my/ code reviews. But it was allowed in pre-standard C code, and was /used/ in pre-standard C code, and therefore has been kept in the C standards because the C standards prefer not to break old code unless they really have to. They leave it up to the implementation to provide warnings on poor code like that, and the mainstream C implementations support the old code while providing checks to prevent such poor style in new code. > If the answer is 'never', then what is the language and/or compiler > playing at in letting them through as warnings? Why do they have to be > told to make them errors? > > If the answer is backwards compatibility with old software (although > you'd have to ask why it contains such code in the first place), then > the obvious solution is to either fix the software, or make such options > work the other way: you have to tell the compiler to allow through such > dubious constructs. I'd be quite happy for compilers to have warnings - and even errors - on this kind of thing by default. But compiler implementers usually pick defaults that suit backwards compatibility. That's okay, of course. People developing software should know how to use compiler warnings when developing and testing their code. It does not matter in the slightest if people /using/ that code have such warnings enabled - the code will never trigger them anyway. And the trouble with picking default sets of warnings is that people will have wildly different ideas about what warnings should be enabled. The ones discussed here may be popular, but there are lots of others that are more controversial. > > The answer isn't for Bart to brush up on his compiler-options knowledge; > that benefits no one and changes nothing. Yes, that /is/ the answer - it benefits /you/ because you will write better code with fewer bugs, and it benefits everyone here because we would not have the same endless moaning from you about compiler options. > > In the case of allowing void-functions inside top-level ?: operators, > what would be the implications of not allowing it? That you'd have to > use if-else instead? That would be a good thing! > > (BTW notice how we have to keep saying void-functions and non-void > functions, instead of Subroutine and Functions. I don't know about you > but for me there's a fraction of a second delay as I translate that into > 'Proc' or 'Function'. Having Subroutine and Function as separate > concepts is more helpful than having them as two attributes of the same > concept. But I said I was done on that topic...) That again is /your/ problem - if indeed you feel a fraction of a second delay is a problem. > >> And the simple application of common flags "-Wall -Werror" (along with >> "-Wpedantic" if you like) gives you the errors you want from gcc, rather >> than just warnings. > > See above. The answer isn't just piling on option after option. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-28 09:14 -0700 |
| Message-ID | <lna81eyf4a.fsf@kst-u.example.com> |
| In reply to | #120445 |
David Brown <david.brown@hesbynett.no> writes:
> On 28/09/17 14:55, bartc wrote:
>> On 28/09/2017 08:42, David Brown wrote:
>>> On 27/09/17 22:54, bartc wrote:
>>>> Return with no value seen in a Function:
>>>>
>>>> C Ignored or warning
>>>
>>> A diagnostic (warning or error) is mandatory - the compiler may not
>>> ignore this.
>>>
>>> gcc: warning: 'return' with no value, in function returning non-void
[...]
>> My tests with C weren't
>> exhaustive. Tiny C ignored it. Gcc (even with -std=c11, -Wall etc) gave
>> a warning, as did MSVC. Three lesser compilers gave an error.
>
> "Tiny C" is an experiment in trying to make a vaguely C-like compiler
> which is as small as possible. Counting its behaviour when looking at
> "a selection of C compilers" is like telling us that cars generally have
> 3 or 4 wheels because your sample of cars includes a Reliant Robin.
That's a bit unfair to tcc. On my system (Ubuntu 17.04, x86_64, tcc
0.9.27), I get:
$ cat c.c
int fred(void) {}
void bill(void) {return 123;}
$ tcc -c c.c
c.c:2: error: cannot cast from/to void
$
The error message is not worded well, but tcc's behavior is conforming.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-28 20:13 +0200 |
| Message-ID | <oqje4l$ug8$1@dont-email.me> |
| In reply to | #120451 |
On 28/09/17 18:14, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 28/09/17 14:55, bartc wrote:
>>> On 28/09/2017 08:42, David Brown wrote:
>>>> On 27/09/17 22:54, bartc wrote:
>>>>> Return with no value seen in a Function:
>>>>>
>>>>> C Ignored or warning
>>>>
>>>> A diagnostic (warning or error) is mandatory - the compiler may not
>>>> ignore this.
>>>>
>>>> gcc: warning: 'return' with no value, in function returning non-void
> [...]
>>> My tests with C weren't
>>> exhaustive. Tiny C ignored it. Gcc (even with -std=c11, -Wall etc) gave
>>> a warning, as did MSVC. Three lesser compilers gave an error.
>>
>> "Tiny C" is an experiment in trying to make a vaguely C-like compiler
>> which is as small as possible. Counting its behaviour when looking at
>> "a selection of C compilers" is like telling us that cars generally have
>> 3 or 4 wheels because your sample of cars includes a Reliant Robin.
>
> That's a bit unfair to tcc. On my system (Ubuntu 17.04, x86_64, tcc
> 0.9.27), I get:
>
> $ cat c.c
> int fred(void) {}
> void bill(void) {return 123;}
> $ tcc -c c.c
> c.c:2: error: cannot cast from/to void
> $
>
> The error message is not worded well, but tcc's behavior is conforming.
>
I don't have tcc - it does not target the cpus I need. So I only had
Bart's comment to go on.
And tcc may be a fine example of what can be done in a small amount of
code - but I don't believe it aims to be a carefully conforming
compiler, or one with substantial levels of static warnings.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-09-29 19:42 +0100 |
| Message-ID | <87a81duz0s.fsf@gmail.com> |
| In reply to | #120470 |
David Brown <david.brown@hesbynett.no> writes: > I don't have tcc - it does not target the cpus I need. So I only had > Bart's comment to go on. In such circumstances, you probably need to consider the source.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-09-28 09:14 -0700 |
| Message-ID | <4c1bbda7-bee7-4dac-b9a1-7e2bd2d3486b@googlegroups.com> |
| In reply to | #120445 |
On Thursday, September 28, 2017 at 4:22:37 PM UTC+1, David Brown wrote:
> On 28/09/17 14:55, bartc wrote:
>
> > Tell, me, under what circumstances would running off the end of a
> > non-void function, not returning a value from a non-void function, or
> > returning a value in a void function, ever pass a code review?
> >
>
> It would never pass one of /my/ code reviews. But it was allowed in
> pre-standard C code, and was /used/ in pre-standard C code, and
> therefore has been kept in the C standards because the C standards
> prefer not to break old code unless they really have to. They leave it
> up to the implementation to provide warnings on poor code like that, and
> the mainstream C implementations support the old code while providing
> checks to prevent such poor style in new code.
>
Consider this
/*
DNA base pairing partner
*/
char partner(char base)
{
switch(base)
{
case 'A' : return 'T';
case 'C' : return 'G';
case 'G': return 'C':
case 'T': return 'A':
default: assert(0);
}
}
The function cannot legitimately be called with anything other
than one of the four DNA bases. But it isn't clear what it should
do if assertions are turned off. Returning garbage is probably
a reasonable answer. If we return 0 people might start relying
on the behaviour and mis-use the function as an "isDNABase().
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-28 09:25 -0700 |
| Message-ID | <ln60c2yemi.fsf@kst-u.example.com> |
| In reply to | #120452 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> Consider this
>
> /*
> DNA base pairing partner
> */
> char partner(char base)
> {
> switch(base)
> {
> case 'A' : return 'T';
> case 'C' : return 'G';
> case 'G': return 'C':
> case 'T': return 'A':
> default: assert(0);
> }
> }
>
> The function cannot legitimately be called with anything other
> than one of the four DNA bases. But it isn't clear what it should
> do if assertions are turned off. Returning garbage is probably
> a reasonable answer. If we return 0 people might start relying
> on the behaviour and mis-use the function as an "isDNABase().
I might consider adding `return '?';` after the assert, so that
when NDEBUG is defined errors show consistent symptoms. Seeing '?'
in the output is a clue that soomething is wrong.
On the other hand, leaving off the return means that a sufficiently
clever compiler might be able to diagnose some such errors at compile
time.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-28 20:17 +0200 |
| Message-ID | <oqjec8$28l$1@dont-email.me> |
| In reply to | #120452 |
On 28/09/17 18:14, Malcolm McLean wrote:
> On Thursday, September 28, 2017 at 4:22:37 PM UTC+1, David Brown wrote:
>> On 28/09/17 14:55, bartc wrote:
>>
>>> Tell, me, under what circumstances would running off the end of a
>>> non-void function, not returning a value from a non-void function, or
>>> returning a value in a void function, ever pass a code review?
>>>
>>
>> It would never pass one of /my/ code reviews. But it was allowed in
>> pre-standard C code, and was /used/ in pre-standard C code, and
>> therefore has been kept in the C standards because the C standards
>> prefer not to break old code unless they really have to. They leave it
>> up to the implementation to provide warnings on poor code like that, and
>> the mainstream C implementations support the old code while providing
>> checks to prevent such poor style in new code.
>>
> Consider this
>
> /*
> DNA base pairing partner
> */
> char partner(char base)
> {
> switch(base)
> {
> case 'A' : return 'T';
> case 'C' : return 'G';
> case 'G': return 'C':
> case 'T': return 'A':
> default: assert(0);
> }
> }
>
> The function cannot legitimately be called with anything other
> than one of the four DNA bases. But it isn't clear what it should
> do if assertions are turned off. Returning garbage is probably
> a reasonable answer. If we return 0 people might start relying
> on the behaviour and mis-use the function as an "isDNABase().
>
That is legal C. It is an example of the type of code that (conforming)
C compilers have to support, and they don't give diagnostics if you fall
off the end of a non-void function. /I/ would not write code like that,
but of course /you/ are welcome to do so. There are plenty of
constructs that are legal, well-defined C and which I would not write.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-28 17:39 +0100 |
| Message-ID | <uB9zB.1550017$WI6.973316@fx30.am4> |
| In reply to | #120445 |
On 28/09/2017 16:22, David Brown wrote:
> On 28/09/17 14:55, bartc wrote:
> Whether you like using ?: like that or not is up to you.
You obviously don't care about such matters.
My opinion is that there is no point in using ?: in a context where
if-else would do. Only if you wanted code to appear cryptic, as a lot of
people obviously do.
>> The answer isn't for Bart to brush up on his compiler-options knowledge;
>> that benefits no one and changes nothing.
>
> Yes, that /is/ the answer - it benefits /you/ because you will write
> better code with fewer bugs, and it benefits everyone here because we
> would not have the same endless moaning from you about compiler options.
OK, I understand. If I write this:
int main(void) {
int a;
void fn();
fn(100);
fn(200.0);
fn("Hello, World!");
fn(&a);
}
which is clearly not right, compile it using:
gcc -std=c11 -Wextra -Wall -Wpedantic -Werror -c c.c
without a peep out of the compiler, the fault is not with the Language,
not with the Compiler, and not even with the user. The fault is with
Bart for not knowing what options to feed it. Clearly that lot isn't
quite enough! (Which ones would be? Serious question.)
Also, tell me what options I need here:
-------------------------------------------
//..... code not shown
-------------------------------------------
I've deliberately left out the code, and the issues it was meant to
highlight, because that reflects how it works in practice. You don't
know what's lurking in your 100,000-line project and want the compiler
to tell you.
So, what are the options? Note that -Werror isn't foolproof because I
used it above and it made no difference.
I really, really have a problem with you constantly making personal digs
at me. Is it too hard to acknowledge that the C language and typical C
compilers may actually have an issue here?
Only DMC reports an error in the above. My own compiler only if all
calls to fn() function with are prohibited, which is the right thing to
do IMO. I don't think there's any point in comparing argument lists for
all such calls; they could all match, but they might all be wrong!
Under what circumstances would a declaration like:
void fn();
without listing parameter types be used anyway?
> That again is /your/ problem - if indeed you feel a fraction of a second
> delay is a problem.
/Is/ it just my problem? Maybe this brief hiatus in concentration is
common. Maybe it is also common get void and non-void mixed up (like
case sensitive and case insensitive).
I know that for me, having independent concepts of Proc (Subroutine) and
Function is very helpful.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-09-28 10:10 -0700 |
| Message-ID | <d9efbdf5-7600-4f96-b303-d0fcccfb26fd@googlegroups.com> |
| In reply to | #120456 |
On Thursday, September 28, 2017 at 12:40:03 PM UTC-4, Bart wrote:
> On 28/09/2017 16:22, David Brown wrote:
> > On 28/09/17 14:55, bartc wrote:
>
> > Whether you like using ?: like that or not is up to you.
>
> You obviously don't care about such matters.
>
> My opinion is that there is no point in using ?: in a context where
> if-else would do. Only if you wanted code to appear cryptic, as a lot of
> people obviously do.
?: is much more concise that if-else, and in some contexts that fact makes code which uses ?: much more readable than corresponding code using if-else.
> >> The answer isn't for Bart to brush up on his compiler-options knowledge;
> >> that benefits no one and changes nothing.
> >
> > Yes, that /is/ the answer - it benefits /you/ because you will write
> > better code with fewer bugs, and it benefits everyone here because we
> > would not have the same endless moaning from you about compiler options.
>
> OK, I understand. If I write this:
>
> int main(void) {
> int a;
> void fn();
>
> fn(100);
> fn(200.0);
> fn("Hello, World!");
> fn(&a);
> }
>
> which is clearly not right, compile it using:
>
> gcc -std=c11 -Wextra -Wall -Wpedantic -Werror -c c.c
>
> without a peep out of the compiler, the fault is not with the Language,
> not with the Compiler, and not even with the user. The fault is with
> Bart for not knowing what options to feed it. Clearly that lot isn't
> quite enough! (Which ones would be? Serious question.)
-Wstrict-prototypes. I also recommend -Wmissing-prototypes.
...
> I really, really have a problem with you constantly making personal digs
> at me. Is it too hard to acknowledge that the C language and typical C
> compilers may actually have an issue here?
Yes, when the issue is clearly your personal limited ability to learn these things (limited primarily by your unwillingness to learn them - I suspect that you actually have the capacity to learn them if the prospect of learning such things didn't disgust you so much).
> Under what circumstances would a declaration like:
>
> void fn();
>
> without listing parameter types be used anyway?
In pre-ANSI C code, where it was the only way to declare a function. Backwards compatibility requires that such a declaration remain legal even after prototypes were invented, but any decent modern compiler can be persuaded to warn you about such code, if you could drop your aversion to learning such things, and find out which option is needed to achieve that result.
Declarations like that are also needed when declaring a function if either the function's return type or the type of one of it's arguments is a pointer to a function of the same type. Such a declaration is infinitely recursive. You can terminate the recursion at any point by using a old-style function declaration rather than function prototype. And, no matter where you terminate the recursion, there's a corresponding way to take advantage of that fact to produce code that will malfunction horribly without triggering any mandatory diagnostic.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-28 19:05 +0100 |
| Message-ID | <vRazB.1314868$ji4.316224@fx10.am4> |
| In reply to | #120461 |
On 28/09/2017 18:10, jameskuyper@verizon.net wrote: > On Thursday, September 28, 2017 at 12:40:03 PM UTC-4, Bart wrote: >> I really, really have a problem with you constantly making personal digs >> at me. Is it too hard to acknowledge that the C language and typical C >> compilers may actually have an issue here? > > Yes, when the issue is clearly your personal limited ability to learn these things (limited primarily by your unwillingness to learn them - I suspect that you actually have the capacity to learn them if the prospect of learning such things didn't disgust you so much). My attitude is this: You have a language L, and a compiler CC. To compile program P, you should just be able to do: CC P And it will tell you if anything is wrong with P. It should JUST WORK. Apparently C doesn't fit into that ideology; to get to that point requires a lot more work. Dozens of options need to be added to report even the most blatant errors. And options which which will only work on Gcc (and Clang) as compilers all have their own interpretations of the language and their own options. FWIW I tried: -Wstrict-prototypes -Wmissing-prototypes -Wextra -Wall -Wpedantic -std=c11 and on pretty much every source file I tried on, across a dozen projects, it had warnings streaming up the screen. If there was one pertinent warning in that lot, I would never see it. And if I'd used -Werror as has been suggested, then nothing would ever compile. (Only LUA sources were 'clean', on the couple of test files I tried.) So, now what? Clearly just piling on options doesn't work. Were all applications created with a particular set of options, and everyone has to use exactly the same? Or is possible that no one else, outside the pedants in this group, bother with any but the default options so all these issues get through? I can use just '-std=c11', and still all these ancient practices such as missing prototypes get through unchallenged. You would expect that specifying the desired standard would be an excellent opportunity to change all the default options to suit modern working practices. My suggestion has always been that compilers should work in the strictest, safest mode so that everything is trapped, and to require options to by-pass that. And yet, still you persist with the personal attacks. Is it possible that Bart might actually have a point but no one is willing to admit that? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-09-28 14:20 -0400 |
| Message-ID | <oqjegt$2ks$1@dont-email.me> |
| In reply to | #120466 |
On 9/28/2017 2:05 PM, bartc wrote:
> On 28/09/2017 18:10, jameskuyper@verizon.net wrote:
>> On Thursday, September 28, 2017 at 12:40:03 PM UTC-4, Bart wrote:
>
>>> I really, really have a problem with you constantly making personal digs
>>> at me. Is it too hard to acknowledge that the C language and typical C
>>> compilers may actually have an issue here?
>>
>> Yes, when the issue is clearly your personal limited ability to learn
>> these things (limited primarily by your unwillingness to learn them -
>> I suspect that you actually have the capacity to learn them if the
>> prospect of learning such things didn't disgust you so much).
>
> My attitude is this:
>
> You have a language L, and a compiler CC.
>
> To compile program P, you should just be able to do:
>
> CC P
>
> And it will tell you if anything is wrong with P. It should JUST WORK.
As far as the compiler goes, I correct. However, if you're talking
about the design of the source code, then I have to disagree.
If your purpose is to create a distributable source file, then that
would be the goal (to create P.c for example). However, if you're
dealing with multiple projects and you want reusable code, that's
not the best design for those multiple targets.
> Apparently C doesn't fit into that ideology; to get to that point
> requires a lot more work. Dozens of options need to be added to report
> even the most blatant errors.
I think the compiler itself can be that simple, but there's a reason
why makefiles exists, and build processes, and there are valid reasons
why multiple different source files exist in a project. It comes
from the upstream developers and how they built what they did, and
what it relies upon.
But I do agree with you that even in those cases it should be easier
to install and use. Bjarne Stroustrup just mentioned this in his
2017 C++ DevCon keynote address. His entire presentation is about
how to teach people to write better code, and he has so many ideas
stated that align with CAlive's goals. It made me very happy to
hear them being conveyed:
https://www.youtube.com/watch?v=fX2W3nNjJIo
Bjarne's mention of the need for better package and build systems
is in the area around 41:50 into the video:
https://www.youtube.com/watch?v=fX2W3nNjJIo&t=41m50s
> My suggestion has always been that compilers should work in the
> strictest, safest mode so that everything is trapped, and to require
> options to by-pass that.
Agree completely.
> And yet, still you persist with the personal attacks. Is it possible
> that Bart might actually have a point but no one is willing to admit that?
You have to understand, Bart, their goals are not to help you. They've
identified you as a target for attacks, and no matter what you say they
will continue to attack you.
You have a good head on your shoulders, and you are very intelligent in
software development. I think you have enough ability to step away from
the role of playing catch-up to their attacks, and start making some
assertions or statements as to how things should be. If they disagree
with you, it's up to them to prove where you're wrong, and it's not up
to you to convince them of where you're right.
You've done more with your language than many of them have, and you are
continuing in active development. They're jealous in many ways of your
success, which is why they try to attack you, to keep you from moving
forward because your views are different than theirs, and you don't fit
nicely into their vision of a box.
BTW, Bjarne Stroustrup has a slide at the beginning of his presentation
which has a quote:
The C++ world
"The reasonable man adapts himself to the world: the unreasonable
one persists in trying to adapt the world to himself. Therefore
all progress depends on the unreasonable man."
- George Bernard Shaw
It is true in C as well. And it is true in most situations in life as
well. Don't let these people bother you, but rather take pride in
what you've accomplished, where you are heading, and your internal
desire to learn and grow and influence this world toward making things
more simple. And take confidence from knowing that towering experts
like Bjarne agree with you, and are now teaching the same things.
--
Thank you, | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA/C, Debi, RDC, CAlive, ES/2, VJr, VFrP, Logician, C90/99
Hardware:
Aroxda Desktop CPU -- 40-bit multi-core 80386 with many extensions
Arxita Embedded CPU -- Low power, low pin count 80386 w/128 registers
Arlina Compute FPGA -- Scalable compute cores, large GPIO pin count
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-09-29 07:52 +1300 |
| Message-ID | <f34ummF6c2hU3@mid.individual.net> |
| In reply to | #120466 |
On 09/29/17 07:05 AM, bartc wrote:> > My attitude is this: > > You have a language L, and a compiler CC. > > To compile program P, you should just be able to do: > > CC P > > And it will tell you if anything is wrong with P. It should JUST WORK. > > Apparently C doesn't fit into that ideology; to get to that point > requires a lot more work. Dozens of options need to be added to report > even the most blatant errors. Some compilers do. The Sun/Oracle compiler I use tries to be compliant to the current standard in default mode. This has been a pain in the arse when porting rubbish code from Linux! > So, now what? Clearly just piling on options doesn't work. Were all > applications created with a particular set of options, and everyone has > to use exactly the same? > > Or is possible that no one else, outside the pedants in this group, > bother with any but the default options so all these issues get through? The large project I am working on uses a variety of compilers and a large set of warnings (with -Werror). We basically turn the warning volume up to 10 and selectively disable warnings generated by old or third party code we don't want to fix. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-09-28 11:59 -0700 |
| Message-ID | <26883832-6a4e-4781-b40f-76e0563ac8a4@googlegroups.com> |
| In reply to | #120466 |
On Thursday, September 28, 2017 at 2:05:23 PM UTC-4, Bart wrote: ... > My attitude is this: > > You have a language L, and a compiler CC. > > To compile program P, you should just be able to do: > > CC P Fine - complain the MANY different compiler vendors who decided not to make it work that way. Don't complain about it here. > And it will tell you if anything is wrong with P. It should JUST WORK. > > Apparently C doesn't fit into that ideology; to get to that point > requires a lot more work. Dozens of options need to be added to report > even the most blatant errors. I only use 7 options, not dozens. > And options which which will only work on Gcc (and Clang) as compilers > all have their own interpretations of the language and their own options. > > FWIW I tried: > > -Wstrict-prototypes -Wmissing-prototypes -Wextra -Wall -Wpedantic > -std=c11 > > and on pretty much every source file I tried on, across a dozen > projects, it had warnings streaming up the screen. If there was one > pertinent warning in that lot, I would never see it. I don't use -Wextra, for precisely that reason. > And if I'd used -Werror as has been suggested, then nothing would ever > compile. (Only LUA sources were 'clean', on the couple of test files I > tried.) I don't use -Werror, and I also don't complain that some messages are warnings rather than error messages. I examine all messages, whether warnings or errors, to determine whether there's an actual problem. If there isn't, I ignore the warning. If it's actually an error, I figure out how to disable the error message (if necessary, by using a different compiler that doesn't consider valid code to be an error). > So, now what? Clearly just piling on options doesn't work. Were all > applications created with a particular set of options, and everyone has > to use exactly the same? They wouldn't be options if everyone was supposed to use the same. You use the options that correspond to what you want the compiler to do. When someone else wants the compiler to do something differently, they choose the options that make it do what they want, instead. > Or is possible that no one else, outside the pedants in this group, > bother with any but the default options so all these issues get through? There's only a few cases where I know what options other people use, but most such cases fall into two general categories: programmers who write lousy code, and who keep warnings turned off so they can go around believing that their code is fine, and programmers who write good but imperfect code, who set warning levels high so they have a decent chance of being warned about some, at least, of the imperfections. Those programmers tend to be relatively sane, and therefore don't have the ridiculous expectation that the compiler can detect every problem that their code might have. > I can use just '-std=c11', and still all these ancient practices such as > missing prototypes get through unchallenged. You would expect that > specifying the desired standard would be an excellent opportunity to > change all the default options to suit modern working practices. I agree with you about that. Complain to the vendor. > My suggestion has always been that compilers should work in the > strictest, safest mode so that everything is trapped, and to require > options to by-pass that. > > And yet, still you persist with the personal attacks. Is it possible > that Bart might actually have a point but no one is willing to admit that? You appear to be unable to understand the simple fact that most of the popular compilers DON"T WORK THAT WAY. I can understand feeling that they should work differently. However, the fact of the matter is that they don't conform to any particular version of the C standard unless you tell them to do so. They don't produce all of the diagnostics you'd like them to produce unless you tell them to do so. The rational response to this fact would be to tell the compiler what it is you want it to do, while complaining about the necessity of doing so to the vendor. You, instead, choose not to tell the compiler what to do, and then complain about the fact that it doesn't do what you didn't tell it to do, and you send those complaints to people who can't do anything to fix the matter. Does that seem at all rational to you? To me, you seem insane: "Doing the same thing over and over again, and expecting to get a different result." And if you feel that's getting excessively personal, keep in mind that, as far as I can tell, there's exactly one person suffering from this particular problem.
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web