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 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-29 16:11 -0700 |
| Message-ID | <d6be54f3-26be-4fe9-a4e1-01afdb689b43@googlegroups.com> |
| In reply to | #120570 |
On Friday, September 29, 2017 at 11:36:00 AM UTC-7, Keith Thompson wrote: > 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 understand the distinction. That's exactly the point I was making. In code written for a freestanding implementation I am free to use stdio.h if I can lay my hands on it or I can ignore it. > > > 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]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-29 16:14 -0700 |
| Message-ID | <ae3b85f9-14d7-40ad-bf13-52806712b5c3@googlegroups.com> |
| In reply to | #120570 |
On Friday, September 29, 2017 at 11:36:00 AM UTC-7, Keith Thompson wrote: > 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. I never said I would drop variadics (stdarg,h) only that I think the same result can be obtained without using them.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-30 08:55 -0700 |
| Message-ID | <3b986987-8103-4acc-8b01-add91a280534@googlegroups.com> |
| In reply to | #120590 |
On Friday, September 29, 2017 at 6:14:20 PM UTC-5, David Kleinecke wrote:
> On Friday, September 29, 2017 at 11:36:00 AM UTC-7, Keith Thompson wrote:
> > 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.
>
> I never said I would drop variadics (stdarg,h) only that I
> think the same result can be obtained without using them.
On many platforms, the same effect can be obtained without using "official"
variadics; in the pre-standard days, compiler writers attempted to support
such code in the same fashion as C74.
On some platforms, however, it may be impractical to implement such
semantics in compatible fashion. Most notably, on a platform which has
push and pop instructions, but whose stack is not otherwise addressable,
something like:
format("Hello");
format(" the value is %d\n", 123);
would generate code like:
push l1
push string1
jmp format
l1:
push l2
push 123
push string2
jmp format
l2:
...
string1: db "Hello ",0
string2: db " the value is %d",10,0
If the format function pops the string argument to an automatic variable,
and then pops a value for each %d in the string, and then does a return,
all will be good. If the format argument doesn't include a %d for every
value that is passed, however, the function will return to the wrong place.
On a platform without an addressable stack, which handled things as above,
there would be two sensible ways to handle variadic functions:
1. Continue to handle them as above, breaking any code (likely written for
other systems) which expects to be able to return without consuming all
the arguments.
2. Require that all function calls on such a platform give the caller enough
information to clean up regardless of how many arguments were used. This
could e.g. be handled by passing a pointer to a temporary structure
containing all the arguments. Doing that would allow all existing source
code to work as it always had, but would require that everything be
recompiled. Existing pre-compiled code would not be usable, however, and
re-compiled code would likely be slower than it had been when using the
old approach.
3. Allow functions that aren't declared as taking variadic arguments to be
processed as they always had been, but require that functions which have
a "..." in their prototype be handled as described in #2. Under that
model, a compiler would generate different code for each of the following
calls:
void function1(int x,...);
void function2(int x, int y, ...);
void function3(int x, int y, int z);
void function4();
function1(1,2,3);
function2(1,2,3);
function3(1,2,3);
The Keil-51 compiler isn't quite conforming, but uses an approach I rather
like. In cases where the existence of a prototype would affect caller-side
code, it adjusts the link-time name of the function. It does so even in a
case the Standard wouldn't allow, specifically:
int functionX1(x) int x; { return x;} // Link-time name is functionX1
int functionX2(int x) { return x;} // Link-time name is _functionX2
but since the latter function may be called more efficiently, and since
failure to prototype the latter function before calling it will result in
a link error rather than erroneous behavior, I'd rather see the Standard
allow such an approach than forbid it.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-09-29 11:36 -0700 |
| Message-ID | <a8637d61-0385-4c46-95bf-86f8f39faac5@googlegroups.com> |
| In reply to | #120562 |
On Friday, September 29, 2017 at 2:16:09 PM UTC-4, David Kleinecke wrote: ... > 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. I don't think you do. The C standard has never defined the behavior of such code. The printf() and scanf() functions were a mysterious exception to the normal argument passing rules in K&R C - the mechanism that was used at that time to implement those functions was not made available to ordinary users until C was standardized. And when the mechanism was standardized, it was standardized in a way that doesn't apply to the code you're talking about. If you don't like such code, don't support it - no version of the C standard says anything that would force you to do so.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-29 12:05 +0100 |
| Message-ID | <87mv5dg3yr.fsf@bsb.me.uk> |
| In reply to | #120522 |
jameskuyper@verizon.net writes: <snip> > I don't think you can do anything remotely similar to a calling a variadic > function by using a function declared without a prototype. Not since 1989, no, but before there were prototypes in C you had no choice. I suspect DK is remembering archaic C and assuming that C89 did not change anything in this area. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-29 12:17 +0100 |
| Message-ID | <87ing1g3f5.fsf@bsb.me.uk> |
| In reply to | #120519 |
David Kleinecke <dkleinecke@gmail.com> writes:
<snip>
> 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.
"It should work" and "it seems legal" are very different sorts of
statement. It may well work in many implementations, partly because
they will often support pre-ANSI C in which there were no prototypes,
but it is not legal in the sense that all C standards make it undefined.
(You also complicate matters by using a printf but "which is not the
library printf". Re-defining standard library functions introduces
another complication that can obscure the general point about variadic
functions.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-29 09:15 -0700 |
| Message-ID | <ln1smpv5vb.fsf@kst-u.example.com> |
| In reply to | #120519 |
David Kleinecke <dkleinecke@gmail.com> writes:
> 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.
So it has nothing to do with the actual printf, which has to accept a
variable number of arguments.
Using a different name to avoid confusion:
int not_printf() { /* ... */ }
empty parentheses in a function *definition* mean that the function has
no parameters. The difference between that and
int not_printf(void) { /* ... */ }
is that the latter imposes a constraint on callers, so that calling it
with one or more arguments must be diagnosed.
> 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.
No, calling not_printf() with one or more arguments has undefined
behavior but need not be diagnosed.
This is why we use prototypes.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-09-29 09:42 +1300 |
| Message-ID | <f3556aF6c2hU4@mid.individual.net> |
| In reply to | #120456 |
On 09/29/17 05:39 AM, 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.)
If you want C++ behaviour, you know where to find it!
CC x.c
"x.c", line 5: Error: Too many arguments in call to "fn()".
"x.c", line 6: Error: Too many arguments in call to "fn()".
"x.c", line 7: Error: Too many arguments in call to "fn()".
"x.c", line 8: Error: Too many arguments in call to "fn()".
4 Error(s) detected.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-28 21:55 +0100 |
| Message-ID | <PkdzB.1410256$py6.64773@fx22.am4> |
| In reply to | #120492 |
On 28/09/2017 21:42, Ian Collins wrote:
> On 09/29/17 05:39 AM, 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.)
>
> If you want C++ behaviour, you know where to find it!
>
> CC x.c
> "x.c", line 5: Error: Too many arguments in call to "fn()".
> "x.c", line 6: Error: Too many arguments in call to "fn()".
> "x.c", line 7: Error: Too many arguments in call to "fn()".
> "x.c", line 8: Error: Too many arguments in call to "fn()".
> 4 Error(s) detected.
It's got that bit right at least. (It doesn't look like it needed a
bunch of options to do do either.)
But why are so many defending that behaviour with C?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-28 14:12 -0700 |
| Message-ID | <lntvzmv87e.fsf@kst-u.example.com> |
| In reply to | #120493 |
bartc <bc@freeuk.com> writes:
[...]
> But why are so many defending that behaviour with C?
Bart, seriously, what is your problem?
I haven't seen anyone defending the behavior. I've seen numerous
people *describing* the behavior, and you refusing to accept that
the C standard actually says what we say it does.
--
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 | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-09-28 17:22 -0400 |
| Message-ID | <2483ba00-8250-c4e8-287d-fa0f07f62cd9@verizon.net> |
| In reply to | #120497 |
On 2017-09-28 17:12, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > [...] >> But why are so many defending that behaviour with C? > > Bart, seriously, what is your problem? > > I haven't seen anyone defending the behavior. I've seen numerous That's not quite true - I've defended the behavior required by the standard as a necessary consequence of the committee's desire to retain backwards compatibility. But no one has defended the use of unprototyped function declarations as a good idea. I also don't remember hearing anyone defend the lousy quality of gcc's diagnostics when no option is selected. I think that -Wall, at least, should have been the default.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-09-29 19:50 +0100 |
| Message-ID | <871smpuyom.fsf@gmail.com> |
| In reply to | #120497 |
Keith Thompson <kst-u@mib.org> writes: > bartc <bc@freeuk.com> writes: > [...] >> But why are so many defending that behaviour with C? > > Bart, seriously, what is your problem? YHBT.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-28 09:00 -0700 |
| Message-ID | <lning2yfrx.fsf@kst-u.example.com> |
| In reply to | #120440 |
bartc <bc@freeuk.com> writes:
> On 28/09/2017 08:42, David Brown wrote:
>> On 27/09/17 22:54, bartc wrote:
>
>
>>> Return with no value seen in a Function:
>>>
>>> C Ignored or warning
>>
>> A diagnostic (warning or error) is mandatory - the compiler may not
>> ignore this.
>>
>> gcc: warning: 'return' with no value, in function returning non-void
>
>
> That's what I said: Ignored or warning. My tests with C weren't
> exhaustive. Tiny C ignored it. Gcc (even with -std=c11, -Wall etc) gave
> a warning, as did MSVC. Three lesser compilers gave an error.
One more time: The C standard does not distinguish between warnings and
fatal errors. It requires a "diagnostic message" for any violation of a
syntax rule or constraint. As far as C conformance is concerned, there
is no distinction between "error" and "warning". "Warning" and
"ignored", on the other hand, are different. Tell us "Ignored or
warning" is useless as far as C conformance is concerned.
DO YOU UNDERSTAND THAT? And if so, why do you pretend not to?
I understand that you would prefer these diagnostics to be fatal errors,
and as I've said several times, I agree with you on that point.
[...]
> My gcc, with all the options, said 'control reaches end of non-void
> function'. If -Werror was used (the same -Werror as used to make the
> above issue a fatal error), then this would fail a program that you said
> above is legal.
gcc's -Werror option makes all warnings fatal -- even ones that are not
required by the language. "gcc -Werror" is non-conforming.
[...]
> Tell, me, under what circumstances would running off the end of a
> non-void function, not returning a value from a non-void function, or
> returning a value in a void function, ever pass a code review?
None (or a poorly done code review). Nobody has claimed that any C code
for which the standard does not require a diagnostic would pass a code
review. You have moved the goalposts.
> If the answer is 'never', then what is the language and/or compiler
> playing at in letting them through as warnings? Why do they have to be
> told to make them errors?
The standard does not require diagnostics to be fatal; a warning (except
for #error) satisfies the standard's requirements. That's just the way
it is. As I've said, I personally would prefer it to be otherwise. I
honestly don't know why it's written that way. I suspect backward
compatibility is part of the reason. Another might be to allow a
conforming compiler to implement extensions; it can diagnose a use of
the extension without rejecting the program. There's some discussion in
the ANSI C Rationale: https://www.lysator.liu.se/c/rat/b.html#2-1-1-3
gcc and some other compilers take advantage of the standard's permission
to issue non-fatal warnings in some modes (of course gcc can easily be
made to behave the way you prefer). As far as I know, nobody here is a
gcc implementer. We can't answer your question. I personally dislike
gcc's default behavior, but I don't worry about it too much because it's
so easy to make it behave in the way I prefer.
[...]
> The answer isn't for Bart to brush up on his compiler-options knowledge;
Yes, Bart, that's exactly the answer.
[...]
>> And the simple application of common flags "-Wall -Werror" (along with
>> "-Wpedantic" if you like) gives you the errors you want from gcc, rather
>> than just warnings.
>
> See above. The answer isn't just piling on option after option.
Yes it is.
--
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 09:35 -0700 |
| Message-ID | <6af39acf-47b3-499c-b1f9-7d6e368aabf1@googlegroups.com> |
| In reply to | #120448 |
On Thursday, September 28, 2017 at 11:00:50 AM UTC-5, Keith Thompson wrote:
> As I've said, I personally would prefer it to be otherwise. I
> honestly don't know why it's written that way. I suspect backward
> compatibility is part of the reason. Another might be to allow a
> conforming compiler to implement extensions; it can diagnose a use of
> the extension without rejecting the program. There's some discussion in
> the ANSI C Rationale: https://www.lysator.liu.se/c/rat/b.html#2-1-1-3
One of the stated goals of the Standard's authors was to avoid "breaking"
existing useful programs. Allowing implementations to behave in arbitrary
fashion when given a particular program is not considered a "breaking"
change if they would be allowed to process the program in useful fashion.
Consider the function:
unsigned mul(unsigned char x, unsigned char y) { return x*y; }
Such a program would have had well-defined behavior on an typical
implementation where "unsigned" was 16 bits if the unsigned char types
promoted to unsigned int (as they sometimes did in the days before the
Standard). In cases where the arithmetic value of `x*y` would exceed
32767, an implementation might be allowed to behave in arbitrary fashion,
but the change wasn't considered "breaking" since implementations were
allowed to process the code the same way as they always had (and indeed
the authors of the Standard indicated that they expected implementations
to do so).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-28 10:57 -0700 |
| Message-ID | <ln1smqyacj.fsf@kst-u.example.com> |
| In reply to | #120455 |
supercat@casperkitty.com writes:
> On Thursday, September 28, 2017 at 11:00:50 AM UTC-5, Keith Thompson wrote:
>> As I've said, I personally would prefer it to be otherwise. I
>> honestly don't know why it's written that way. I suspect backward
>> compatibility is part of the reason. Another might be to allow a
>> conforming compiler to implement extensions; it can diagnose a use of
>> the extension without rejecting the program. There's some discussion in
>> the ANSI C Rationale: https://www.lysator.liu.se/c/rat/b.html#2-1-1-3
>
> One of the stated goals of the Standard's authors was to avoid "breaking"
> existing useful programs. Allowing implementations to behave in arbitrary
> fashion when given a particular program is not considered a "breaking"
> change if they would be allowed to process the program in useful fashion.
> Consider the function:
>
> unsigned mul(unsigned char x, unsigned char y) { return x*y; }
[snip]
That's nice, but we were talking about compile-time diagnostics.
--
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 | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-09-25 10:35 -0700 |
| Message-ID | <c4baadb9-0c58-4823-a0c1-7daee934e307@googlegroups.com> |
| In reply to | #120306 |
On Monday, September 25, 2017 at 12:49:18 PM UTC-3, Keith Thompson wrote: > Thiago Adams writes: ... > > to swap this string you need to fix the internal pointer. > > IF you're working with data structures like that, perhaps it would be > better to rework your code so you can swap pointers rather than full > objects. This kind of technique is used to avoid heap allocations. I am not using it at this moment. But in some cases you can have faster data structures to fill. The situation were you need to move can happen, this also depends if your type is designed for many cases or for just one specific case.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-09-25 06:57 -0700 |
| Message-ID | <c56cd020-ebc5-4ee5-9751-6370c69dd4d8@googlegroups.com> |
| In reply to | #120285 |
On Monday, September 25, 2017 at 1:59:00 PM UTC+1, Thiago Adams wrote: > On Monday, September 25, 2017 at 9:45:07 AM UTC-3, Thiago Adams wrote: > > Comparing C++ swap with C, the key point is to ask if C want's > function overloading / templates / operator overloading. > The real issue with swap is do you want "move semantics". As long as my actual structures are small, it's a lot cheaper to swap A and B than to take a copy of B and assign it to A. usually B is then discarded, but the swap ensures that it is in a coherent state and removes the necessity for deleting A. In C we just pass pointers and the programmer has to keep track of which pointers hold allocated memory.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-25 16:32 +0100 |
| Message-ID | <87vak623qk.fsf@bsb.me.uk> |
| In reply to | #120277 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, September 25, 2017 at 7:31:12 AM UTC+1, David Brown wrote:
>> On 24/09/17 14:09, Jorgen Grahn wrote:
>
>> In C++, you know std::swap is not a macro. As long as you are not doing
>> something programmer-unfriendly, like defining [] or ++ operators that
>> act in unexpected ways, then the ordering and effects is clear.
>>
>> In C, this sort of thing tends to be a macro. The operands to "swap"
>> might be evaluated several times in different orders - or they might be
>> handled in a safe manner (using compiler extensions like "typeof"). C++
>> lets you write a good "swap" function - C does not.
>>
> The C way of writing a swap is
>
> void memswap(void *ptra, void *ptrb, size_t length);
In modern C
void memswap(void *restrict ptra, void *restrict ptrb, size_t length);
might be better. Writing it this way makes it clear that the code is
intended to be used to swap the contents of non-overlapping objects.
> However this exposes a few weaknesses in the language. We can't force
> the types to be identical. We have to write the loop as a dumb
> bytewise copying loop to support a situation - structures with size
> that is an odd number of bytes - that is very unlikely to occur.
Why does that mean the code must use a dumb byte-wise loop? For
example, if you know that your library memcpy is good for small
power-of-two sizes you might write:
void mem_swap(void *restrict vp1, void *restrict vp2, size_t size)
{
switch (size) {
case 1: case 2: case 4: case 8: {
char t[8];
memcpy(&t, vp1, size);
memcpy(vp1, vp2, size);
memcpy(vp2, &t, size);
break;
}
default: {
size_t half = 1;
while ((half << 1) < size) half <<= 1;
mem_swap(vp1, vp2, half);
mem_swap((char *)vp1 + half, (char *)vp2 + half, size - half);
}}
}
The little dance with 'half' is to guarantee aligned moves. When you
know the compiler, you could probably replace it with a built-in
bit-twiddling function (you with gcc).
> We can inline the code these days, but not in C89 which is still live.
This remark might give people the wrong impression. C89 (AKA C90)
compilers are permitted to expand functions inline, and compilers for
later C versions are not obliged to even when the 'inline' qualifier is
used. What C99 added was a mechanism to make the programmer's
intentions clear.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2017-09-25 08:43 -0700 |
| Message-ID | <1d22cc40-1a6e-450d-afdd-f0e0da45732d@googlegroups.com> |
| In reply to | #120302 |
On Monday, September 25, 2017 at 4:32:48 PM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
> > On Monday, September 25, 2017 at 7:31:12 AM UTC+1, David Brown wrote:
> >> On 24/09/17 14:09, Jorgen Grahn wrote:
> >
> >> In C++, you know std::swap is not a macro. As long as you are not doing
> >> something programmer-unfriendly, like defining [] or ++ operators that
> >> act in unexpected ways, then the ordering and effects is clear.
> >>
> >> In C, this sort of thing tends to be a macro. The operands to "swap"
> >> might be evaluated several times in different orders - or they might be
> >> handled in a safe manner (using compiler extensions like "typeof"). C++
> >> lets you write a good "swap" function - C does not.
> >>
> > The C way of writing a swap is
> >
> > void memswap(void *ptra, void *ptrb, size_t length);
>
> In modern C
>
> void memswap(void *restrict ptra, void *restrict ptrb, size_t length);
>
> might be better. Writing it this way makes it clear that the code is
> intended to be used to swap the contents of non-overlapping objects.
>
> > However this exposes a few weaknesses in the language. We can't force
> > the types to be identical. We have to write the loop as a dumb
> > bytewise copying loop to support a situation - structures with size
> > that is an odd number of bytes - that is very unlikely to occur.
>
> Why does that mean the code must use a dumb byte-wise loop? For
> example, if you know that your library memcpy is good for small
> power-of-two sizes you might write:
>
> void mem_swap(void *restrict vp1, void *restrict vp2, size_t size)
> {
> switch (size) {
> case 1: case 2: case 4: case 8: {
> char t[8];
> memcpy(&t, vp1, size);
> memcpy(vp1, vp2, size);
> memcpy(vp2, &t, size);
> break;
> }
> default: {
> size_t half = 1;
> while ((half << 1) < size) half <<= 1;
> mem_swap(vp1, vp2, half);
> mem_swap((char *)vp1 + half, (char *)vp2 + half, size - half);
> }}
> }
>
> The little dance with 'half' is to guarantee aligned moves. When you
> know the compiler, you could probably replace it with a built-in
> bit-twiddling function (you with gcc).
>
> > We can inline the code these days, but not in C89 which is still live.
>
> This remark might give people the wrong impression. C89 (AKA C90)
> compilers are permitted to expand functions inline, and compilers for
> later C versions are not obliged to even when the 'inline' qualifier is
> used. What C99 added was a mechanism to make the programmer's
> intentions clear.
>
That's a good memswap on top on inlineable memcpy(). Whether a compiler
would be clever enough to make the optimisations I don't know, but at
least there's a good chance.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-25 22:12 +0100 |
| Message-ID | <87377a1nzf.fsf@bsb.me.uk> |
| In reply to | #120305 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, September 25, 2017 at 4:32:48 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
<snip>
>> > However this exposes a few weaknesses in the language. We can't force
>> > the types to be identical. We have to write the loop as a dumb
>> > bytewise copying loop to support a situation - structures with size
>> > that is an odd number of bytes - that is very unlikely to occur.
>>
>> Why does that mean the code must use a dumb byte-wise loop? For
>> example, if you know that your library memcpy is good for small
>> power-of-two sizes you might write:
>>
>> void mem_swap(void *restrict vp1, void *restrict vp2, size_t size)
>> {
>> switch (size) {
>> case 1: case 2: case 4: case 8: {
>> char t[8];
>> memcpy(&t, vp1, size);
>> memcpy(vp1, vp2, size);
>> memcpy(vp2, &t, size);
>> break;
>> }
>> default: {
>> size_t half = 1;
>> while ((half << 1) < size) half <<= 1;
>> mem_swap(vp1, vp2, half);
>> mem_swap((char *)vp1 + half, (char *)vp2 + half, size - half);
>> }}
>> }
<snip>
> That's a good memswap on top on inlineable memcpy(). Whether a compiler
> would be clever enough to make the optimisations I don't know, but at
> least there's a good chance.
If you mark mem_swap as inline, gcc -O2 generates the same code for
mem_swap(&a, &b, sizeof a);
as it does for the conventional sequence
T t = a; a = b; b = t;
when T is any of char, short, int and long (1, 2, 4 and 8 bytes
respectively on my machine).
I have no idea if it's actually fast for larger object swaps. It's hard
to time things like that on modern hardware.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web