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 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-27 11:10 -0700 |
| Message-ID | <lnd16cypug.fsf@kst-u.example.com> |
| In reply to | #120391 |
supercat@casperkitty.com writes:
> On Wednesday, September 27, 2017 at 12:47:42 PM UTC-5, Ben Bacarisse wrote:
>> There is no "special 'void' value" so that explanation can only be
>> confusing (to people who don't know). "void functions" are simply C's
>> way of writing a subroutine or a procedure. They return no value.
>
> Failure to recognize the concept of empty objects can add a lot of needless
> complexity to a language. Treating empty objects the same way as any others
> can be a useful simplifying abstraction in many cases, though many language
> specs are written in a way that makes it needlessly leaky.
What is an "empty object"? We were discussing types and values, not
objects. (If you're mixing up the concepts of values and objects,
please unmix them before replying.)
--
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:10 +0200 |
| Message-ID | <oqi7a0$91b$1@dont-email.me> |
| In reply to | #120391 |
On 27/09/17 19:52, supercat@casperkitty.com wrote: > On Wednesday, September 27, 2017 at 12:47:42 PM UTC-5, Ben Bacarisse wrote: >> There is no "special 'void' value" so that explanation can only be >> confusing (to people who don't know). "void functions" are simply C's >> way of writing a subroutine or a procedure. They return no value. > > Failure to recognize the concept of empty objects can add a lot of needless > complexity to a language. Treating empty objects the same way as any others > can be a useful simplifying abstraction in many cases, though many language > specs are written in a way that makes it needlessly leaky. > "void" is used to mean "no return type" and "no parameters" for functions, and as an empty incomplete type. It is like the empty set - there are no values of type "void". (You can make expressions to void type - they have no value.) Empty objects would be a different matter - like members of a struct type with no fields. That is not allowed in standard C. Such empty objects carry no information except their type. In C, there isn't a lot you can do with that type information - so there is no particular use of such objects. In languages that use types more, such as C++, they /are/ useful.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-27 11:06 -0700 |
| Message-ID | <lnh8voyq2d.fsf@kst-u.example.com> |
| In reply to | #120384 |
bartc <bc@freeuk.com> writes:
> On 27/09/2017 17:15, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> On 26/09/17 13:28, Malcolm McLean wrote:
>> [...]
>>>> But you're using a subroutine call.
>>>
>>> C does not have subroutines. I think you mean a function call?
>>
>> C has subroutines. It calls them "functions".
>
> It emulates subroutines, which are procedures that don't return values,
> with functions returning a special 'void' value.
C has subroutines. It calls them "functions". There are more details
than that, but they don't change the fundamental point.
> And it doesn't work that well because, if I try and return a value from
> such a function, half the compilers I used either say nothing, or give a
> warning.
>
> It should absolutely be a hard error.
>
> (Unless someone can explain to me how such a thing can be just a warning.)
A return statement with an expression in a void function is a constraint
violation, requiring a diagnostic. Any diagnostic (other than for a
#error directive) can be "just a warning". That's how.
I agree that this one *should* be a "hard error", but the standard
doesn't require compilers to treat it as one. I personally wish
it did.
Given:
void func(void) {
return 42;
}
a conforming compiler may issue either a fatal error or a non-fatal
warning. A compiler that does neither is non-conforming -- and we
already know that there are plenty of non-conforming compilers out
there.
gcc, for example, issues a non-fatal warning by default, but it can
easily be invoked in a mode (using "-pedantic-errors") that makes
it a fatal error.
The fact that required diagnostics need not be fatal has been
discussed here repeatedly. I suggest you save or bookmark this
answer so you don't have to ask again.
--
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 | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-27 20:01 +0100 |
| Message-ID | <QzSyB.796199$uh.155860@fx28.am4> |
| In reply to | #120394 |
On 27/09/2017 19:06, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > gcc, for example, issues a non-fatal warning by default, but it can > easily be invoked in a mode (using "-pedantic-errors") that makes > it a fatal error. > > The fact that required diagnostics need not be fatal has been > discussed here repeatedly. I suggest you save or bookmark this > answer so you don't have to ask again. What's that go to do anything? You contracted someone by saying C does has 'subroutines' in the form of functions. I said those don't count, partly because the language allows a compiler to not implement them rigorously. Therefore C doesn't properly enforce the concept of subroutines; it makes it optional. Does C have subroutines? It depends... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-27 12:26 -0700 |
| Message-ID | <ln1smsymbr.fsf@kst-u.example.com> |
| In reply to | #120400 |
bartc <bc@freeuk.com> writes:
> On 27/09/2017 19:06, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>
>> gcc, for example, issues a non-fatal warning by default, but it can
>> easily be invoked in a mode (using "-pedantic-errors") that makes
>> it a fatal error.
>>
>> The fact that required diagnostics need not be fatal has been
>> discussed here repeatedly. I suggest you save or bookmark this
>> answer so you don't have to ask again.
>
> What's that go to do anything?
It's a direct answer to a question that you asked, and have now snipped.
Here's what you wrote:
It should absolutely be a hard error.
(Unless someone can explain to me how such a thing can be just a
warning.)
I took that last parenthesized sentence fragment as a question.
I explained how such a thing can be just a warning. That's what
it's got to do with anything.
> You contracted someone by saying C does has 'subroutines' in the form of
> functions.
Contradicted, but yes.
> I said those don't count, partly because the language allows a compiler
> to not implement them rigorously.
>
> Therefore C doesn't properly enforce the concept of subroutines; it
> makes it optional.
>
> Does C have subroutines? It depends...
If I understand you correctly, you think that the fact that a
conforming C compiler need not treat `return 42;` in a void function
as a fatal error means that a void function is not a subroutine.
I find that absurd.
I can't wait to see where the goalposts end up on your next followup.
--
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 | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-27 20:38 +0100 |
| Message-ID | <C6TyB.1386148$py6.1076342@fx22.am4> |
| In reply to | #120403 |
On 27/09/2017 20:26, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> Does C have subroutines? It depends... > > If I understand you correctly, you think that the fact that a > conforming C compiler need not treat `return 42;` in a void function > as a fatal error means that a void function is not a subroutine. > I find that absurd. > > I can't wait to see where the goalposts end up on your next followup. I thought I'd made my position clear: C's subroutines are only lookalikes and only mildly enforced by the language. If you had to translate code using subroutines from another language to C, then yes it's simple enough, but it is by making functions behave like subroutines. Maybe it's a subtle difference for you, but for me the distinction is important. (And internally, my implementations treat non-void functions and void functions quite differently.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-09-27 13:00 -0700 |
| Message-ID | <6308c8a5-6a1e-4667-bac4-1cdaf18e7e55@googlegroups.com> |
| In reply to | #120404 |
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. > (And internally, my implementations treat non-void functions and void > functions quite differently.) Good - that's precisely what it's supposed to do (depending upon what you mean by "differently"). Does your implementation treat void functions any differently from the way it would treat subroutines, if C were modified in whatever way would be required to make you admit that it has subroutines? If so, what are those differences?
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-27 21:54 +0100 |
| Message-ID | <ueUyB.1549783$WI6.1384739@fx30.am4> |
| In reply to | #120407 |
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. 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: 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 non-C ERROR Return with no value seen in a Function: C Ignored or warning non-C ERROR Run into end of a Function: C Ignored or warning non-C ERROR Appear in ?: expression, example x?y:Subroutine(); : C Ignored (assuming at statement/expr level) 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. 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! -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-27 14:12 -0700 |
| Message-ID | <f149ecf5-7994-4ba7-983d-b76786b1bf5c@googlegroups.com> |
| In reply to | #120408 |
On Wednesday, September 27, 2017 at 3:54:59 PM UTC-5, Bart wrote: > 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. > > Anything except admit that the language should been far more explicit! The authors of the Standard wanted to avoid doing anything that would forbid conforming compilers from processing any existing useful programs, even if those programs would make use of features or guarantees not covered by the Standard. Allowing a compiler to yield a diagnostic but then execute a program anyway avoided any need to break the existing programs.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-09-27 14:34 -0700 |
| Message-ID | <03c7177e-47fd-4300-96e1-5e702dc377dc@googlegroups.com> |
| In reply to | #120408 |
On Wednesday, September 27, 2017 at 4:54:59 PM UTC-4, Bart wrote: ... > 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. > > Anything except admit that the language should been far more explicit! Making the language more explicit would not have any effect on non-conforming implementations. They would continue to fail to conform, ignoring the more explicit wording. A compiler that is non-conforming by default, but can be fully conforming if you turn on the right options (which describes virtually all C compilers), will continue to not conform, so long as you continue refusing to learn which options those are. I was very interested in seeing your answer to a question I asked which you've decided to snip. Is there any chance that I can convince you to answer it?: > > Does your implementation treat void functions any differently from the way > > it would treat subroutines, if C were modified in whatever way would be > > required to make you admit that it has subroutines? If so, what are those > > differences?
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-27 23:16 +0100 |
| Message-ID | <BqVyB.864067$sC5.392864@fx45.am4> |
| In reply to | #120410 |
On 27/09/2017 22:34, jameskuyper@verizon.net wrote: > On Wednesday, September 27, 2017 at 4:54:59 PM UTC-4, Bart wrote: > ... >> 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. >> >> Anything except admit that the language should been far more explicit! > > Making the language more explicit would not have any effect on non-conforming implementations. They would continue to fail to conform, ignoring the more explicit wording. Unusually, we're not talking about a proposed change to C this time. If function and subroutines had been treated more differently from the start, then we wouldn't be in a situation where implementations can do what they like, because they language allows them to do what they like. And what the language allows is to blur the distinction between function and subroutine. I think the only reliable hard error is a type error and that's only because 'void' can't be used in an expression with other values. But it CAN be used with certain operators like ?: and comma. For example, this is legal when fn() is a void function: x = A[fn(), i]; A subroutine call in the middle of an expression, WT...? A compiler that is non-conforming by default, but can be fully conforming if you turn on the right options (which describes virtually all C compilers), will continue to not conform, so long as you continue refusing to learn which options those are. > > I was very interested in seeing your answer to a question I asked which you've decided to snip. Is there any chance that I can convince you to answer it?: > >>> Does your implementation treat void functions any differently from the way >>> it would treat subroutines, if C were modified in whatever way would be >>> required to make you admit that it has subroutines? If so, what are those >>> differences? Once converted to internal representation then yes it can work with 'functions' and 'subroutines'. Or as much as existing code allows it to: if a missing return value is commonly tolerated, then I have to do the same. But look at that list that you snipped, to which you can add comma operators. If you had to have a poll as to whether C's Functions and Subroutines were like other languages' Functions and Subroutines, then those are the facts. A language with proper separation of functions and subroutines prohibits certain things that C is not bothered about, but IMO makes for clearer thinking about what that code does. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-09-27 16:09 -0700 |
| Message-ID | <81bddf68-70c6-4c85-a218-19dcbfb9249e@googlegroups.com> |
| In reply to | #120412 |
On Wednesday, September 27, 2017 at 6:16:09 PM UTC-4, Bart wrote: > On 27/09/2017 22:34, jameskuyper@verizon.net wrote: > > On Wednesday, September 27, 2017 at 4:54:59 PM UTC-4, Bart wrote: > > ... > >> 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. > >> > >> Anything except admit that the language should been far more explicit! > > > > Making the language more explicit would not have any effect on non-conforming implementations. They would continue to fail to conform, ignoring the more explicit wording. > > 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? > If function and subroutines had been treated more differently from the > start, then we wouldn't be in a situation where implementations can do > what they like, because they language allows them to do what they like. 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. > And what the language allows is to blur the distinction between function > and subroutine. No, it completely ignores that distinction. Instead, it makes a distinction between functions which return a value, and functions which do not. The earliest versions of the language didn't even make that distinction - all functions had a return type; some returned a value, some didn't. You needed to know which functions were in each category, because things could go badly wrong if you used the return value of a function that hadn't actually returned one. When it was finally realized that it would be a good idea to make the fact that a function didn't return a value part of the function declaration, a need to retain backwards compatibility resulted in the situation you're complaining about. Returning a value from a function declared as not returning a value can be a constraint violation, because functions so declared could not possibly be in code that existed before that change. Failing to return a value from a function that is declared as having a return value could not be treated that way because pre-existing code often did exactly that - any function that nowadays would be declared void was implemented in precisely that fashion in pre-standard C. Any decent modern compiler should warn about it, but is not entitled to refuse to compile such code - and that's the way it has to be as long as backwards compatibility is an issue the committee cares about. Both kinds of functions qualify as subroutines as far as the Wikipedia definition I quoted earlier is concerned. I don't really care how you choose to distinguish them. ... > > I was very interested in seeing your answer to a question I asked which you've decided to snip. Is there any chance that I can convince you to answer it?: > > > >>> Does your implementation treat void functions any differently from the way > >>> it would treat subroutines, if C were modified in whatever way would be > >>> required to make you admit that it has subroutines? If so, what are those > >>> differences? > > Once converted to internal representation then yes it can work with > 'functions' and 'subroutines'. Or as much as existing code allows it to: > if a missing return value is commonly tolerated, then I have to do the same. That question was, very specifically, about void functions, and only about void functions. Missing return values are mandatory in that case, not merely tolerated.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-28 01:12 +0100 |
| Message-ID | <w7XyB.1061513$LJ4.683762@fx37.am4> |
| In reply to | #120413 |
On 28/09/2017 00:09, jameskuyper@verizon.net wrote:
> On Wednesday, September 27, 2017 at 6:16:09 PM UTC-4, Bart wrote:
>> On 27/09/2017 22:34, jameskuyper@verizon.net wrote:
>>> On Wednesday, September 27, 2017 at 4:54:59 PM UTC-4, Bart wrote:
>>> ...
>>>> 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.
>>>>
>>>> Anything except admit that the language should been far more explicit!
>>>
>>> Making the language more explicit would not have any effect on non-conforming implementations. They would continue to fail to conform, ignoring the more explicit wording.
>>
>> 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. Actually at
one time I used these macros:
#define proc void
#define function
Then I could write this (which also makes source tools trivial to
implement):
proc f(void);
function int g(void);
But of course this still is just pretending.
>
>> If function and subroutines had been treated more differently from the
>> start, then we wouldn't be in a situation where implementations can do
>> what they like, because they language allows them to do what they like.
>
> 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? 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? That and the 100 other
things it doesn't otherwise take seriously?
>> And what the language allows is to blur the distinction between function
>> and subroutine.
>
> No, it completely ignores that distinction. Instead, it makes a distinction
> between functions which return a value, and functions which do not.
Subroutines don't have any concept of returning anything. Functions
always return a value.
>> Once converted to internal representation then yes it can work with
>> 'functions' and 'subroutines'. Or as much as existing code allows it to:
>> if a missing return value is commonly tolerated, then I have to do the same.
>
> That question was, very specifically, about void functions, and only about void
> functions. Missing return values are mandatory in that case, not merely
> tolerated.
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.
So here, I'm treating the two kinds of functions more distinctly, more
like actual Function and Subroutine, that typical C compilers. And you
get a real benefit from doing so. I immediately get told the code is
wrong without having to point a gun at the compiler's head, or needing
to be aware of the 150 fatal errors that by default are treated as warnings.
So, yes, void functions can do the job of Subroutine, but the
combination of lacking visual distinction, of using the same 'function'
name for both features, of a lacklustre approach to enforcing return
values on one and not allowing them on the other, or allowing void
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."
I'm done.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-28 02:03 +0100 |
| Message-ID | <87bmlvhbxa.fsf@bsb.me.uk> |
| In reply to | #120414 |
bartc <bc@freeuk.com> writes:
<snip>
> 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?
Yes, the command-line options matter (gcc -x f77 is not even trying to
be a C compiler). If you don't say what you want, you get whatever
defaults the gcc people decided on. You know this from all the other
times its cropped up.
> If I give it -std=c99,
> it's the same. Only when I give it all this:
>
> -std=c11 -Wextra -Wall -Wpedantic
As it happens, I get a warning from the second line with no gcc options
at all. But that's the trouble with not saying what you want -- you
really don't know what you'll get from one release to another. But you
must get a diagnostic when you ask for -std=c11 -Wpedantic (the other
warning options are your choice).
> then I get warnings on both. But still only warnings!
Could we make this the last time you act surprised that (a) gcc does not
implement standard C by default, and (b) you only get warned about some
things? Maybe you could pin a note to your computer: "gcc is not a
confirming C compiler by default"?
<snip>
> My compiler says this:
>
> "Missing return statement in function"
(and you explain that compilation stops here)
That's your choice, but it makes your compiler non-conforming. I think
you've said before that you are not aiming for a conforming compiler,
but rather for one that does what you think is useful. Since it's your
compiler for your own use, there's nothing wrong with that.
<snip>
> "It [C] emulates subroutines, which are procedures that don't return
> values, with functions returning a special 'void' value."
That's still wrong.
> I'm done.
OK, but you have not answered James's question. I'll leave it to him to
ask again if he thinks it's worth while persevering.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-09-28 17:31 +1300 |
| Message-ID | <f33c86F6c2hU1@mid.individual.net> |
| In reply to | #120415 |
On 09/28/17 02:03 PM, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>
> <snip>
>> 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?
>
> Yes, the command-line options matter (gcc -x f77 is not even trying to
> be a C compiler). If you don't say what you want, you get whatever
> defaults the gcc people decided on. You know this from all the other
> times its cropped up.
>
>> If I give it -std=c99,
>> it's the same. Only when I give it all this:
>>
>> -std=c11 -Wextra -Wall -Wpedantic
>
> As it happens, I get a warning from the second line with no gcc options
> at all. But that's the trouble with not saying what you want -- you
> really don't know what you'll get from one release to another. But you
> must get a diagnostic when you ask for -std=c11 -Wpedantic (the other
> warning options are your choice).
>
>> then I get warnings on both. But still only warnings!
>
> Could we make this the last time you act surprised that (a) gcc does not
> implement standard C by default, and (b) you only get warned about some
> things? Maybe you could pin a note to your computer: "gcc is not a
> confirming C compiler by default"?
>
> <snip>
>> My compiler says this:
>>
>> "Missing return statement in function"
>
> (and you explain that compilation stops here)
>
> That's your choice, but it makes your compiler non-conforming.
Does it?
"Missing return statement in function" is a diagnostic, isn't stopping
compilation a viable option?
If I try my machine's compiler, it does much the same:
cc x.c
"x.c", line 2: void function cannot return value
cc: acomp failed for x.c
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-28 09:55 +0200 |
| Message-ID | <oqi9tl$ome$1@dont-email.me> |
| In reply to | #120421 |
On 28/09/17 06:31, Ian Collins wrote:
> On 09/28/17 02:03 PM, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>>
>> <snip>
>>> 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?
>>
>> Yes, the command-line options matter (gcc -x f77 is not even trying to
>> be a C compiler). If you don't say what you want, you get whatever
>> defaults the gcc people decided on. You know this from all the other
>> times its cropped up.
>>
>>> If I give it -std=c99,
>>> it's the same. Only when I give it all this:
>>>
>>> -std=c11 -Wextra -Wall -Wpedantic
>>
>> As it happens, I get a warning from the second line with no gcc options
>> at all. But that's the trouble with not saying what you want -- you
>> really don't know what you'll get from one release to another. But you
>> must get a diagnostic when you ask for -std=c11 -Wpedantic (the other
>> warning options are your choice).
>>
>>> then I get warnings on both. But still only warnings!
>>
>> Could we make this the last time you act surprised that (a) gcc does not
>> implement standard C by default, and (b) you only get warned about some
>> things? Maybe you could pin a note to your computer: "gcc is not a
>> confirming C compiler by default"?
>>
>> <snip>
>>> My compiler says this:
>>>
>>> "Missing return statement in function"
>>
>> (and you explain that compilation stops here)
>>
>> That's your choice, but it makes your compiler non-conforming.
>
> Does it?
>
Yes - 6.9.1p12 says it is legal to run off the end of a non-void
function. Trying to use the value "returned" by such a run-off is
undefined behaviour.
> "Missing return statement in function" is a diagnostic, isn't stopping
> compilation a viable option?
Stopping after giving a required diagnostic is fine - stopping when
given legal code is not (in the context of conformance).
It's fine to be non-conforming by default, IMHO - especially in cases
like this. But it is important to know about such non-conformances.
>
> If I try my machine's compiler, it does much the same:
>
> cc x.c
> "x.c", line 2: void function cannot return value
> cc: acomp failed for x.c
>
Your compiler is conforming here - it allows line 1, which is bad but
allowed, and gives a diagnostic on line 2 which is not allowed.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-09-28 21:00 +1300 |
| Message-ID | <f33og4F6c2hU2@mid.individual.net> |
| In reply to | #120429 |
On 09/28/17 08:55 PM, David Brown wrote:
> On 28/09/17 06:31, Ian Collins wrote:
>> On 09/28/17 02:03 PM, Ben Bacarisse wrote:
>>> bartc <bc@freeuk.com> writes:
>>>
>>> <snip>
>>>> 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?
>>>
>>> Yes, the command-line options matter (gcc -x f77 is not even trying to
>>> be a C compiler). If you don't say what you want, you get whatever
>>> defaults the gcc people decided on. You know this from all the other
>>> times its cropped up.
>>>
>>>> If I give it -std=c99,
>>>> it's the same. Only when I give it all this:
>>>>
>>>> -std=c11 -Wextra -Wall -Wpedantic
>>>
>>> As it happens, I get a warning from the second line with no gcc options
>>> at all. But that's the trouble with not saying what you want -- you
>>> really don't know what you'll get from one release to another. But you
>>> must get a diagnostic when you ask for -std=c11 -Wpedantic (the other
>>> warning options are your choice).
>>>
>>>> then I get warnings on both. But still only warnings!
>>>
>>> Could we make this the last time you act surprised that (a) gcc does not
>>> implement standard C by default, and (b) you only get warned about some
>>> things? Maybe you could pin a note to your computer: "gcc is not a
>>> confirming C compiler by default"?
>>>
>>> <snip>
>>>> My compiler says this:
>>>>
>>>> "Missing return statement in function"
>>>
>>> (and you explain that compilation stops here)
>>>
>>> That's your choice, but it makes your compiler non-conforming.
>>
>> Does it?
>>
>
> Yes - 6.9.1p12 says it is legal to run off the end of a non-void
> function. Trying to use the value "returned" by such a run-off is
> undefined behaviour.
Ah, I missed the order of the two functions!
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-28 10:48 +0100 |
| Message-ID | <Nz3zB.975584$gM6.250093@fx03.am4> |
| In reply to | #120421 |
On 28/09/2017 05:31, Ian Collins wrote:
> On 09/28/17 02:03 PM, Ben Bacarisse wrote:
>> That's your choice, but it makes your compiler non-conforming.
>
> Does it?
>
> "Missing return statement in function" is a diagnostic, isn't stopping
> compilation a viable option?
With some types of errors it is quite possible to keep compiling and end
up with a list of such errors.
I choose to stop mainly because that's what I've always done. But also
because, since I usually fix errors one at a time, I might as well
report them one at a time. Compilation is instant and I don't need to
work in batch or overnight mode any more.
With some kinds of errors such as unresolved names (missing declarations
or mistyped identifiers), especially in a big block of fresh code, it
would be useful to have them reported as a list. Although it would still
need to abort at the end of the pass.
But I'm not sure that's possible with the C compiler, as the parsing,
name-resolving and type-checking passes are integrated into one pass; it
would be too messy.
>>> int fred(void) {}
>>> void bill(void) {return 123;}
(This example is a little confusing because it is actually the second
line that would be reported first [with my compiler], as a missing
return value is detected in the next pass. That latter check had been
disabled so I suspect it was necessary to tolerate such code in certain
programs.)
> If I try my machine's compiler, it does much the same:
>
> cc x.c
> "x.c", line 2: void function cannot return value
> cc: acomp failed for x.c
Is 'cc' a compiler driver? Whether it fails depends on whether that is
an error or warning; it doesn't say.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-28 13:20 +0200 |
| Message-ID | <oqiltk$7aa$1@dont-email.me> |
| In reply to | #120435 |
On 28/09/17 11:48, bartc wrote:
> On 28/09/2017 05:31, Ian Collins wrote:
>> On 09/28/17 02:03 PM, Ben Bacarisse wrote:
>
>>> That's your choice, but it makes your compiler non-conforming.
>>
>> Does it?
>>
>> "Missing return statement in function" is a diagnostic, isn't stopping
>> compilation a viable option?
>
> With some types of errors it is quite possible to keep compiling and end
> up with a list of such errors.
>
> I choose to stop mainly because that's what I've always done. But also
> because, since I usually fix errors one at a time, I might as well
> report them one at a time. Compilation is instant and I don't need to
> work in batch or overnight mode any more.
>
That is a perfectly reasonable choice. It is not the only possibility -
some people prefer other choices. I use an IDE that highlights compiler
errors and warnings, updated whenever the compiler runs, and I find it
useful to have all the errors and warnings for a compiler run to be
shown. It might be that I will fix them in a different order than the
compiler had generated them. (I also often continue building other
files, because I might pick a different order to fix the files.)
On the other hand, stopping after the first error is an easy way to
avoid an avalanche of error messages caused by a single mistake in the
code.
> With some kinds of errors such as unresolved names (missing declarations
> or mistyped identifiers), especially in a big block of fresh code, it
> would be useful to have them reported as a list. Although it would still
> need to abort at the end of the pass.
>
> But I'm not sure that's possible with the C compiler, as the parsing,
> name-resolving and type-checking passes are integrated into one pass; it
> would be too messy.
>
>>>> int fred(void) {}
>>>> void bill(void) {return 123;}
>
> (This example is a little confusing because it is actually the second
> line that would be reported first [with my compiler], as a missing
> return value is detected in the next pass. That latter check had been
> disabled so I suspect it was necessary to tolerate such code in certain
> programs.)
>
>> If I try my machine's compiler, it does much the same:
>>
>> cc x.c
>> "x.c", line 2: void function cannot return value
>> cc: acomp failed for x.c
>
> Is 'cc' a compiler driver? Whether it fails depends on whether that is
> an error or warning; it doesn't say.
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-28 11:29 +0100 |
| Message-ID | <874lrnglqb.fsf@bsb.me.uk> |
| In reply to | #120421 |
Ian Collins <ian-news@hotmail.com> writes:
> On 09/28/17 02:03 PM, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
<snip>
>>> int fred(void) {}
>>> void bill(void) {return 123;}
<snip>
>>> My compiler says this:
>>>
>>> "Missing return statement in function"
>>
>> (and you explain that compilation stops here)
>>
>> That's your choice, but it makes your compiler non-conforming.
>
> Does it?
>
> "Missing return statement in function" is a diagnostic, isn't stopping
> compilation a viable option?
Not if the translation unit is otherwise valid. A file containing just
that first line should be translated. If the compiler can prove that
every run of the overall program calls fred and uses the returned value,
then it could reject the program but that's not the case here.
> If I try my machine's compiler, it does much the same:
>
> cc x.c
> "x.c", line 2: void function cannot return value
> cc: acomp failed for x.c
That's the other line and, being a constraint violation, it is fine to
terminate compilation.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web