Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #110663 > unrolled thread
| Started by | bartc <bc@freeuk.com> |
|---|---|
| First post | 2017-05-26 01:01 +0100 |
| Last post | 2017-05-28 22:15 -0700 |
| Articles | 20 on this page of 205 — 28 participants |
Back to article view | Back to comp.lang.c
C Code Quality bartc <bc@freeuk.com> - 2017-05-26 01:01 +0100
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-26 03:18 +0100
Re: C Code Quality "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-05-25 20:03 -0700
Re: C Code Quality Gareth Owen <gwowen@gmail.com> - 2017-05-26 06:32 +0100
Re: C Code Quality Richard Heathfield <rjh@cpax.org.uk> - 2017-05-26 07:24 +0100
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 11:33 +0100
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 15:16 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 14:40 +0100
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 16:42 +0200
Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 17:42 +0200
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-26 17:46 +0200
Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 19:09 +0200
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-26 19:48 +0200
Re: C Code Quality "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-26 12:05 -0400
Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 19:10 +0200
Re: C Code Quality "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-26 13:16 -0400
Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-27 02:18 +0200
Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-05-29 10:07 +0000
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 12:21 +0200
Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-05-29 12:00 +0000
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 14:23 +0200
Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 10:57 -0400
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 17:16 +0200
Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 16:53 -0400
Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-05-29 15:23 +0000
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 17:25 +0200
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-29 14:13 +0100
Re: C Code Quality Gareth Owen <gwowen@gmail.com> - 2017-05-29 14:48 +0100
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 17:14 +0200
Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 16:57 -0400
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-29 23:44 +0200
Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 19:14 -0400
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 02:57 +0200
Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 22:23 -0400
Re: C Code Quality Gareth Owen <gwowen@gmail.com> - 2017-05-30 06:54 +0100
Re: C Code Quality asetofsymbols@gmail.com - 2017-05-29 15:06 -0700
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 00:23 +0200
Re: C Code Quality asetofsymbols@gmail.com - 2017-05-29 15:33 -0700
Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 19:15 -0400
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 02:55 +0200
Re: C Code Quality Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-29 22:24 -0400
Re: C Code Quality David Kleinecke <dkleinecke@gmail.com> - 2017-05-30 15:24 -0700
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 00:48 +0200
Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-30 06:04 -0700
Re: C Code Quality scott@slp53.sl.home (Scott Lurndal) - 2017-05-30 14:21 +0000
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 17:31 +0200
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-30 17:48 +0200
Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-06-03 12:07 +0000
Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-05 13:10 -0700
Re: C Code Quality "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-30 23:46 +0200
Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-06-03 12:09 +0000
Re: C Code Quality supercat@casperkitty.com - 2017-05-26 09:09 -0700
Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 19:11 +0200
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 20:18 +0200
Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-27 02:59 +0200
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-27 14:52 +0200
Re: C Code Quality supercat@casperkitty.com - 2017-05-27 13:51 -0700
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-27 22:36 +0100
Re: C Code Quality supercat@casperkitty.com - 2017-05-28 09:38 -0700
Re: C Code Quality "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-26 20:31 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 19:47 +0100
Re: C Code Quality "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-26 21:50 +0200
Re: C Code Quality supercat@casperkitty.com - 2017-05-26 13:06 -0700
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 21:28 +0100
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 23:46 +0100
Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 17:22 +0200
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-26 17:32 +0200
Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 19:07 +0200
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-26 19:40 +0200
Re: C Code Quality supercat@casperkitty.com - 2017-05-26 08:26 -0700
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 14:29 +0100
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 16:44 +0200
Re: C Code Quality supercat@casperkitty.com - 2017-05-26 08:32 -0700
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 18:47 +0100
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 20:27 +0200
Re: C Code Quality supercat@casperkitty.com - 2017-05-26 11:24 -0700
Re: C Code Quality Ike Naar <ike@iceland.freeshell.org> - 2017-05-28 07:25 +0000
Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 17:44 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 17:31 +0100
Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-05-26 09:52 -0700
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 20:29 +0200
Re: C Code Quality "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-26 14:41 -0400
Re: C Code Quality supercat@casperkitty.com - 2017-05-26 08:22 -0700
Re: C Code Quality scott@slp53.sl.home (Scott Lurndal) - 2017-05-26 16:26 +0000
Re: C Code Quality supercat@casperkitty.com - 2017-05-26 10:06 -0700
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 20:37 +0200
Re: C Code Quality supercat@casperkitty.com - 2017-05-26 12:24 -0700
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-27 02:03 +0100
Re: C Code Quality Noob <root@127.0.0.1> - 2017-05-28 00:07 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-27 23:51 +0100
Re: C Code Quality Gareth Owen <gwowen@gmail.com> - 2017-05-28 10:52 +0100
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-28 16:03 +0200
Re: C Code Quality Philip Lantz <prl@canterey.us> - 2017-05-25 20:37 -0700
Re: C Code Quality Philip Lantz <prl@canterey.us> - 2017-05-25 20:42 -0700
C Code Quality asetofsymbols@gmail.com - 2017-05-25 23:58 -0700
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 12:53 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 12:32 +0100
Re: C Code Quality mark.bluemel@gmail.com - 2017-05-26 06:21 -0700
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 15:25 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 15:00 +0100
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 16:50 +0200
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-26 17:14 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 17:24 +0100
Re: C Code Quality scott@slp53.sl.home (Scott Lurndal) - 2017-05-26 16:46 +0000
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-26 20:47 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-27 19:31 +0100
Re: C Code Quality Noob <root@127.0.0.1> - 2017-05-27 10:52 +0200
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-28 18:57 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-28 20:00 +0100
Re: C Code Quality Ian Collins <ian-news@hotmail.com> - 2017-05-29 07:34 +1200
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-29 11:32 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-29 12:37 +0100
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-29 14:01 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-29 13:47 +0100
Re: C Code Quality Reinhardt Behm <rbehm@hushmail.com> - 2017-05-29 20:15 +0800
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-29 14:23 +0100
Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-29 17:36 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-29 17:01 +0100
Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-30 07:05 -0700
Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-30 17:18 +0200
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-30 21:31 +0200
Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-30 12:49 -0700
Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-30 13:52 -0700
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-31 12:55 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-31 13:15 +0100
Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-31 05:42 -0700
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-31 15:40 +0100
Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-31 10:52 -0700
Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-01 00:00 +0100
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 01:11 +0100
Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-01 02:21 +0100
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-06-01 10:37 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-01 11:28 +0100
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 10:55 +0100
Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-06 12:43 +0100
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-06 13:03 +0100
Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-06 14:44 +0100
Re: C Code Quality scott@slp53.sl.home (Scott Lurndal) - 2017-06-06 14:58 +0000
Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-06 17:23 +0100
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-06 17:23 +0100
Re: C Code Quality antispam@math.uni.wroc.pl - 2017-06-06 17:14 +0000
Re: C Code Quality antispam@math.uni.wroc.pl - 2017-06-06 16:54 +0000
Re: C Code Quality bartc <bc@freeuk.com> - 2017-06-06 18:49 +0100
Re: C Code Quality antispam@math.uni.wroc.pl - 2017-06-06 18:28 +0000
Re: C Code Quality antispam@math.uni.wroc.pl - 2017-06-16 15:28 +0000
Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-31 05:21 -0700
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-31 15:22 +0200
Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-31 06:59 -0700
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-05-31 17:18 +0200
Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-31 10:24 -0700
Re: C Code Quality David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 12:22 -0700
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-31 22:32 +0100
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-31 23:08 +0100
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-01 00:22 +0200
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 00:54 +0100
Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 04:00 -0700
Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-06-01 09:12 -0700
Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 10:09 -0700
Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-06-01 10:11 -0700
Re: C Code Quality David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 21:31 -0700
Re: C Code Quality David Kleinecke <dkleinecke@gmail.com> - 2017-05-31 21:27 -0700
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 11:04 +0100
Re: C Code Quality David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 10:57 -0700
Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-06-01 12:05 -0700
Re: C Code Quality "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-01 15:39 -0400
Re: C Code Quality supercat@casperkitty.com - 2017-06-01 13:39 -0700
Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-06-01 14:19 -0700
Re: C Code Quality supercat@casperkitty.com - 2017-06-01 16:33 -0700
Re: C Code Quality David Kleinecke <dkleinecke@gmail.com> - 2017-06-01 15:22 -0700
Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-06-01 17:44 -0700
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-02 02:56 +0100
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 21:24 +0100
Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 04:13 -0700
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 14:01 +0100
Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 06:53 -0700
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 15:13 +0100
Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 08:40 -0700
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-01 17:18 +0100
Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-01 14:56 -0700
Re: C Code Quality Ian Collins <ian-news@hotmail.com> - 2017-06-01 07:35 +1200
Re: C Code Quality David Brown <david.brown@hesbynett.no> - 2017-06-01 10:41 +0200
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 17:14 +0200
Re: C Code Quality Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-31 09:02 -0700
Re: C Code Quality GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-31 19:45 +0200
Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-06-03 12:17 +0000
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-30 16:32 +0100
Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-30 12:38 -0700
Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-05-30 13:00 -0700
Re: C Code Quality Thiago Adams <thiago.adams@gmail.com> - 2017-06-02 10:58 -0700
Re: C Code Quality guido <guido@invalid.invalid> - 2017-05-30 19:56 +0000
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-30 23:06 +0100
Re: C Code Quality guido <guido@invalid.invalid> - 2017-05-30 23:02 +0000
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-31 04:14 +0100
Re: C Code Quality guido <guido@invalid.invalid> - 2017-05-31 08:38 +0000
Re: C Code Quality Ian Collins <ian-news@hotmail.com> - 2017-05-30 15:22 +1200
Re: C Code Quality raltbos@xs4all.nl (Richard Bos) - 2017-05-29 10:12 +0000
Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-26 18:03 +0200
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 17:45 +0100
Re: C Code Quality Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-26 20:05 +0100
Re: C Code Quality supercat@casperkitty.com - 2017-05-26 12:42 -0700
Re: C Code Quality bartc <bc@freeuk.com> - 2017-05-26 20:19 +0100
Re: C Code Quality "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-05-27 03:03 +0200
Re: C Code Quality Keith Thompson <kst-u@mib.org> - 2017-05-26 20:37 -0700
Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-28 22:17 -0700
Re: C Code Quality Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-28 22:15 -0700
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-31 21:27 -0700 |
| Message-ID | <6d9ddb2e-b672-4cf2-af71-6c49f3bbeaf4@googlegroups.com> |
| In reply to | #111056 |
On Wednesday, May 31, 2017 at 2:32:51 PM UTC-7, Ben Bacarisse wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > <snip> > > You can write C code using only the following kinds of statements: > > compound > > labeled > > if // no else > > goto > > return > > There's no logical need for return but you do need expression > statements. (You need declarations too, but these are not statements so > maybe you were assuming they would be permitted since you spoke only > about statements.) > > And if you permit functions you can do without goto. In that model, you > can also do without if. > > > This is primitive assembly level and rightfully deplored. But I > > think it must be admitted to be C I only listed the control statements - but you are right. There are expression statements too. I can't define functions without a return statement. I don't see how one can do loops without if and goto. But if there is no goto then labels are not needed.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-06-01 11:04 +0100 |
| Message-ID | <87r2z4vxbg.fsf@bsb.me.uk> |
| In reply to | #111072 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, May 31, 2017 at 2:32:51 PM UTC-7, Ben Bacarisse wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> <snip>
>> > You can write C code using only the following kinds of statements:
>> > compound
>> > labeled
>> > if // no else
>> > goto
>> > return
>>
>> There's no logical need for return but you do need expression
>> statements. (You need declarations too, but these are not statements so
>> maybe you were assuming they would be permitted since you spoke only
>> about statements.)
>>
>> And if you permit functions you can do without goto. In that model, you
>> can also do without if.
>>
>> > This is primitive assembly level and rightfully deplored. But I
>> > think it must be admitted to be C
>
> I only listed the control statements - but you are right. There
> are expression statements too.
>
> I can't define functions without a return statement.
You just "fall off the end". This is a theoretical exercise so
convenience is not the issue and having a return value is just a matter
of convenience.
> I don't see how one can do loops without if and goto.
You need functions:
void print_seq(int n) { n > 0 && printf("%d\n", (print_seq(n-1), n)); }
> But if there is no goto then labels are not needed.
Yup.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-06-01 10:57 -0700 |
| Message-ID | <da8b3002-5fe3-4fdf-a106-b0ddbc449746@googlegroups.com> |
| In reply to | #111084 |
On Thursday, June 1, 2017 at 3:04:15 AM UTC-7, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
>
> > On Wednesday, May 31, 2017 at 2:32:51 PM UTC-7, Ben Bacarisse wrote:
> >> David Kleinecke <dkleinecke@gmail.com> writes:
> >> <snip>
> >> > You can write C code using only the following kinds of statements:
> >> > compound
> >> > labeled
> >> > if // no else
> >> > goto
> >> > return
> >>
> >> There's no logical need for return but you do need expression
> >> statements. (You need declarations too, but these are not statements so
> >> maybe you were assuming they would be permitted since you spoke only
> >> about statements.)
> >>
> >> And if you permit functions you can do without goto. In that model, you
> >> can also do without if.
> >>
> >> > This is primitive assembly level and rightfully deplored. But I
> >> > think it must be admitted to be C
> >
> > I only listed the control statements - but you are right. There
> > are expression statements too.
> >
> > I can't define functions without a return statement.
>
> You just "fall off the end". This is a theoretical exercise so
> convenience is not the issue and having a return value is just a matter
> of convenience.
>
> > I don't see how one can do loops without if and goto.
>
> You need functions:
>
> void print_seq(int n) { n > 0 && printf("%d\n", (print_seq(n-1), n)); }
>
> > But if there is no goto then labels are not needed.
>
> Yup.
Oh so. I consider that cheating under the rules I set. All you
have done is passed the loop to a recursion and, so far as I can
tell, a C function is not required to be recursive [so,
implementation-dependent] my compiler may not implement function
calls so that they are recursive.
But that is a clever trick and it feels to me exactly like how
one school of parallel programming works.
But all this is, of course, a trivial pastime. We aren't going
to go back to coding that way.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-01 12:05 -0700 |
| Message-ID | <ln7f0vplzn.fsf@kst-u.example.com> |
| In reply to | #111132 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> Oh so. I consider that cheating under the rules I set. All you
> have done is passed the loop to a recursion and, so far as I can
> tell, a C function is not required to be recursive [so,
> implementation-dependent] my compiler may not implement function
> calls so that they are recursive.
N1570 6.5.2.2p11: "Recursive function calls shall be permitted, both
directly and indirectly through any chain of other functions."
Support for recursion is not optional. (Of course compilers can
optimize code for functions that it can prove are not called
recursively.)
--
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-06-01 15:39 -0400 |
| Message-ID | <270358c1-4be8-3cd5-994d-700a881d8adb@verizon.net> |
| In reply to | #111137 |
On 06/01/2017 03:05 PM, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > [...] >> Oh so. I consider that cheating under the rules I set. All you >> have done is passed the loop to a recursion and, so far as I can >> tell, a C function is not required to be recursive [so, >> implementation-dependent] my compiler may not implement function >> calls so that they are recursive. > > N1570 6.5.2.2p11: "Recursive function calls shall be permitted, both > directly and indirectly through any chain of other functions." He said "not required", N1570 says "shall be permitted". Those are not in conflict. > Support for recursion is not optional. (Of course compilers can > optimize code for functions that it can prove are not called > recursively.) It's not at all clear to me what the point of this sub-thread is. However, I believe he's talking about code that is arbitrarily restricted to use only use a sub-set of C, so he could have specified that this sub-set does not include recursive function calls. He didn't, but he could have, and he appears to be imposing that requirement retroactively.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-06-01 13:39 -0700 |
| Message-ID | <5cb3aea6-4476-4cc5-bf07-b1f355d3d070@googlegroups.com> |
| In reply to | #111137 |
On Thursday, June 1, 2017 at 2:05:26 PM UTC-5, Keith Thompson wrote:
> David Kleinecke writes:
> [...]
> > Oh so. I consider that cheating under the rules I set. All you
> > have done is passed the loop to a recursion and, so far as I can
> > tell, a C function is not required to be recursive [so,
> > implementation-dependent] my compiler may not implement function
> > calls so that they are recursive.
>
> N1570 6.5.2.2p11: "Recursive function calls shall be permitted, both
> directly and indirectly through any chain of other functions."
>
> Support for recursion is not optional. (Of course compilers can
> optimize code for functions that it can prove are not called
> recursively.)
Given the code:
unsigned long long q(long long x)
{
if (x <= 1) return 1;
return q(x-1)+q(x-2);
}
would a conforming implementation have to be capable of evaluating
q(1000000000000000LL)? How about q(2)? So far as I can tell, either
the One Program Rule would exempt implementations from having to support
q(2) [meaning that implementations could not require that programs be
statically verifiable as non-recursive, but could behave in arbitrary
fashion if code tries to actually make a recursive call], or else the
C Standard would be impossible to implement (since it would require that
implementations be capable of evaluating function calls a quadrillion
levels deep--something it's unlikely any implementation will ever be
capable of doing).
If the Standard isn't going to require that implementations be capable of
supporting constructs in *useful* fashion, making such constructs optional
would seem to make more sense than saying that they may invoke UB.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-01 14:19 -0700 |
| Message-ID | <ln37bjpfrw.fsf@kst-u.example.com> |
| In reply to | #111145 |
supercat@casperkitty.com writes:
> On Thursday, June 1, 2017 at 2:05:26 PM UTC-5, Keith Thompson wrote:
>> David Kleinecke writes:
>> [...]
>> > Oh so. I consider that cheating under the rules I set. All you
>> > have done is passed the loop to a recursion and, so far as I can
>> > tell, a C function is not required to be recursive [so,
>> > implementation-dependent] my compiler may not implement function
>> > calls so that they are recursive.
>>
>> N1570 6.5.2.2p11: "Recursive function calls shall be permitted, both
>> directly and indirectly through any chain of other functions."
>>
>> Support for recursion is not optional. (Of course compilers can
>> optimize code for functions that it can prove are not called
>> recursively.)
>
> Given the code:
>
> unsigned long long q(long long x)
> {
> if (x <= 1) return 1;
> return q(x-1)+q(x-2);
> }
>
> would a conforming implementation have to be capable of evaluating
> q(1000000000000000LL)? How about q(2)?
[...]
N1570 1p2:
This International Standard does not specify
...
the size or complexity of a program and its data that will exceed
the capacity of any specific data-processing system or the capacity
of a particular processor;
No doubt you'd prefer the standard to have a rigorous definition
of capacity limits which would make it unambigously clear that an
implementation is required to support q(2) and is not required to
support q(1000000000000000LL).
Feel free to write that up as a set of requirements that can replace
the standard's current wording.
Also, feel free to cite a real-world implementation that claims
full conformance to the C standard (any edition) while failing to
usefully implement recursion.
--
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-06-01 16:33 -0700 |
| Message-ID | <72baeef2-0ee0-4fc2-98a8-bfc6e78afbfb@googlegroups.com> |
| In reply to | #111149 |
On Thursday, June 1, 2017 at 4:19:39 PM UTC-5, Keith Thompson wrote:
> No doubt you'd prefer the standard to have a rigorous definition
> of capacity limits which would make it unambigously clear that an
> implementation is required to support q(2) and is not required to
> support q(1000000000000000LL).
Under the present Standard, the fact that an implementation may behave in
arbitrary fashion when fed anything other than its "One Program" is merely
a quality-of-implementation issue. Thus, an inability to process any
particular program construct in useful fashion would at most indicate that
an implementation was of poor quality, and would not imply that it was
non-conforming [note that the "One Program" isn't required to use any
particular constructs in any genuinely useful fashion].
Attempting to define a set of programs which all implementations would be
required to process usefully would be difficult, and not very useful, but
that doesn't mean that UB should merely be a QoI issue. It would be much
more useful to provide means by which programs could specify what they need,
and recognize a category of implementations that would be guaranteed to
process in constrained (though not necessarily useful) fashion any program
that correctly specifies all of its requirements. Implementations would be
expected to specify environmental requirements, and would be only be allowed
to jump the rails for two reasons:
1. A program failed to specify that it needed an optional feature or
guarantee, or waived a guarantee that it actually needed.
2. The execution environment failed to meet the implementation's stated
requirements.
An implementation of that category which is fed a program that uses
recursion and does not include any directives or intrinsics related to
stack usage would have three options for processing it:
1. Analyze the program and, if the maximum recursive depth can be shown
to be within the system's abilities, run it.
2. Generate code that will terminate the program via Implementation-Defined
means in case of stack overflow (but regard execution as defined up to
that point).
3. Reject the program altogether, in Implementation-Defined fashion.
Adopting that sort of approach would eliminate the need to wrangle over
what kinds of features or guarantees compilers should support, since no
feature would impose any burden on an implementation that didn't wish to
support it beyond:
1. The implementation would need to reject programs that demand the
feature.
2. If many programs would demand the feature, people whose compilers
could easily provide it but fail to do so would have to tolerate
disdain from the programming community.
> Also, feel free to cite a real-world implementation that claims
> full conformance to the C standard (any edition) while failing to
> usefully implement recursion.
My point is not that real-world implementations in fact do such things, but
rather that the Standard as written fails to actually guarantee anything
useful about programs and implementations, beyond the fact that #error
directives must generate diagnostics that report the messages associated
therewith.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-06-01 15:22 -0700 |
| Message-ID | <f8a08dbd-541b-4ff2-af0d-35ff51f1d422@googlegroups.com> |
| In reply to | #111137 |
On Thursday, June 1, 2017 at 12:05:26 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > Oh so. I consider that cheating under the rules I set. All you
> > have done is passed the loop to a recursion and, so far as I can
> > tell, a C function is not required to be recursive [so,
> > implementation-dependent] my compiler may not implement function
> > calls so that they are recursive.
>
> N1570 6.5.2.2p11: "Recursive function calls shall be permitted, both
> directly and indirectly through any chain of other functions."
>
> Support for recursion is not optional. (Of course compilers can
> optimize code for functions that it can prove are not called
> recursively.)
I work with the C89 standard and it's not there. But it at 6.3.2.2.
I think the wording is odd - "permitted". It could be read as
lacking assurance it will work properly. But it seems clear that
the usual call method makes it hard not be recursive.
Surely there are example of C code where recursion fails. Or
is recursion now an automatic result of the implementation?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-01 17:44 -0700 |
| Message-ID | <lnr2z3nrq3.fsf@kst-u.example.com> |
| In reply to | #111162 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, June 1, 2017 at 12:05:26 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> > Oh so. I consider that cheating under the rules I set. All you
>> > have done is passed the loop to a recursion and, so far as I can
>> > tell, a C function is not required to be recursive [so,
>> > implementation-dependent] my compiler may not implement function
>> > calls so that they are recursive.
>>
>> N1570 6.5.2.2p11: "Recursive function calls shall be permitted, both
>> directly and indirectly through any chain of other functions."
>>
>> Support for recursion is not optional. (Of course compilers can
>> optimize code for functions that it can prove are not called
>> recursively.)
>
> I work with the C89 standard and it's not there.
Yes, it is. ansi.c.txt 3.3.2.2:
Recursive function calls shall be permitted, both directly and
indirectly through any chain of other functions.
C90 6.3.2.2, same wording.
K&R1, Appendix A, 7.1:
Recursive calls to any function are permitted.
And if you'd care to refer to something closer to the current language
definition: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
I'm not saying you need to *use* a more modern standard, but if you're
going to discuss the language here I suggest you should at least have
access to the current definition. (Not that it matters in the case of
this particular feature.)
> But it at 6.3.2.2.
> I think the wording is odd - "permitted". It could be read as
> lacking assurance it will work properly. But it seems clear that
> the usual call method makes it hard not be recursive.
It means that the implementation must permit programs to perform
recursive function calls.
> Surely there are example of C code where recursion fails. Or
> is recursion now an automatic result of the implementation?
Support for recursion is required by all editions of the C standard.
Capacity restrictions can cause such calls to fail in unspecified
circumstances (the same is true for all language features).
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-06-02 02:56 +0100 |
| Message-ID | <87d1anrw33.fsf@bsb.me.uk> |
| In reply to | #111178 |
Keith Thompson <kst-u@mib.org> writes: > David Kleinecke <dkleinecke@gmail.com> writes: >> On Thursday, June 1, 2017 at 12:05:26 PM UTC-7, Keith Thompson wrote: >>> David Kleinecke <dkleinecke@gmail.com> writes: >>> [...] >>> > Oh so. I consider that cheating under the rules I set. All you >>> > have done is passed the loop to a recursion and, so far as I can >>> > tell, a C function is not required to be recursive [so, >>> > implementation-dependent] my compiler may not implement function >>> > calls so that they are recursive. >>> >>> N1570 6.5.2.2p11: "Recursive function calls shall be permitted, both >>> directly and indirectly through any chain of other functions." >>> >>> Support for recursion is not optional. (Of course compilers can >>> optimize code for functions that it can prove are not called >>> recursively.) >> >> I work with the C89 standard and it's not there. > > Yes, it is. ansi.c.txt 3.3.2.2: > > Recursive function calls shall be permitted, both directly and > indirectly through any chain of other functions. > > C90 6.3.2.2, same wording. I was going to reply like this but then I saw: >> But it at 6.3.2.2. There's a word missing and a misplaced full stop but DK knows that ANSI C and C90 have the same text. The stress should be: "It's not *there* but in 6.3.2.2" -- it's only the location that's being questioned. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-06-01 21:24 +0100 |
| Message-ID | <878tlbtq07.fsf@bsb.me.uk> |
| In reply to | #111132 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, June 1, 2017 at 3:04:15 AM UTC-7, Ben Bacarisse wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>>
>> > On Wednesday, May 31, 2017 at 2:32:51 PM UTC-7, Ben Bacarisse wrote:
>> >> David Kleinecke <dkleinecke@gmail.com> writes:
>> >> <snip>
>> >> > You can write C code using only the following kinds of statements:
>> >> > compound
>> >> > labeled
>> >> > if // no else
>> >> > goto
>> >> > return
>> >>
>> >> There's no logical need for return but you do need expression
>> >> statements. (You need declarations too, but these are not statements so
>> >> maybe you were assuming they would be permitted since you spoke only
>> >> about statements.)
>> >>
>> >> And if you permit functions you can do without goto. In that model, you
>> >> can also do without if.
>> >>
>> >> > This is primitive assembly level and rightfully deplored. But I
>> >> > think it must be admitted to be C
>> >
>> > I only listed the control statements - but you are right. There
>> > are expression statements too.
>> >
>> > I can't define functions without a return statement.
>>
>> You just "fall off the end". This is a theoretical exercise so
>> convenience is not the issue and having a return value is just a matter
>> of convenience.
>>
>> > I don't see how one can do loops without if and goto.
>>
>> You need functions:
>>
>> void print_seq(int n) { n > 0 && printf("%d\n", (print_seq(n-1), n)); }
>>
>> > But if there is no goto then labels are not needed.
>>
>> Yup.
>
> Oh so. I consider that cheating under the rules I set.
You are free to do that, but I could not see any rule against it. What
part of it do your rules prohibit?
> All you
> have done is passed the loop to a recursion and, so far as I can
> tell, a C function is not required to be recursive [so,
> implementation-dependent] my compiler may not implement function
> calls so that they are recursive.
That sounds like you might think that a C compiler is not obliged to
support recursive calls. That's not the case.
What you literally say -- that a function is not obliged to be recursive
-- is obviously true, but so obviously true that "as far as I can tell"
makes no sense is relation to it.
> But that is a clever trick and it feels to me exactly like how
> one school of parallel programming works.
>
> But all this is, of course, a trivial pastime. We aren't going
> to go back to coding that way.
There's some interesting theory behind it, though, and some languages
are based on radically different models of computation exactly like
this.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-06-01 04:13 -0700 |
| Message-ID | <kfnk24wc64q.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #111056 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > David Kleinecke <dkleinecke@gmail.com> writes: > <snip> >> You can write C code using only the following kinds of statements: >> compound >> labeled >> if // no else >> goto >> return > > There's no logical need for return but you do need expression > statements. [...] Expression statements are nice, but not strictly necessary. Writing in C, all computable functions can be written using exactly one compound-statement (the outer block of main()), plus exactly one return statement.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-06-01 14:01 +0100 |
| Message-ID | <87fufjx3o7.fsf@bsb.me.uk> |
| In reply to | #111091 |
Tim Rentsch <txr@alumni.caltech.edu> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> David Kleinecke <dkleinecke@gmail.com> writes: >> <snip> >>> You can write C code using only the following kinds of statements: >>> compound >>> labeled >>> if // no else >>> goto >>> return >> >> There's no logical need for return but you do need expression >> statements. [...] > > Expression statements are nice, but not strictly necessary. > Writing in C, all computable functions can be written using > exactly one compound-statement (the outer block of main()), > plus exactly one return statement. Presumably you mean to use the return to evaluate an expression that is the computation? You can also avoid expression statements by writing what would be a statement E; like this: if (E); Labels and gotos then complete the picture. But I'm getting lost in the twisty passages. I thought the list above excluded functions. Excluding functions I don't see how you can make do with a single expression. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-06-01 06:53 -0700 |
| Message-ID | <kfnfufjddaw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #111102 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> David Kleinecke <dkleinecke@gmail.com> writes:
>>> <snip>
>>>> You can write C code using only the following kinds of statements:
>>>> compound
>>>> labeled
>>>> if // no else
>>>> goto
>>>> return
>>>
>>> There's no logical need for return but you do need expression
>>> statements. [...]
>>
>> Expression statements are nice, but not strictly necessary.
>> Writing in C, all computable functions can be written using
>> exactly one compound-statement (the outer block of main()),
>> plus exactly one return statement.
>
> Presumably you mean to use the return to evaluate an expression
> that is the computation?
Yes.
> You can also avoid expression statements by writing what would be a
> statement E; like this:
>
> if (E);
>
> Labels and gotos then complete the picture.
Ahh, I hadn't thought of that. Now that you mention it, there
is a similar trick with initializers:
int ignored = ((E), 0);
> But I'm getting lost in the twisty passages. I thought the list
> above excluded functions. Excluding functions I don't see how you
> can make do with a single expression.
No functions other than main(), which the return expression can
call recursively. Do I need to say more?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-06-01 15:13 +0100 |
| Message-ID | <87mv9rvlra.fsf@bsb.me.uk> |
| In reply to | #111104 |
Tim Rentsch <txr@alumni.caltech.edu> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Tim Rentsch <txr@alumni.caltech.edu> writes: >> >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>> >>>> David Kleinecke <dkleinecke@gmail.com> writes: >>>> <snip> >>>>> You can write C code using only the following kinds of statements: >>>>> compound >>>>> labeled >>>>> if // no else >>>>> goto >>>>> return >>>> >>>> There's no logical need for return but you do need expression >>>> statements. [...] >>> >>> Expression statements are nice, but not strictly necessary. >>> Writing in C, all computable functions can be written using >>> exactly one compound-statement (the outer block of main()), >>> plus exactly one return statement. >> >> Presumably you mean to use the return to evaluate an expression >> that is the computation? > > Yes. > >> You can also avoid expression statements by writing what would be a >> statement E; like this: >> >> if (E); >> >> Labels and gotos then complete the picture. > > Ahh, I hadn't thought of that. Now that you mention it, there > is a similar trick with initializers: > > int ignored = ((E), 0); > >> But I'm getting lost in the twisty passages. I thought the list >> above excluded functions. Excluding functions I don't see how you >> can make do with a single expression. > > No functions other than main(), which the return expression can > call recursively. Do I need to say more? No need to explain if you can treat main like any other function. Not permitting functions would, to me, mean not permitting a call to main but the whole thing is obviously open to interpretation. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-06-01 08:40 -0700 |
| Message-ID | <kfnbmq7d8ci.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #111105 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>> >>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>> >>>>> David Kleinecke <dkleinecke@gmail.com> writes: >>>>> <snip> >>>>>> You can write C code using only the following kinds of statements: >>>>>> compound >>>>>> labeled >>>>>> if // no else >>>>>> goto >>>>>> return >>>>> >>>>> There's no logical need for return but you do need expression >>>>> statements. [...] >>>> >>>> Expression statements are nice, but not strictly necessary. >>>> Writing in C, all computable functions can be written using >>>> exactly one compound-statement (the outer block of main()), >>>> plus exactly one return statement. >>> >>> Presumably you mean to use the return to evaluate an expression >>> that is the computation? >> >> Yes. >> >>> You can also avoid expression statements by writing what would be a >>> statement E; like this: >>> >>> if (E); >>> >>> Labels and gotos then complete the picture. >> >> Ahh, I hadn't thought of that. Now that you mention it, there >> is a similar trick with initializers: >> >> int ignored = ((E), 0); >> >>> But I'm getting lost in the twisty passages. I thought the list >>> above excluded functions. Excluding functions I don't see how you >>> can make do with a single expression. >> >> No functions other than main(), which the return expression can >> call recursively. Do I need to say more? > > No need to explain if you can treat main like any other function. Not > permitting functions would, to me, mean not permitting a call to main > but the whole thing is obviously open to interpretation. Hmm, maybe I missed something. I didn't realize the allowance of functions - either definitions or calls - was being called into question. There has to be at least one definition, for main(). But then if no calls are allowed, the computational model is not Turing complete. (Strictly speaking C is not Turing complete anyway, because pointers are of fixed size; but usually that is ignored when talking about Turing completeness of programming languages.) For whatever reason I unconsciously assumed function calls would be allowed (and also function definitions if they hadn't been ruled out by my stipulating the program had exactly one compound-statement). Sorry if that was confusing.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-06-01 17:18 +0100 |
| Message-ID | <87o9u7u1e4.fsf@bsb.me.uk> |
| In reply to | #111117 |
Tim Rentsch <txr@alumni.caltech.edu> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Tim Rentsch <txr@alumni.caltech.edu> writes: >> >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>> >>>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>> >>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>>> >>>>>> David Kleinecke <dkleinecke@gmail.com> writes: >>>>>> <snip> >>>>>>> You can write C code using only the following kinds of statements: >>>>>>> compound >>>>>>> labeled >>>>>>> if // no else >>>>>>> goto >>>>>>> return >>>>>> >>>>>> There's no logical need for return but you do need expression >>>>>> statements. [...] >>>>> >>>>> Expression statements are nice, but not strictly necessary. >>>>> Writing in C, all computable functions can be written using >>>>> exactly one compound-statement (the outer block of main()), >>>>> plus exactly one return statement. >>>> >>>> Presumably you mean to use the return to evaluate an expression >>>> that is the computation? >>> >>> Yes. >>> >>>> You can also avoid expression statements by writing what would be a >>>> statement E; like this: >>>> >>>> if (E); >>>> >>>> Labels and gotos then complete the picture. >>> >>> Ahh, I hadn't thought of that. Now that you mention it, there >>> is a similar trick with initializers: >>> >>> int ignored = ((E), 0); >>> >>>> But I'm getting lost in the twisty passages. I thought the list >>>> above excluded functions. Excluding functions I don't see how you >>>> can make do with a single expression. >>> >>> No functions other than main(), which the return expression can >>> call recursively. Do I need to say more? >> >> No need to explain if you can treat main like any other function. Not >> permitting functions would, to me, mean not permitting a call to main >> but the whole thing is obviously open to interpretation. > > Hmm, maybe I missed something. I didn't realize the allowance of > functions - either definitions or calls - was being called into > question. There has to be at least one definition, for main(). > But then if no calls are allowed, the computational model is not > Turing complete. Now I'm probably missing something! With only one function (main) and no explicit calls to it, the model presented by DK is Turing complete (in the limited sense, as you note, that anything can be). He made no mention of functions so I assumed that he was proposing a minimal model with one giant main function and lots of jumps. I'm guessing that when *you* say no calls are allowed, you are including the implicit call to main rather than simply banning the syntactic form of a function call expression. > (Strictly speaking C is not Turing complete > anyway, because pointers are of fixed size; but usually that is > ignored when talking about Turing completeness of programming > languages.) For whatever reason I unconsciously assumed function > calls would be allowed (and also function definitions if they > hadn't been ruled out by my stipulating the program had exactly > one compound-statement). Sorry if that was confusing. It hardly matters. So what is the minimum C dialect? With functions, you need only allow one statement per function -- a return -- and that can be the only statement type you need. No need either for in-line declarations because parameter declarations will do. With only one function, you need to allow main to be called from main. And if that is prohibited (no function-like behaviour at all), you need gotos, and since declarations can't be labeled, you need something that can be. Since 'for' statements can be labeled *and* they can include a declaration, it would be cool if you can manage with only them, but I don't think that can be made to work without compound statements. Then there's the whole question of what you can leave out of the expression syntax. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-06-01 14:56 -0700 |
| Message-ID | <kfn37bjcqxt.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #111121 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>
>>>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>>>
>>>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>>>
>>>>>>> David Kleinecke <dkleinecke@gmail.com> writes:
>>>>>>> <snip>
>>>>>>>> You can write C code using only the following kinds of statements:
>>>>>>>> compound
>>>>>>>> labeled
>>>>>>>> if // no else
>>>>>>>> goto
>>>>>>>> return
>>>>>>>
>>>>>>> There's no logical need for return but you do need expression
>>>>>>> statements. [...]
>>>>>>
>>>>>> Expression statements are nice, but not strictly necessary.
>>>>>> Writing in C, all computable functions can be written using
>>>>>> exactly one compound-statement (the outer block of main()),
>>>>>> plus exactly one return statement.
>>>>>
>>>>> Presumably you mean to use the return to evaluate an expression
>>>>> that is the computation?
>>>>
>>>> Yes.
>>>>
>>>>> You can also avoid expression statements by writing what would be a
>>>>> statement E; like this:
>>>>>
>>>>> if (E);
>>>>>
>>>>> Labels and gotos then complete the picture.
>>>>
>>>> Ahh, I hadn't thought of that. Now that you mention it, there
>>>> is a similar trick with initializers:
>>>>
>>>> int ignored = ((E), 0);
>>>>
>>>>> But I'm getting lost in the twisty passages. I thought the list
>>>>> above excluded functions. Excluding functions I don't see how you
>>>>> can make do with a single expression.
>>>>
>>>> No functions other than main(), which the return expression can
>>>> call recursively. Do I need to say more?
>>>
>>> No need to explain if you can treat main like any other function. Not
>>> permitting functions would, to me, mean not permitting a call to main
>>> but the whole thing is obviously open to interpretation.
>>
>> Hmm, maybe I missed something. I didn't realize the allowance of
>> functions - either definitions or calls - was being called into
>> question. There has to be at least one definition, for main().
>> But then if no calls are allowed, the computational model is not
>> Turing complete.
>
> Now I'm probably missing something! With only one function (main) and
> no explicit calls to it, the model presented by DK is Turing complete
> (in the limited sense, as you note, that anything can be). He made no
> mention of functions so I assumed that he was proposing a minimal model
> with one giant main function and lots of jumps. I'm guessing that when
> *you* say no calls are allowed, you are including the implicit call to
> main rather than simply banning the syntactic form of a function call
> expression.
Taking those sentences in reverse order -
What I meant was no function calls written as part of the
program, but an implicit call to main() is okay.
In reading the first message I did not assume function calls or
definitions were meant to be excluded; but, after your previous
message I am taking both to be excluded (not counting any
implicit call to main(), which hadn't occured to me until this
posting).
Considering just one function (ie, main()), and no function calls
in the body of main(), I say that computational model is not
Turing complete because the amount of memory available is fixed
by the program. To me that constraint is of a different kind
than pointers being of fixed size. I assume this distinction
came from somewhere in my past experience and it isn't something
I am simply making up now, but I don't recall what the past
experience might be. In any event I don't mean to argue a point
of view, but simply to explain my previous statement, so if you
understand my explanation then I think there is no reason to
belabor the point further.
>> (Strictly speaking C is not Turing complete
>> anyway, because pointers are of fixed size; but usually that is
>> ignored when talking about Turing completeness of programming
>> languages.) For whatever reason I unconsciously assumed function
>> calls would be allowed (and also function definitions if they
>> hadn't been ruled out by my stipulating the program had exactly
>> one compound-statement). Sorry if that was confusing.
>
> It hardly matters.
>
> So what is the minimum C dialect? With functions, you need only allow
> one statement per function -- a return -- and that can be the only
> statement type you need. No need either for in-line declarations
> because parameter declarations will do. With only one function, you
> need to allow main to be called from main. And if that is prohibited
> (no function-like behaviour at all), you need gotos, and since
> declarations can't be labeled, you need something that can be.
For Turing completeness (ie, in the sense I tried to explain
above), there needs to be a way to use additional memory. If no
functions other than main() may be defined, and calls to main()
are not allowed, additional memory could be acquired by calling
malloc(). Adding malloc() to the original list of statements,
and only one function definition (for main()), and no calls
to main(), gives a complete dialect.
> Since 'for' statements can be labeled *and* they can include a
> declaration, it would be cool if you can manage with only them, but I
> don't think that can be made to work without compound statements.
Assuming malloc() is available (and also printf() etc for I/O),
and assuming empty expression statements (eg, in 'if(1);')
don't count as expression statements, I believe all computable
functions (ignoring the limitations of pointer size) can be
written using just 'while()' statements, as illustrated by the
following example program (which reads standard input, turning
tabs into 'x's):
#include <stdio.h>
#include <stdlib.h>
#define FOO struct { int argc; char **argv; int c; }
#define F( e ) ((FOO *)(e))
#define A F(v)
int
main( int x, char *v[] ){
while( 0 ? 0
: x >= 0 ?
v[x] = malloc( sizeof (FOO) ),
v[x] ?
F( v[x] )->argc = x,
F( v[x] )->argv = v,
v = (void*) v[x],
A->argv[x] = 0,
x = -2
: (printf( "Oops, malloc() failed!\n" ), 0)
: x == -2 ?
A->c = getchar(),
A->c != EOF
? (putchar)( A->c == '\t' ? 'x' : A->c ), 1
: (x = -3)
: (printf( "All done, exiting\n" ), 0)
);
}
The FOO struct can have additional members declared, as needed.
One or more of these can be pointers to recursively grown data
structures.
> Then there's the whole question of what you can leave out of the
> expression syntax.
I will very considerately leave that question for some other
adventurous person to tackle. :)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-06-01 07:35 +1200 |
| Message-ID | <ep8k84Fuc47U1@mid.individual.net> |
| In reply to | #111030 |
On 06/ 1/17 05:24 AM, Thiago Adams wrote: > > The C++ language itself has some build-in patterns. Some patterns > can be built with templates,but others can not. > The constructor/destructor for instance, cannot be created without > the compiler help because template code cannot iterate over > all struct members. It sounds to me like you are referring to compiler generated default constructors and destructors when you say "code generation". -- Ian
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web