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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-28 14:07 -0700 |
| Message-ID | <lny3oyv8et.fsf@kst-u.example.com> |
| In reply to | #120491 |
supercat@casperkitty.com writes:
> 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?
Good point, I hadn't thought of that. If the first call terminates the
program, the behavior of the other calls is irrelevant.
--
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 Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-28 16:25 -0700 |
| Message-ID | <5b6b3759-5c3e-4b65-9c54-a96ccc0dd393@googlegroups.com> |
| In reply to | #120490 |
On Thursday, September 28, 2017 at 1:32:04 PM UTC-7, Keith Thompson wrote: > 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. As nearly as I can tell it would be possible to use non-prototyped functions where we now use variadic functions. I think that is a bad idea. But ...
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-28 18:45 -0700 |
| Message-ID | <lnefqquvko.fsf@kst-u.example.com> |
| In reply to | #120510 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, September 28, 2017 at 1:32:04 PM UTC-7, Keith Thompson wrote:
>> 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.
>
> As nearly as I can tell it would be possible to use
> non-prototyped functions where we now use variadic
> functions. I think that is a bad idea. But ...
The behavior would be undefined.
Given:
printf("%d\n", 42);
printf("%s\n", "hello");
there is no way to declare and define printf such that both calls will
have defined behavior other than by using the ", ..." syntax.
Any call to a variadic function has undefined behavior unless a correct
prototype for that function is visible.
--
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 Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-28 19:54 -0700 |
| Message-ID | <f0027021-e19c-40bb-b1c4-0f0f782e0d5d@googlegroups.com> |
| In reply to | #120516 |
On Thursday, September 28, 2017 at 6:45:18 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Thursday, September 28, 2017 at 1:32:04 PM UTC-7, Keith Thompson wrote:
> >> 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.
> >
> > As nearly as I can tell it would be possible to use
> > non-prototyped functions where we now use variadic
> > functions. I think that is a bad idea. But ...
>
> The behavior would be undefined.
>
> Given:
>
> printf("%d\n", 42);
> printf("%s\n", "hello");
>
> there is no way to declare and define printf such that both calls will
> have defined behavior other than by using the ", ..." syntax.
>
> Any call to a variadic function has undefined behavior unless a correct
> prototype for that function is visible.
I don't want to defend the undefensible. But the context
would be
int printf () { ...}
which is not the library printf. With no prototype this
should work - provided the implementation gets the right
arguments in the right place.
As I said before I don't like this idea. But it seems
legal.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-09-28 20:51 -0700 |
| Message-ID | <e34536b2-23bd-4286-be7a-c4a90bb3b34b@googlegroups.com> |
| In reply to | #120519 |
On Thursday, September 28, 2017 at 10:54:23 PM UTC-4, David Kleinecke wrote:
> On Thursday, September 28, 2017 at 6:45:18 PM UTC-7, Keith Thompson wrote:
> > David Kleinecke <dkleinecke@gmail.com> writes:
...
> > > As nearly as I can tell it would be possible to use
> > > non-prototyped functions where we now use variadic
> > > functions. I think that is a bad idea. But ...
> >
> > The behavior would be undefined.
> >
> > Given:
> >
> > printf("%d\n", 42);
> > printf("%s\n", "hello");
> >
> > there is no way to declare and define printf such that both calls will
> > have defined behavior other than by using the ", ..." syntax.
> >
> > Any call to a variadic function has undefined behavior unless a correct
> > prototype for that function is visible.
>
> I don't want to defend the undefensible. But the context
> would be
> int printf () { ...}
> which is not the library printf. With no prototype this
> should work - provided the implementation gets the right
> arguments in the right place.
"All identifiers with external linkage in any of the following subclauses
(including the future library directions) and errno are always reserved for use
as identifiers with external linkage." (7.1.3p1). printf is and identifier with
external linkage defined in one of the following subclauses (specifically,
7.21.6.3), and is therefore reserved for use as an identifiers with external
linkage. You can therefore only do this by declaring your "printf" with internal
linkage (and you must, therefore define it in the same translation unit):
static int printf() { ... };
A variadic function can be called with defined behavior using arguments of many
different types, so long as it can figure out, at run time, what type each
argument has before using va_arg() to extract the value of that argument.
A function declared without a prototype can only be called with
defined behavior if each argument passed to it has a promoted type that's
compatible with the type of the corresponding parameter in the function's
definition (if that definition uses a prototype) or with the promoted type of
that parameter (if the definition does not use a prototype) (6.5.2.2p6).
> As I said before I don't like this idea. But it seems
> legal.
I don't think you can do anything remotely similar to a calling a variadic
function by using a function declared without a prototype.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-28 22:39 -0700 |
| Message-ID | <596f824f-b750-47f1-9d66-60873e73ceef@googlegroups.com> |
| In reply to | #120522 |
On Thursday, September 28, 2017 at 8:51:42 PM UTC-7, james...@verizon.net wrote:
> On Thursday, September 28, 2017 at 10:54:23 PM UTC-4, David Kleinecke wrote:
> > On Thursday, September 28, 2017 at 6:45:18 PM UTC-7, Keith Thompson wrote:
> > > David Kleinecke <dkleinecke@gmail.com> writes:
> ...
> > > > As nearly as I can tell it would be possible to use
> > > > non-prototyped functions where we now use variadic
> > > > functions. I think that is a bad idea. But ...
> > >
> > > The behavior would be undefined.
> > >
> > > Given:
> > >
> > > printf("%d\n", 42);
> > > printf("%s\n", "hello");
> > >
> > > there is no way to declare and define printf such that both calls will
> > > have defined behavior other than by using the ", ..." syntax.
> > >
> > > Any call to a variadic function has undefined behavior unless a correct
> > > prototype for that function is visible.
> >
> > I don't want to defend the undefensible. But the context
> > would be
> > int printf () { ...}
> > which is not the library printf. With no prototype this
> > should work - provided the implementation gets the right
> > arguments in the right place.
>
> "All identifiers with external linkage in any of the following subclauses
> (including the future library directions) and errno are always reserved for use
> as identifiers with external linkage." (7.1.3p1). printf is and identifier with
> external linkage defined in one of the following subclauses (specifically,
> 7.21.6.3), and is therefore reserved for use as an identifiers with external
> linkage. You can therefore only do this by declaring your "printf" with internal
> linkage (and you must, therefore define it in the same translation unit):
>
> static int printf() { ... };
>
> A variadic function can be called with defined behavior using arguments of many
> different types, so long as it can figure out, at run time, what type each
> argument has before using va_arg() to extract the value of that argument.
>
> A function declared without a prototype can only be called with
> defined behavior if each argument passed to it has a promoted type that's
> compatible with the type of the corresponding parameter in the function's
> definition (if that definition uses a prototype) or with the promoted type of
> that parameter (if the definition does not use a prototype) (6.5.2.2p6).
>
> > As I said before I don't like this idea. But it seems
> > legal.
>
> I don't think you can do anything remotely similar to a calling a variadic
> function by using a function declared without a prototype.
The standard library is not a required part of the C language.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-29 09:16 -0700 |
| Message-ID | <lnwp4htr8y.fsf@kst-u.example.com> |
| In reply to | #120525 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> The standard library is not a required part of the C language.
It certainly is required for hosted implementations. In any case, how
is that relevent to what we were discussing?
--
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 | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-09-29 16:17 +0000 |
| Message-ID | <oqlrni$4pu$1@news.xmission.com> |
| In reply to | #120551 |
In article <lnwp4htr8y.fsf@kst-u.example.com>, Keith Thompson <kst-u@mib.org> wrote: >David Kleinecke <dkleinecke@gmail.com> writes: >[...] >> The standard library is not a required part of the C language. > >It certainly is required for hosted implementations. In any case, how >is that relevent to what we were discussing? How is *ANY* of this relevant to "Set the result of void function" ? -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/Mandela
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-29 11:05 -0700 |
| Message-ID | <dd6a73f2-70da-4b22-aa55-b1fbcf5afe8d@googlegroups.com> |
| In reply to | #120551 |
On Friday, September 29, 2017 at 9:16:23 AM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > [...] > > The standard library is not a required part of the C language. > > It certainly is required for hosted implementations. In any case, how > is that relevent to what we were discussing? The standard library was assumed to define the meaning of the token "printf". An unhosted program can use "printf" to mean anything it pleases - as I did.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-29 11:23 -0700 |
| Message-ID | <lnmv5dtlcw.fsf@kst-u.example.com> |
| In reply to | #120559 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, September 29, 2017 at 9:16:23 AM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> > The standard library is not a required part of the C language.
>>
>> It certainly is required for hosted implementations. In any case, how
>> is that relevent to what we were discussing?
>
> The standard library was assumed to define the meaning of the
> token "printf". An unhosted program can use "printf" to mean
> anything it pleases - as I did.
By "unhosted program", you mean a program running under a freestanding
implementation, yes?
I have no clue why you would choose to define a function called
"printf" with no parameters and a non-prototype declaration as part
of its definition. I don't see how that has anything to do with
what we've been discussing, which was your claim upthread that:
As nearly as I can tell it would be possible to use
non-prototyped functions where we now use variadic
functions. I think that is a bad idea. But ...
How does your redefinition of "printf" contribute to that discussion?
My perception is that you merely moved the goalposts, probably to
somewhere out in the parking lot.
In pre-ANSI C, yes, the printf function would commonly be defined as:
int printf() { /* ... */}
or perhaps as:
int printf(format)
char *format;
{
/* ... */
}
with some compiler-specific code to process the arguments. It was not
portable, but it was the only approach possible at the time. ANSI C
added ", ..." and <stdarg.h> precisely to make it possible to define
printf and similar functions portably. In modern C, any attempt to use
the pre-ANSI methods to define a printf-like function might happen to
work, but it would have undefined behavior.
What point were you trying to make?
--
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-29 12:15 -0700 |
| Message-ID | <88b67cd7-1e41-4ae5-9147-cb3567327fb8@googlegroups.com> |
| In reply to | #120564 |
On Friday, September 29, 2017 at 1:23:36 PM UTC-5, Keith Thompson wrote:
> In pre-ANSI C, yes, the printf function would commonly be defined as:
>
> int printf() { /* ... */}
>
> or perhaps as:
>
> int printf(format)
> char *format;
> {
> /* ... */
> }
>
> with some compiler-specific code to process the arguments. It was not
> portable, but it was the only approach possible at the time. ANSI C
> added ", ..." and <stdarg.h> precisely to make it possible to define
> printf and similar functions portably. In modern C, any attempt to use
> the pre-ANSI methods to define a printf-like function might happen to
> work, but it would have undefined behavior.
On platforms which have a defined conventions for function calls and
argument passing, a compiler which specifies *that it will always behave in
a fashion consistent with those conventions* would, in so doing, define the
behavior of code that fetches its parameters from the places where a caller
would be required to put its arguments. The Standard doesn't require that
implementations behave in a fashion consistent with any particular platform's
calling conventions, but a compiler cannot truthfully claim that it upholds
a platform's conventions in all cases unless in behaves in every case in a
fashion consistent with them.
I don't know about the mainframe world, but in the microcomputer world things
were very consistent. The printf function given in the C74 manual would need
to be adjusted slightly to accommodate different sizes of arguments and
different amounts of padding between them, but a very wide range of micro-
computer implementations could have been accommodated with no other changes.
Such code might not be 100% portable, but 95% or better among microprocessor
implementations would likely be a realistically achievable goal.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-29 16:04 -0700 |
| Message-ID | <def3dea9-4caa-4aaf-ac4b-805b126a62aa@googlegroups.com> |
| In reply to | #120564 |
On Friday, September 29, 2017 at 11:23:36 AM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Friday, September 29, 2017 at 9:16:23 AM UTC-7, Keith Thompson wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >> [...]
> >> > The standard library is not a required part of the C language.
> >>
> >> It certainly is required for hosted implementations. In any case, how
> >> is that relevent to what we were discussing?
> >
> > The standard library was assumed to define the meaning of the
> > token "printf". An unhosted program can use "printf" to mean
> > anything it pleases - as I did.
>
> By "unhosted program", you mean a program running under a freestanding
> implementation, yes?
>
> I have no clue why you would choose to define a function called
> "printf" with no parameters and a non-prototype declaration as part
> of its definition. I don't see how that has anything to do with
> what we've been discussing, which was your claim upthread that:
>
> As nearly as I can tell it would be possible to use
> non-prototyped functions where we now use variadic
> functions. I think that is a bad idea. But ...
>
> How does your redefinition of "printf" contribute to that discussion?
> My perception is that you merely moved the goalposts, probably to
> somewhere out in the parking lot.
>
> In pre-ANSI C, yes, the printf function would commonly be defined as:
>
> int printf() { /* ... */}
>
> or perhaps as:
>
> int printf(format)
> char *format;
> {
> /* ... */
> }
>
> with some compiler-specific code to process the arguments. It was not
> portable, but it was the only approach possible at the time. ANSI C
> added ", ..." and <stdarg.h> precisely to make it possible to define
> printf and similar functions portably. In modern C, any attempt to use
> the pre-ANSI methods to define a printf-like function might happen to
> work, but it would have undefined behavior.
>
> What point were you trying to make?
I didn't think I was being that obscure. I was saying
that if we have no information about suitable arguments
then we could write
int not_printf ();
not_printf ("Hello World");
not_printf ("uses %d words", 2);
and get the expected result - assuming we knew the
implementation always got the arguments in the right
places.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-29 16:44 -0700 |
| Message-ID | <lnbmltt6hf.fsf@kst-u.example.com> |
| In reply to | #120588 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, September 29, 2017 at 11:23:36 AM UTC-7, Keith Thompson wrote:
[...]
>> What point were you trying to make?
>
> I didn't think I was being that obscure. I was saying
> that if we have no information about suitable arguments
> then we could write
>
> int not_printf ();
> not_printf ("Hello World");
> not_printf ("uses %d words", 2);
>
> and get the expected result - assuming we knew the
> implementation always got the arguments in the right
> places.
Perhaps so. Of course any such code relies on explicitly undefined
behavior, and the code that implements not_printf() would have to
use implementation-specific methods to obtain the argument values.
That's ugly and error-prone, and it's exactly why C since 1989 has
provided more reliable mechanisms.
(Your reuse of the name "printf", your showing a definition of a
printf function that explicitly has no parameters, and your statement
that <stdio.h> is not required without mentioning freestanding
implementations all contributed to the confusion.)
--
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 Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-30 10:04 -0700 |
| Message-ID | <e9182d55-b4a9-4183-8a13-d0754e454f92@googlegroups.com> |
| In reply to | #120591 |
On Friday, September 29, 2017 at 4:44:59 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Friday, September 29, 2017 at 11:23:36 AM UTC-7, Keith Thompson wrote:
> [...]
> >> What point were you trying to make?
> >
> > I didn't think I was being that obscure. I was saying
> > that if we have no information about suitable arguments
> > then we could write
> >
> > int not_printf ();
> > not_printf ("Hello World");
> > not_printf ("uses %d words", 2);
> >
> > and get the expected result - assuming we knew the
> > implementation always got the arguments in the right
> > places.
>
> Perhaps so. Of course any such code relies on explicitly undefined
> behavior, and the code that implements not_printf() would have to
> use implementation-specific methods to obtain the argument values.
>
> That's ugly and error-prone, and it's exactly why C since 1989 has
> provided more reliable mechanisms.
>
> (Your reuse of the name "printf", your showing a definition of a
> printf function that explicitly has no parameters, and your statement
> that <stdio.h> is not required without mentioning freestanding
> implementations all contributed to the confusion.)
I don't mind causing a little confusion by not assuming
hosted C is the default C. Too many people in this group
don't seem to understand that freestanding implementations
are also possible.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-30 10:33 -0700 |
| Message-ID | <36ddb002-6cc7-4c78-b8da-cdf2896f14d3@googlegroups.com> |
| In reply to | #120609 |
On Saturday, September 30, 2017 at 12:04:49 PM UTC-5, David Kleinecke wrote: > I don't mind causing a little confusion by not assuming > hosted C is the default C. Too many people in this group > don't seem to understand that freestanding implementations > are also possible. And also understand that it is very common for programmers using freestanding implementations to "partially host" them. While the Standard doesn't require that freestanding implementations support self-hosting, but many of them do. All that is necessary to turn a self-hosting freestanding implementation into a hosted one is a set of C files that implement all the functions of the Standard library. In cases where an application doesn't need all of the functionality that a hosted implementation would need to provide (e.g. it never uses "printf" with any format specifiers other than %d, %02x, %04x, and %08lx) replacing full-fledged library functions with custom-tailored ones may allow useful efficiency improvements. Note that while some execution environments (like Unix) may provide library implementations code can link to without having to include them with the generated machine code, many others don't. If a conforming printf implementation would take 20KB of code, but a minimalist version that fits a program's needs would take 2KB, being able to substitute the latter would let a programmer shrink a program by 18K. If the program is supposed to fit in a part with 32K of code space, that can be a *huge* advantage.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-09-29 11:26 -0700 |
| Message-ID | <b6d7a8c1-689b-4e4b-97e6-c04c44cf86e7@googlegroups.com> |
| In reply to | #120559 |
On Friday, September 29, 2017 at 2:05:14 PM UTC-4, David Kleinecke wrote: ... > The standard library was assumed to define the meaning of the > token "printf". An unhosted program can use "printf" to mean > anything it pleases - as I did. printf is always reserved for use as an identifier with external linkage - 7.1.3p1 contains no exemption from that reservation for freestanding implementations. This allows, among other possibilities, for a freestanding implementation to provide any standard library functions it wishes to, in addition to the minimal amount of standard library support that is mandatory for freestanding implementations. I believe it is also permitted to provide them in a form that doesn't match the standard's requirements for those functions, or to use those same identifiers for objects instead of functions, but I'm not entirely sure about that point. What would you expect your program to do if compiled by such an implementation?
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-29 16:03 -0700 |
| Message-ID | <dc142187-dda2-494a-aa2b-6db3bd92dd49@googlegroups.com> |
| In reply to | #120566 |
On Friday, September 29, 2017 at 11:26:40 AM UTC-7, james...@verizon.net wrote: > On Friday, September 29, 2017 at 2:05:14 PM UTC-4, David Kleinecke wrote: > ... > > The standard library was assumed to define the meaning of the > > token "printf". An unhosted program can use "printf" to mean > > anything it pleases - as I did. > > printf is always reserved for use as an identifier with external linkage - 7.1.3p1 contains no exemption from that reservation for freestanding implementations. This allows, among other possibilities, for a freestanding implementation to provide any standard library functions it wishes to, in addition to the minimal amount of standard library support that is mandatory for freestanding implementations. I believe it is also permitted to provide them in a form that doesn't match the standard's requirements for those functions, or to use those same identifiers for objects instead of functions, but I'm not entirely sure about that point. > What would you expect your program to do if compiled by such an implementation? I don't read the standard that way.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-09-29 09:44 -0700 |
| Message-ID | <d8c57dfd-839b-4c1a-b19b-b34beedff13c@googlegroups.com> |
| In reply to | #120525 |
On Friday, September 29, 2017 at 1:39:39 AM UTC-4, David Kleinecke wrote: > On Thursday, September 28, 2017 at 8:51:42 PM UTC-7, james...@verizon.net wrote: > > On Thursday, September 28, 2017 at 10:54:23 PM UTC-4, David Kleinecke wrote: > > > On Thursday, September 28, 2017 at 6:45:18 PM UTC-7, Keith Thompson wrote: > > > > David Kleinecke <dkleinecke@gmail.com> writes: ... > > A variadic function can be called with defined behavior using arguments of > > many different types, so long as it can figure out, at run time, what type > > each argument has before using va_arg() to extract the value of that > > argument. ... > The standard library is not a required part of the C language. "A conforming freestanding implementation shall accept any strictly conforming program in which the use of the features specified in the library clause (clause 7) is confined to the contents of the standard headers <float.h>, <iso646.h>, <limits.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and <stdnoreturn.h>." (4p6). Note that <stdarg.h> is where va_arg() is defined. I presume it's my mention of va_arg() that prompted your comment? I can't find anything else I wrote that would justify responding by airing your misconceptions about the mandatory nature of the library. A hosted implementation of C is required to support the entire library. You may have been confused by the fact that many C compilers are provided without a copy of the standard library, relying upon some other vendor to provide that library. However, such compilers only qualify as a conforming implementation of C when combined with a compatible version of the C standard library.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-29 11:15 -0700 |
| Message-ID | <67d49fc0-fa3d-434d-b79c-cb3041bcf72e@googlegroups.com> |
| In reply to | #120554 |
On Friday, September 29, 2017 at 9:44:41 AM UTC-7, james...@verizon.net wrote: > On Friday, September 29, 2017 at 1:39:39 AM UTC-4, David Kleinecke wrote: > > On Thursday, September 28, 2017 at 8:51:42 PM UTC-7, james...@verizon.net wrote: > > > On Thursday, September 28, 2017 at 10:54:23 PM UTC-4, David Kleinecke wrote: > > > > On Thursday, September 28, 2017 at 6:45:18 PM UTC-7, Keith Thompson wrote: > > > > > David Kleinecke <dkleinecke@gmail.com> writes: > ... > > > A variadic function can be called with defined behavior using arguments of > > > many different types, so long as it can figure out, at run time, what type > > > each argument has before using va_arg() to extract the value of that > > > argument. > ... > > The standard library is not a required part of the C language. > > "A conforming freestanding implementation shall accept any strictly conforming > program in which the use of the features specified in the library clause (clause > 7) is confined to the contents of the standard headers <float.h>, <iso646.h>, > <limits.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and > <stdnoreturn.h>." (4p6). Note that <stdarg.h> is where va_arg() is defined. I > presume it's my mention of va_arg() that prompted your comment? I can't find > anything else I wrote that would justify responding by airing your > misconceptions about the mandatory nature of the library. > A hosted implementation of C is required to support the entire library. > > You may have been confused by the fact that many C compilers are provided > without a copy of the standard library, relying upon some other vendor to > provide that library. However, such compilers only qualify as a conforming > implementation of C when combined with a compatible version of the C standard > library. As usual I go with C90 where fewer headers are required. But what matters is that stdio.h isn't. I didn't assume va_arg etc. were not defined - only that the same effect could be obtained without using them. I don't like such a use but, so far as I can tell, I must allow it in my compiler.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-29 11:35 -0700 |
| Message-ID | <lning1tks8.fsf@kst-u.example.com> |
| In reply to | #120562 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, September 29, 2017 at 9:44:41 AM UTC-7, james...@verizon.net wrote:
[...]
>> A hosted implementation of C is required to support the entire library.
>>
>> You may have been confused by the fact that many C compilers are provided
>> without a copy of the standard library, relying upon some other vendor to
>> provide that library. However, such compilers only qualify as a conforming
>> implementation of C when combined with a compatible version of the C standard
>> library.
>
> As usual I go with C90 where fewer headers are required. But what
> matters is that stdio.h isn't.
<stdio.h> is absolutely required for hosted implementations. It is not
required for freestanding implementations. Please indicate that you
understand the distinction.
> I didn't assume va_arg etc. were
> not defined - only that the same effect could be obtained without
> using them. I don't like such a use but, so far as I can tell, I
> must allow it in my compiler.
Why must you allow it? Are you building a compiler that you intend to
be used only as part of a freestanding implementation? If so, you don't
have to worry, for purposes of your implementation, about <stdio.h>.
But <stdarg.h> is required for any conforming implementation, either
hosted for freestanding.
Since you're implementing the compiler, you can't just *assume* that
effect of the <stdarg.h> mechanisms can be obtained without using the
header, you have to make sure of it. <stdarg.h> can't be implemented in
portable C, but it can be (and typically is) implemented in C that makes
some non-portable assumptions.
--
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]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web