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 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-28 18:50 +0100 |
| Message-ID | <87zi9eg1bb.fsf@bsb.me.uk> |
| In reply to | #120456 |
bartc <bc@freeuk.com> writes:
<snip>
> 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,
That's a bit vague. It's not a complete program for one thing, but I
don't think there is a way to complete it without it being undefined by
C. However, one of the C's strengths is the ability to exploit
undefined behaviour in useful ways, some of whohc might make that code
"right" (for the practical programmer).
For example, what you describe here as "clearly not right" is how I
might test an assembler routine with the external name "fn". Sure, it's
UB (as far as C in concerned) but the implementation may guarantee that
I can link this translation unit with one written in some other language
that defines "fn".
This is not to say you don't have a point, just that your example does
not make it particularly well. Had you included a definition of fn of
just said that it's undefined by C's definition it would have been clear
that your are pointing out how C compilers sometimes miss opportunities
to report errors.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-28 19:47 +0100 |
| Message-ID | <wtbzB.1314463$zs1.567806@fx15.am4> |
| In reply to | #120464 |
On 28/09/2017 18:50, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
> <snip>
>> 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,
>
> That's a bit vague. It's not a complete program for one thing, but I
> don't think there is a way to complete it without it being undefined by
> C.
...
> This is not to say you don't have a point, just that your example does
> not make it particularly well. Had you included a definition of fn of
> just said that it's undefined by C's definition it would have been clear
> that your are pointing out how C compilers sometimes miss opportunities
> to report errors.
I tested with this definition of fn() in another module:
void fn(int a) {}
In case it could detect something at link time. It didn't.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-28 21:57 +0200 |
| Message-ID | <oqjk7g$h3p$1@dont-email.me> |
| In reply to | #120456 |
On 28/09/17 18:39, bartc 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.
I personally don't make much use of ?:, and definitely not in cases
where it is just a compacted replacement for "if". But I don't care
much about whether /you/ use it or not. I am not planning on arguing
whether it is better to use "if" or ?:, I was merely point out when it
was being used correctly.
>
> 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.
I suspect that it is extremely rare that people write code with the
intention of appearing cryptic. That might be a side-effect of the way
they write the code, but I don't expect it to be the reason for writing
code that way. Remember that what is clear and what is cryptic is very
subjective.
>
>>> 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.)
You have told the compiler you have a function that can take arguments
of any type - and then you call that function with a variety of
arguments. Is the compiler supposed to guess that you don't know what
you are doing? To me, it is /not/ clear that the code you wrote is not
right - nor what the correct version might be. It is only clear that
you have a poor coding style and that if you had used a sensible
header/source style then mistakes with incorrect function declarations
are very difficult to make.
>
> 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.
If /you/ don't know what is lurking in your 100,000 line project, then
you have much bigger problems than compiler options.
>
> So, what are the options? Note that -Werror isn't foolproof because I
> used it above and it made no difference.
-Werror is not a magic flag that asks the compiler to find all your bugs
for you. Compiler warnings are a tool that help spot some kinds of
mistakes, catch some typos and small errors, and help enforce some style
rules.
>
> 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?
You are forever hanging "kick me" signs on your back. You do it
yourself, again and again. You've done it again here - by ignoring the
/many/ times in which I have said there are things that I would have
preferred be different in the C language and in the compilers I use.
Look at the last few posts in this thread - you will see several cases
when I said I agreed with you about what would be better defaults or
rules. But no, you would rather moan about how everyone is against you
than actually /read/ what people write.
>
> Only DMC reports an error in the above.
It is not an error, so why should it?
> 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!
And they could all be right.
>
> Under what circumstances would a declaration like:
>
> void fn();
>
> without listing parameter types be used anyway?
I don't think you can legally define a matching function fn() in
standard C. I am not an expert on variable argument functions. But it
is certainly easy to imagine how such a function could be written to
work (even if it cannot be done in C). You could have a function that
has a static "stepNo" variable starting at 0 and incrementing for each
call. On the first call, it interprets the parameter as an integer, and
prints it out. On the second call, it interprets the parameter as a
double and prints it out. And so on.
I can't think where this might be a good idea, but C compilers are not
judgemental about that.
>
>> 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.
>
This is no more and no less than a matter of familiarity and practice.
People who have done a lot of C programming then try Pascal find it
annoying that they have to use ":=" all the time, and write "x : int;"
instead of "int x;". And people who have done a lot of Pascal and then
try C find exactly the opposite. Get used to it - or accept that you
will always find C slightly awkward. Either way, it is /your/ problem -
no one can force you to be comfortable with the language. And there
certainly is nothing special or difficult about the way C does things
here - it is merely a little different from the way you have picked for
your own languages.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-09-28 16:14 -0400 |
| Message-ID | <8ef18f8f-fe02-4da5-b23e-76a1f2cb3448@verizon.net> |
| In reply to | #120485 |
On 2017-09-28 15:57, David Brown wrote:
> On 28/09/17 18:39, bartc wrote:
...
>> OK, I understand. If I write this:
>>
>> int main(void) {
>> int a;
>> void fn();
>>
>> fn(100);
>> fn(200.0);
>> fn("Hello, World!");
>> fn(&a);
>> }
...
> you are doing? To me, it is /not/ clear that the code you wrote is not
> right - nor what the correct version might be.
At least three of the calls to fn() must have undefined behavior - which
call has defined behavior depends upon how fn() is defined. It could
trivially be defined in a way that gives all four calls undefined behavior.
>> Under what circumstances would a declaration like:
>>
>> void fn();
>>
>> without listing parameter types be used anyway?
>
> I don't think you can legally define a matching function fn() in
> standard C.
It's only the calls to fn() in main() above that are problematic. The
function declaration itself isn't a problem. Defining a function that
can be called with defined behavior by using such a declaration is trivial:
void fn(int i)
{
printf("%d\n", i);
};
However, with that definition, only the first of the four calls to fn()
above has defined behavior.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-28 13:17 -0700 |
| Message-ID | <2cb547cb-391c-4081-95ac-46bf672c6c23@googlegroups.com> |
| In reply to | #120485 |
On Thursday, September 28, 2017 at 2:57:43 PM UTC-5, David Brown wrote:
> I don't think you can legally define a matching function fn() in
> standard C. I am not an expert on variable argument functions. But it
> is certainly easy to imagine how such a function could be written to
> work (even if it cannot be done in C). You could have a function that
> has a static "stepNo" variable starting at 0 and incrementing for each
> call. On the first call, it interprets the parameter as an integer, and
> prints it out. On the second call, it interprets the parameter as a
> double and prints it out. And so on.
Another situation which isn't applicable to function-address constants, but
would be applicable to function pointers, would be:
void foo(int mode, void (*func)())
{
if (mode == 1)
func(123);
else
func("Hey there!");
}
Actually, even with function-address constants, one might plausibly want
to build a pre-compiled library that can be used in conjunction with more
than one other library. In that situation, one might possibly want to
do something like:
void func();
void foo(void)
{
if (func_expects_long())
func(123L);
else
func(123);
}
Such behavior should be portable when used in conjunction with a
"func_expects_long()" which always returns zero if "func" expects
an "int" argument, and non-zero if it expects a "long". Testing at
run-time rather than build time might be less than ideal, but an
ability to use the same pre-compiled code in both usage scenarios
may justify the run-time expense.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-28 21:23 +0100 |
| Message-ID | <USczB.1196412$ik4.640179@fx38.am4> |
| In reply to | #120485 |
On 28/09/2017 20:57, David Brown wrote:
> On 28/09/17 18:39, bartc wrote:
>> 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.
>
> If /you/ don't know what is lurking in your 100,000 line project, then
> you have much bigger problems than compiler options.
So you know about every small subtle error within that 100Kloc projects,
enough that you don't really need a compiler to help you find it?
As on many previous occasions, I don't believe you.
One line accidentally gets deleted or commented out, and that line
happens to be:
return 1;
just before a final }. But you obviously will know all about it, even if
it was someone else who was responsible! Who needs a compiler for this
stuff when the programmer is a clairvoyant!
>> Only DMC reports an error in the above.
>
> It is not an error, so why should it?
Look at the code again. Are you seriously telling me that passing a
string to a function, then passing a float to the same function, is not
an error?
And (this is getting surreal), are you seriously telling me that you
might report a bug in DMC, even though it's the only one doing its job
properly?!
>> 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!
>
> And they could all be right.
So, programming is now a game of chance?!
There is no reason for a function declaration to not declare the number
and type of its parameters. But this is what you're suggesting:
* Declare a function, but omit its parameter list
* When you see a call, just assume that the number and parameters given
are correct
* When you see another call, assume /those/ are correct, even if they
are completely different
* But if they /are/ the same, that somehow increases probability they
are correct!
>
>>
>> Under what circumstances would a declaration like:
>>
>> void fn();
>>
>> without listing parameter types be used anyway?
>
> I don't think you can legally define a matching function fn() in
> standard C. I am not an expert on variable argument functions.
This is not a variadic function if that's what you mean.
But it
> is certainly easy to imagine how such a function could be written to
> work (even if it cannot be done in C). You could have a function that
> has a static "stepNo" variable starting at 0 and incrementing for each
> call. On the first call, it interprets the parameter as an integer, and
> prints it out. On the second call, it interprets the parameter as a
> double and prints it out. And so on.
On x64, the integer would be passed in rcx and the double in xmm0.
> I can't think where this might be a good idea, but C compilers are not
> judgemental about that.
Then you make that an exception. If the one person in a million really
wants to do that, force them to use a compiler option for that highly
unusual behaviour.
After all C compilers are judgemental about everything else. ("Unused
variable in function so and so". Yes, I know.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-28 13:55 -0700 |
| Message-ID | <ln3776wnk8.fsf@kst-u.example.com> |
| In reply to | #120489 |
bartc <bc@freeuk.com> writes:
> On 28/09/2017 20:57, David Brown wrote:
>> On 28/09/17 18:39, bartc wrote:
[...]
>>> Only DMC reports an error in the above.
>>
>> It is not an error, so why should it?
>
> Look at the code again. Are you seriously telling me that passing a
> string to a function, then passing a float to the same function, is not
> an error?
We are seriously telling you that the behavior is undefined, that
the C standard does not require a diagnostic, and that the problem is
easily avoided by consistent use of prototypes.
Do you not believe us?
--
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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-09-29 19:50 +0100 |
| Message-ID | <8760c1uyp0.fsf@gmail.com> |
| In reply to | #120494 |
Keith Thompson <kst-u@mib.org> writes: > We are seriously telling you that the behavior is undefined, that > the C standard does not require a diagnostic, and that the problem is > easily avoided by consistent use of prototypes. > > Do you not believe us? How many times are you going to ask such questions before you realise you are not going to get an answer? Another 100? Another 1000? What point are you trying to make, and who are you trying to make it to? YHBT. YHL. As we used to say.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-09-28 13:57 -0700 |
| Message-ID | <84abb778-0d46-4764-9c62-ab4fc932646c@googlegroups.com> |
| In reply to | #120489 |
On Thursday, September 28, 2017 at 4:23:24 PM UTC-4, Bart wrote: > On 28/09/2017 20:57, David Brown wrote: > > On 28/09/17 18:39, bartc wrote: ... > There is no reason for a function declaration to not declare the number > and type of its parameters. ... Having been written before the C language provided any way to do that, doesn't count as a reason? That's the only thing that justifies writing such code - and there's an awful lot of code to which that justification applies. > ... But this is what you're suggesting: > > * Declare a function, but omit its parameter list No one is suggesting that. It used to be the only way a C function could be declared, a problem that has since been fixed, but a need for backwards compatibility means that a conforming implementation of C must still accept such code. That doesn't mean that anyone should write such code, and no one has suggested otherwise. Any decent implementation of C can also be convinced to complain about such code, while accepting it. > * When you see a call, just assume that the number and parameters given > are correct No one has ever suggested that, even when it wasn't possible to declare the number and types of the parameters. The advice given was "Make sure the number and types of the parameters match the number and promoted types of the arguments." > * When you see another call, assume /those/ are correct, even if they > are completely different If two calls to the same function that must both occur during the same run of the program require the function to have two incompatible definitions, at least one of those calls is guaranteed to have undefined behavior. A compiler that noticed that this was the case would be entitled to abort compilation for that reason, but doing so would complicate the code that implements a feature than no one cares about. No modern sane programmer writes unprototyped function declarations except where strictly necessary (see my comment elsewhere about infinitely recursive prototypes). Therefore, I would not be surprised by any particular compiler failing to notice the problem. > * But if they /are/ the same, that somehow increases probability they > are correct! Well, that's true. Two separate calls to the same routine that both require it to have the same definition do provide extra evidence that the author expected it to have that definition, for the same reason that two different people who claim that Charlie's height was 93cm increases the likelihood Charlie does have that height. Assuming that the author is sane, that also increases the likelihood that it does indeed have that definition. However, code written after support for C90 became widely supported, that uses unprototyped function declarations, casts serious doubts on the author's sanity.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-28 23:18 +0200 |
| Message-ID | <oqjov1$mf7$1@dont-email.me> |
| In reply to | #120489 |
On 28/09/17 22:23, bartc wrote:
> On 28/09/2017 20:57, David Brown wrote:
>> On 28/09/17 18:39, bartc wrote:
>
>>> 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.
>>
>> If /you/ don't know what is lurking in your 100,000 line project, then
>> you have much bigger problems than compiler options.
>
> So you know about every small subtle error within that 100Kloc projects,
> enough that you don't really need a compiler to help you find it?
>
> As on many previous occasions, I don't believe you.
As on many previous occasions, you put words in my mouth and then
disagree with them.
When I write a 100,000 line project, I have a good idea what is in it
because I wrote it. If someone else has written bits of it, then I have
at least read the code unless it is from a known good, well-tested
source. And I don't just write 100,000 lines of C code, give it a shot
with a compiler with minimal checking, then ship it - there is a whole
process of checks, tests, reviews, etc. Compile-time warnings - with a
many more warning checks than have been discussed here - are part of it.
And my code does hit /any/ of the warnings I use - none are skipped.
(Third-party code might need some warnings disabled.)
Is my code bug free? No, bugs happen - but any that will easily be
caught by a compiler check /will/ be caught.
>
> One line accidentally gets deleted or commented out, and that line
> happens to be:
>
> return 1;
>
> just before a final }. But you obviously will know all about it, even if
> it was someone else who was responsible! Who needs a compiler for this
> stuff when the programmer is a clairvoyant!
I cannot fathom why you think I don't have the compiler check this sort
of thing. Unlike you, I know how to use my compilers - I read the
manual pages. I enable warnings for this sort of thing, set as errors.
>
>>> Only DMC reports an error in the above.
>>
>> It is not an error, so why should it?
>
> Look at the code again. Are you seriously telling me that passing a
> string to a function, then passing a float to the same function, is not
> an error?
It is almost certainly a daft idea - but I /think/ it is legal in C.
(James and Keith are sort of disagreeing with me here - though I still
think it could be possible using an externally defined function, perhaps
written in assembly. Note that "undefined behaviour" means "C does not
define its behaviour" - it does not preclude an assembly function with
clear deterministic behaviour that C does not know about.)
>
> And (this is getting surreal), are you seriously telling me that you
> might report a bug in DMC, even though it's the only one doing its job
> properly?!
>
If I am correct in thinking that the C code here is legal, then yes -
DMC is non-conforming by giving an error. Whether it is "doing its job
properly" depends on whether you think its job is to be a conforming C
compiler, or to be a mostly-conforming C compiler that gives extra
errors on highly dubious code. I would be quite happy with the later -
I use gcc options to make gcc into such a tool - but you should
understand if it is not conforming.
>>> 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!
>>
>> And they could all be right.
>
> So, programming is now a game of chance?!
No, it will depend on what the function "fn" does. I gave an example of
how a function "fn" might work in such a way that all calls to it here
are correct.
>
> There is no reason for a function declaration to not declare the number
> and type of its parameters.
I agree. Non-prototype function declarations are considered obsolete in
C - but they are still allowed for backwards compatibility. It would be
nice to see them removed entirely in future C standards.
> But this is what you're suggesting:
>
> * Declare a function, but omit its parameter list
>
> * When you see a call, just assume that the number and parameters given
> are correct
>
> * When you see another call, assume /those/ are correct, even if they
> are completely different
>
> * But if they /are/ the same, that somehow increases probability they
> are correct!
>
C originally had very little checking of the number and types of
parameters - there was a lot of "trust the programmer". Modern C gives
you a way to do more checking, by letting you provide function
prototypes with the number and type of the parameters. It still
supports the old ways, however - if you want to force these to be errors
you need to use compiler options to do so.
And again, because you seem to be working hard to misunderstand me, /I/
use these options, and the code you gave would give errors when I use a
compiler.
>>
>>>
>>> Under what circumstances would a declaration like:
>>>
>>> void fn();
>>>
>>> without listing parameter types be used anyway?
>>
>> I don't think you can legally define a matching function fn() in
>> standard C. I am not an expert on variable argument functions.
>
> This is not a variadic function if that's what you mean.
It is a function whose parameters are not specified at all. A variadic
function can support multiple parameters of different types, and can be
matched (at link time) to a function declaration whose parameters are
undeclared. But you can't define a variadic function in C without at
least one defined fixed parameter.
>
> But it
>> is certainly easy to imagine how such a function could be written to
>> work (even if it cannot be done in C). You could have a function that
>> has a static "stepNo" variable starting at 0 and incrementing for each
>> call. On the first call, it interprets the parameter as an integer,
>> and prints it out. On the second call, it interprets the parameter as
>> a double and prints it out. And so on.
>
> On x64, the integer would be passed in rcx and the double in xmm0.
That makes no difference whatsoever. Of course, the implementation in
assembly would have to know the ABI details.
>
>> I can't think where this might be a good idea, but C compilers are not
>> judgemental about that.
>
> Then you make that an exception. If the one person in a million really
> wants to do that, force them to use a compiler option for that highly
> unusual behaviour.
>
> After all C compilers are judgemental about everything else. ("Unused
> variable in function so and so". Yes, I know.)
>
They warn about things you ask them to warn about. If you don't want to
warn about unused variables, don't ask the compiler to tell you about
them. (I /do/ want the compiler to tell me such things - because an
unused local variable is either a temporary situation while writing a
function, or a mistake in the code.)
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-09-28 17:38 -0400 |
| Message-ID | <ffc6d5fb-13ed-6ee2-c8c8-67e6dfcf63ee@verizon.net> |
| In reply to | #120499 |
On 2017-09-28 17:18, David Brown wrote: > On 28/09/17 22:23, bartc wrote: ... >> Look at the code again. Are you seriously telling me that passing a >> string to a function, then passing a float to the same function, is not >> an error? > > It is almost certainly a daft idea - but I /think/ it is legal in C. > > (James and Keith are sort of disagreeing with me here - though I still > think it could be possible using an externally defined function, perhaps > written in assembly. Note that "undefined behaviour" means "C does not > define its behaviour" - it does not preclude an assembly function with > clear deterministic behaviour that C does not know about.) The behavior of a C program linked to anything (other than the C standard library) that is not written in C is undefined, "by the omission of any explicit definition of behavior" (4p6). supercat is, oddly enough, the one who has pointed out that there is a way to define fn() that allows the entire program to have defined behavior. There's a problem with two function calls that require the called function to have two different incompatible definitions, but only if both calls actually occur. ... >> And (this is getting surreal), are you seriously telling me that you >> might report a bug in DMC, even though it's the only one doing its job >> properly?! >> > > If I am correct in thinking that the C code here is legal, then yes - > DMC is non-conforming by giving an error. If Bartc's main() were linked to supercat's definition for fn(), the resulting program is strictly conforming - DMC is therefore required to accept it, even if it also generates a warning message. Since DMC didn't have access to the definition of fn(), it must assume that it is defined in a way that gives the entire program defined behavior. That can only be the case if fn() causes the program to terminate before the second call to fn(). As a result, a conforming implementation of C is allowed to optimize away the last three calls to fn() - a conclusion that would probably horrify supercat.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-28 15:54 -0700 |
| Message-ID | <7c49a43b-b21a-48da-9be0-c4642584f2ac@googlegroups.com> |
| In reply to | #120502 |
On Thursday, September 28, 2017 at 4:39:06 PM UTC-5, James R. Kuyper wrote: > Since DMC didn't > have access to the definition of fn(), it must assume that it is defined > in a way that gives the entire program defined behavior. One thing which appears to have changed philosophically between the days of C89 and today is that in cases where there would be only way a function could work while conforming to the Standard, that used to be regarded as sufficient to define the behavior. Under C89, if a function received two pointers from an unknown source, and behavior would be defined if they were members of the same union object (e.g. by the Common Initial Sequence guarantee), a compiler would have no reason to know or care about what kind of union object (if any) they were actually members of. Since there was only one way code could behave when given to pointers to things that might be union objects, there was no need to include explicit language to make the CIS guarantees apply to structure pointers even though the CIS guarantees are far more usefully applied to structure pointers than to union members.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-29 08:59 +0200 |
| Message-ID | <oqkr07$ats$1@dont-email.me> |
| In reply to | #120502 |
On 28/09/17 23:38, James R. Kuyper wrote: > On 2017-09-28 17:18, David Brown wrote: >> On 28/09/17 22:23, bartc wrote: > ... >>> Look at the code again. Are you seriously telling me that passing a >>> string to a function, then passing a float to the same function, is not >>> an error? >> >> It is almost certainly a daft idea - but I /think/ it is legal in C. >> >> (James and Keith are sort of disagreeing with me here - though I still >> think it could be possible using an externally defined function, perhaps >> written in assembly. Note that "undefined behaviour" means "C does not >> define its behaviour" - it does not preclude an assembly function with >> clear deterministic behaviour that C does not know about.) > > The behavior of a C program linked to anything (other than the C > standard library) that is not written in C is undefined, "by the > omission of any explicit definition of behavior" (4p6). Right. It is easy to think that "undefined behaviour" means bad code, non-determinism, Supercat's evil compiler authors, nasal daemons, and the rest - when it simply means "no behaviour defined by the C standard". Bart's code could be correct and well behaved - but (AFAICS) it could not have behaviour defined entirely by the C standards. > > supercat is, oddly enough, the one who has pointed out that there is a > way to define fn() that allows the entire program to have defined > behavior. There's a problem with two function calls that require the > called function to have two different incompatible definitions, but only > if both calls actually occur. > > ... >>> And (this is getting surreal), are you seriously telling me that you >>> might report a bug in DMC, even though it's the only one doing its job >>> properly?! >>> >> >> If I am correct in thinking that the C code here is legal, then yes - >> DMC is non-conforming by giving an error. > > If Bartc's main() were linked to supercat's definition for fn(), the > resulting program is strictly conforming - DMC is therefore required to > accept it, even if it also generates a warning message. Since DMC didn't > have access to the definition of fn(), it must assume that it is defined > in a way that gives the entire program defined behavior. That can only > be the case if fn() causes the program to terminate before the second > call to fn(). As a result, a conforming implementation of C is allowed > to optimize away the last three calls to fn() - a conclusion that would > probably horrify supercat. :-)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-28 14:43 -0700 |
| Message-ID | <lnpoaav6qw.fsf@kst-u.example.com> |
| In reply to | #120499 |
David Brown <david.brown@hesbynett.no> writes:
> On 28/09/17 22:23, bartc wrote:
>> On 28/09/2017 20:57, David Brown wrote:
[...]
>> Look at the code again. Are you seriously telling me that passing a
>> string to a function, then passing a float to the same function, is not
>> an error?
>
> It is almost certainly a daft idea - but I /think/ it is legal in C.
>
> (James and Keith are sort of disagreeing with me here - though I still
> think it could be possible using an externally defined function, perhaps
> written in assembly. Note that "undefined behaviour" means "C does not
> define its behaviour" - it does not preclude an assembly function with
> clear deterministic behaviour that C does not know about.)
I'm not exactly disagreeing with you. It depends on what you mean by
"legal". The C standard doesn't use that term.
The code in question (which declares a function with no prototype and
then calls it 4 times with inconsistent arguments) is certainly bad code
that would not pass a code review unless it was intended as a compiler
test case. It does not violate any syntax rule or constraint, but its
behavior is *probably* undefined. I can imagine its behavior in some
particular environment being useful. And as supercat correctly pointed
out, you can create a highly contrived definition of the fn() function
that avoids any undefined behavior, which I believe implies that a
conforming compiler may warn about it but may not reject it.
>> And (this is getting surreal), are you seriously telling me that you
>> might report a bug in DMC, even though it's the only one doing its job
>> properly?!
>>
>
> If I am correct in thinking that the C code here is legal, then yes -
> DMC is non-conforming by giving an error.
If "giving an error" means rejecting the code, then DMC is failing to
conform to the standard. That's not a problem unless it does so in a
mode in which it claims to be conforming. Even in that case, it's a
conformance bug, but not one that worries me greatly.
[...]
>>> I don't think you can legally define a matching function fn() in
>>> standard C. I am not an expert on variable argument functions.
>>
>> This is not a variadic function if that's what you mean.
>
> It is a function whose parameters are not specified at all.
The empty parentheses declare that it has a fixed but unspecified number
of parameters. It cannot be variadic (well, it can, but if it does the
behavior is undefined). For example, this:
int printf();
printf("Hello, world\n");
has undefined behavior. (Variadic functions might require special
argument passing methods. The compiler might need to know that a
function is variadic to be able to process a call correctly.)
Or it could work "correctly". That's one of the possible consequences
of undefined behavior.
> A variadic
> function can support multiple parameters of different types, and can be
> matched (at link time) to a function declaration whose parameters are
> undeclared. But you can't define a variadic function in C without at
> least one defined fixed parameter.
At link time, you can do pretty much anything you like; the only
available information about a function is its name. Which is why rules
for function calls are enforced 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-29 10:43 +0200 |
| Message-ID | <oql12p$gdn$1@dont-email.me> |
| In reply to | #120503 |
On 28/09/17 23:43, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 28/09/17 22:23, bartc wrote:
>>> On 28/09/2017 20:57, David Brown wrote:
> [...]
>>> Look at the code again. Are you seriously telling me that passing a
>>> string to a function, then passing a float to the same function, is not
>>> an error?
>>
>> It is almost certainly a daft idea - but I /think/ it is legal in C.
>>
>> (James and Keith are sort of disagreeing with me here - though I still
>> think it could be possible using an externally defined function, perhaps
>> written in assembly. Note that "undefined behaviour" means "C does not
>> define its behaviour" - it does not preclude an assembly function with
>> clear deterministic behaviour that C does not know about.)
>
> I'm not exactly disagreeing with you. It depends on what you mean by
> "legal". The C standard doesn't use that term.
I have often put "legal" in quotation marks, intentionally keeping it
vague because it is not a term in the C standard. I use "legal" to mean
no constraint violations, no syntax errors, no undefined behaviour (at
least within the code in view at the time), etc. I have been known to
be inaccurate about the exact reasons for something being incorrect C,
and so sometimes prefer to avoid the risk of confusion by using
imprecise terms like "legal" or "correct C".
>
> The code in question (which declares a function with no prototype and
> then calls it 4 times with inconsistent arguments) is certainly bad code
> that would not pass a code review unless it was intended as a compiler
> test case. It does not violate any syntax rule or constraint, but its
> behavior is *probably* undefined. I can imagine its behavior in some
> particular environment being useful. And as supercat correctly pointed
> out, you can create a highly contrived definition of the fn() function
> that avoids any undefined behavior, which I believe implies that a
> conforming compiler may warn about it but may not reject it.
I agree with all that. (Supercat is an expert at highly contrived code!)
>
>>> And (this is getting surreal), are you seriously telling me that you
>>> might report a bug in DMC, even though it's the only one doing its job
>>> properly?!
>>>
>>
>> If I am correct in thinking that the C code here is legal, then yes -
>> DMC is non-conforming by giving an error.
>
> If "giving an error" means rejecting the code, then DMC is failing to
> conform to the standard. That's not a problem unless it does so in a
> mode in which it claims to be conforming. Even in that case, it's a
> conformance bug, but not one that worries me greatly.
Agreed.
>
> [...]
>
>>>> I don't think you can legally define a matching function fn() in
>>>> standard C. I am not an expert on variable argument functions.
>>>
>>> This is not a variadic function if that's what you mean.
>>
>> It is a function whose parameters are not specified at all.
>
> The empty parentheses declare that it has a fixed but unspecified number
> of parameters. It cannot be variadic (well, it can, but if it does the
> behavior is undefined). For example, this:
>
> int printf();
> printf("Hello, world\n");
>
> has undefined behavior. (Variadic functions might require special
> argument passing methods. The compiler might need to know that a
> function is variadic to be able to process a call correctly.)
>
The function can't be a normal C variadic function - as you say, these
need to be declared properly to get argument passing correct. And C
requires that they have at least one fixed normal parameter (like the
format string in printf). But once you leave C and consider a function
"fn" written in assembly, it could happily work with any parameters
passed using whatever (implementation-dependent) calling convention is
used for different types - if it has another way of knowing how it
should interpret the parameter(s). The implementation of "fn" would be
undefined behaviour as far as C is concerned, but the /use/ of it could
be defined behaviour.
> Or it could work "correctly". That's one of the possible consequences
> of undefined behavior.
>
Yes.
>> A variadic
>> function can support multiple parameters of different types, and can be
>> matched (at link time) to a function declaration whose parameters are
>> undeclared. But you can't define a variadic function in C without at
>> least one defined fixed parameter.
>
> At link time, you can do pretty much anything you like; the only
> available information about a function is its name. Which is why rules
> for function calls are enforced at compile time.
>
> [...]
>
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-29 07:43 -0700 |
| Message-ID | <e9e450ad-7cca-4890-abc8-8c32d147ae52@googlegroups.com> |
| In reply to | #120527 |
On Friday, September 29, 2017 at 3:43:21 AM UTC-5, David Brown wrote:
> The function can't be a normal C variadic function - as you say, these
> need to be declared properly to get argument passing correct.
Dennis Ritchie's 1974 C compiler set the precedent that C compilers
should allow arbitrary numbers of arguments to be passed to functions,
with unused arguments being passed on the stack but otherwise ignored.
Its documentation includes an implementation of "printf" which would be
expected to be adaptable to other implementations. Supporting this meant
that compilers for some platforms had to use a less-efficient calling
convention for *all* C functions than would be needed for almost any other
language.
The authors of the Standard said they wanted to avoid breaking existing
code. Assuming they were truthful, that would suggest that they intended
that implementations that could usefully work with existing code should
be compatible with it when practical. If a platform would require that
each function know in advance what arguments would be received, then it
would make sense to have the calls:
void foo(int,long,double);
void zoo(int,...);
foo(12, 123456L, 12.34);
zoo(12, 123456L, 12.34);
pass "foo" an int, a long, and a double, but pass "zoo" an int and a void*
which points to a struct{long p1; float p2;}. A caller couldn't know that
"zoo" required its parameters that way, however, without a prototype.
The authors of the C Standard never specify things as "On implementations
where variadic functions receive arguments the same way as any others,
calls to such functions without a prototype in scope should be handled the
same as calls to any other functions; on those where they receive arguments
differently, the behavior would be undefined". They expect that people
writing implementations should be able to figure out such things without
having to be babied.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-09-30 19:21 +0100 |
| Message-ID | <87d168f3o9.fsf@gmail.com> |
| In reply to | #120499 |
David Brown <david.brown@hesbynett.no> writes: >> So you know about every small subtle error within that 100Kloc >> projects, enough that you don't really need a compiler to help you >> find it? >> >> As on many previous occasions, I don't believe you. > > As on many previous occasions, you put words in my mouth and then > disagree with them. Box. Of. Rocks. >> just before a final }. But you obviously will know all about it, >> even if it was someone else who was responsible! Who needs a >> compiler for this stuff when the programmer is a clairvoyant! > > I cannot fathom why you think I don't have the compiler check this > sort of thing. Unlike you, I know how to use my compilers - I read > the manual pages. I enable warnings for this sort of thing, set as > errors. Box. Of. Rocks. > And again, because you seem to be working hard to misunderstand me, Box. Of. Rocks.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-30 19:45 +0100 |
| Message-ID | <dDRzB.547174$wU.193342@fx36.am4> |
| In reply to | #120613 |
On 30/09/2017 19:21, Gareth Owen wrote: > Box. Of. Rocks. > Box. Of. Rocks. > Box. Of. Rocks. I think it's clear who is either mentally deranged or has had a few. But please fuck off out of it, there's a good chap, if you have no contributions to make in this technical group.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-28 13:31 -0700 |
| Message-ID | <ln7ewiwon8.fsf@kst-u.example.com> |
| In reply to | #120485 |
David Brown <david.brown@hesbynett.no> writes:
> On 28/09/17 18:39, bartc wrote:
[...]
>> 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.)
>
> You have told the compiler you have a function that can take arguments
> of any type - and then you call that function with a variety of
> arguments. Is the compiler supposed to guess that you don't know what
> you are doing? To me, it is /not/ clear that the code you wrote is not
> right - nor what the correct version might be. It is only clear that
> you have a poor coding style and that if you had used a sensible
> header/source style then mistakes with incorrect function declarations
> are very difficult to make.
It is 100% clear that the program of which the above main function is a
part has undefined behavior. If a function is declared with (), then
it's the caller's responsibility to call it with the correct number and
type(s) of arguments. If the call is inconsistent with the definition
(which in this case is probably in some other source file), then the
behavior is undefined.
There is no possible definition of the fn function that could be
consistent with all 4 calls shown above. In fact, any definition could
be consistent with at most one of them.
Problem: Non-prototyped functions are error-prone. Solution: Don't use
them.
[...]
>> Under what circumstances would a declaration like:
>>
>> void fn();
>>
>> without listing parameter types be used anyway?
>
> I don't think you can legally define a matching function fn() in
> standard C.
In fact you can. For example, you could have:
void fn(const char *s) { puts(s); }
in another translation unit; that would make the fn("Hello, World!")
legal and well behaved.
> I am not an expert on variable argument functions. But it
> is certainly easy to imagine how such a function could be written to
> work (even if it cannot be done in C). You could have a function that
> has a static "stepNo" variable starting at 0 and incrementing for each
> call. On the first call, it interprets the parameter as an integer, and
> prints it out. On the second call, it interprets the parameter as a
> double and prints it out. And so on.
Calling a variadic function without a visible prototype has undefined
behavior. (It might happen to "work", and is likely to in many cases
because compiler writers usually try to make pre-ANSI code works as
expected. Pre-ANSI code didn't have prototypes, nor did it have
variadic functions in their current form.)
The prototype for a variadic function has ", ..." at the end of its
parameter list.
[...]
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-28 13:41 -0700 |
| Message-ID | <e28bc87d-2889-4fdc-9c89-7a94ea66fb1a@googlegroups.com> |
| In reply to | #120490 |
On Thursday, September 28, 2017 at 3:32:04 PM UTC-5, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> > On 28/09/17 18:39, bartc wrote:
> >> int main(void) {
> >> int a;
> >> void fn();
> >>
> >> fn(100);
> >> fn(200.0);
> >> fn("Hello, World!");
> >> fn(&a);
> >> }
> It is 100% clear that the program of which the above main function is a
> part has undefined behavior.
If fn() is declared as:
#include <stdlib.h>
#include <stdio.h>
int fn(n)
int n;
{
printf("%d\n",n);
exit(0);
}
what latitude would a conforming hosted compiler have do anything other
than output 100 and exit?
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web