Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #107910 > unrolled thread
| Started by | Peabody <waybackNO584SPAM44@yahoo.com> |
|---|---|
| First post | 2017-04-08 22:59 -0500 |
| Last post | 2017-04-26 11:09 -0700 |
| Articles | 20 on this page of 245 — 33 participants |
Back to article view | Back to comp.lang.c
And they say C is obscure Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-08 22:59 -0500
Re: And they say C is obscure Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-04-08 22:17 -0600
Re: And they say C is obscure Peabody <waybackNO584SPAM44@yahoo.com> - 2017-04-09 07:42 -0500
Re: And they say C is obscure Barry Schwarz <schwarzb@dqel.com> - 2017-04-09 07:46 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-04-09 16:47 +0200
Re: And they say C is obscure James Kuyper <jameskuyper@verizon.net> - 2017-04-09 14:42 -0400
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-09 13:25 -0700
Re: And they say C is obscure James Kuyper <jameskuyper@verizon.net> - 2017-04-09 22:56 -0400
Re: And they say C is obscure Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-04-09 15:18 -0600
Re: And they say C is obscure Ken Brody <kenbrody@spamcop.net> - 2017-04-10 12:57 -0400
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-10 14:46 +0000
Re: And they say C is obscure luser droog <luser.droog@gmail.com> - 2017-04-09 07:26 -0700
Re: And they say C is obscure James Kuyper <jameskuyper@verizon.net> - 2017-04-09 14:18 -0400
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-09 20:53 +0100
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-09 13:52 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-04-14 11:48 +0000
Re: And they say C is obscure Ken Brody <kenbrody@spamcop.net> - 2017-04-14 13:36 -0400
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-04-20 13:24 +0000
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-20 08:05 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-20 15:32 +0000
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-20 09:48 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-20 18:00 +0000
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-20 11:34 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-20 18:41 +0000
Re: And they say C is obscure Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-04-09 13:18 -0700
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-09 14:03 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-09 22:56 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-04-10 09:12 +0200
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-10 08:22 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-10 18:28 +0100
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-10 17:49 +0000
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-10 11:50 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-10 20:33 +0100
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-10 13:06 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-10 21:48 +0100
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-10 22:15 +0100
Re: And they say C is obscure Michael Barry <barrym95838@yahoo.com> - 2017-04-10 18:46 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-10 21:46 +0000
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-10 23:09 +0100
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-11 12:40 +0000
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-11 14:15 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 10:13 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-26 10:38 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-10 15:23 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-04-14 11:51 +0000
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-14 13:14 +0100
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-14 10:42 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-14 19:04 +0100
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-14 21:43 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 11:02 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-26 19:05 +0100
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-04-26 12:02 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-26 21:55 +0100
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-27 00:15 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:23 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-14 18:12 +0100
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-14 18:37 +0100
Re: And they say C is obscure GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-11 00:03 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-04-10 14:10 -0700
Re: And they say C is obscure mark.bluemel@gmail.com - 2017-04-11 08:41 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-11 08:58 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-04-11 09:06 -0700
Re: And they say C is obscure scott@slp53.sl.home (Scott Lurndal) - 2017-04-11 16:46 +0000
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-04-11 19:02 +0100
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-04-14 11:59 +0000
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 10:59 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-04-27 21:40 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 05:17 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 12:50 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 01:20 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-05 12:37 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-06 00:16 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-06 11:49 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-06 13:16 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-06 14:10 -0700
Re: And they say C is obscure Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-05-06 20:23 -0600
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-06 21:51 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 05:04 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 05:09 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 05:18 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 05:54 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-05-07 13:48 +0100
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-07 06:13 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-07 15:10 +0200
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-05-07 16:47 +0200
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-07 21:08 +0200
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-05-07 21:54 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-08 00:59 +0200
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-07 16:59 -0700
Re: And they say C is obscure Robert Wessel <robertwessel2@yahoo.com> - 2017-05-07 22:28 -0500
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-08 10:16 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-08 02:41 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-08 07:36 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 10:06 +0000
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-09 14:03 +0200
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-05-09 19:41 +0200
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-09 21:35 +0200
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 20:25 +0000
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-10 14:48 +0200
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-10 14:23 +0100
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-05-10 21:31 +0200
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-10 12:45 -0700
Re: And they say C is obscure "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-10 16:49 -0400
Re: And they say C is obscure Philip Lantz <prl@canterey.us> - 2017-05-18 09:20 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-07 08:56 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-08 09:54 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-08 17:32 -0700
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-08 18:26 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-09 02:28 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 10:15 +0000
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-09 05:53 -0700
Re: And they say C is obscure bartc <bc@freeuk.com> - 2017-05-09 14:15 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-09 06:55 -0700
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-09 14:43 +0100
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-09 23:07 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-10 15:32 +0200
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-10 11:39 +0000
Re: And they say C is obscure mark.bluemel@gmail.com - 2017-05-09 06:21 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-11 03:00 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-05-09 18:20 +0100
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-10 10:06 -0700
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-10 11:11 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-10 12:45 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-10 05:33 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-10 13:41 +0100
Re: And they say C is obscure Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-10 09:32 -0400
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-10 14:51 +0100
Re: And they say C is obscure Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-10 10:54 -0400
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-10 17:36 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-10 09:28 -0700
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-10 19:12 +0100
Re: And they say C is obscure me <crisdunbar@gmail.com> - 2017-05-10 11:53 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-10 22:19 +0200
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-05-11 07:36 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-11 00:39 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-11 13:30 +0200
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-11 13:17 +0100
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-11 13:37 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-12 10:39 +0200
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 09:34 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-13 09:48 -0700
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-13 19:48 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-13 14:01 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-05-13 15:23 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-14 03:14 -0700
[OT] Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-14 12:18 +0100
Re: [OT] Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-14 13:28 +0100
Re: [OT] Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-14 15:56 +0200
Re: [OT] Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-14 16:56 +0100
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-14 02:03 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-14 03:08 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-14 13:44 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-14 16:13 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-14 08:04 -0700
Re: And they say C is obscure luser droog <luser.droog@gmail.com> - 2017-05-14 08:52 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-14 09:16 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-14 17:48 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 14:11 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-15 01:47 -0700
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-15 11:56 +0100
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-15 13:22 +0000
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 06:50 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-14 22:57 +0200
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-14 14:10 -0700
Re: And they say C is obscure "J. Clarke" <j.clarke.873638@gmail.com> - 2017-05-28 16:03 -0400
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-30 02:21 -0700
Re: And they say C is obscure "J. Clarke" <j.clarke.873638@gmail.com> - 2017-06-04 20:55 -0400
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-05 01:44 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-06-05 09:47 +0000
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-05 03:51 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-06-05 15:43 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-05 13:51 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-06-06 17:26 +0000
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-05 11:59 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-05 04:12 -0700
Re: And they say C is obscure asetofsymbols@gmail.com - 2017-06-05 05:54 -0700
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-05 15:03 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-05 07:22 -0700
Re: And they say C is obscure GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-05 16:22 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-05 07:40 -0700
Re: And they say C is obscure GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-05 16:41 +0200
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-06-05 15:44 +0100
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-05 16:12 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-05 09:08 -0700
Re: And they say C is obscure David Kleinecke <dkleinecke@gmail.com> - 2017-06-05 12:08 -0700
Re: And they say C is obscure asetofsymbols@gmail.com - 2017-06-05 13:10 -0700
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-05 23:54 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-06 01:15 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-06-06 11:10 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-06 02:39 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-06-06 12:15 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-06 03:47 -0700
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-06-06 13:09 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-06 05:26 -0700
Re: And they say C is obscure GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-06 14:25 +0200
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-06 05:34 -0700
Re: And they say C is obscure GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-06 15:41 +0200
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-06-06 15:04 +0200
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-06-06 17:37 +0000
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-06-07 10:17 +0200
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-06-06 08:49 -0700
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-06-06 19:17 +0100
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-06-06 19:16 +0100
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-06 12:44 +0100
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-06-06 17:34 +0000
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-06-06 21:14 +0200
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-06 13:10 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-06 14:34 -0700
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-06-06 15:27 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-11 16:06 -0700
Re: And they say C is obscure Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-06 12:10 +0100
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-06-06 04:36 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-06-06 17:32 +0000
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-06-05 17:58 +0200
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-14 15:51 +0200
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-05-15 18:51 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 14:04 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-11 07:45 -0700
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-11 16:45 +0100
Re: And they say C is obscure Gareth Owen <gwowen@gmail.com> - 2017-05-11 19:58 +0100
Re: And they say C is obscure Ike Naar <ike@iceland.freeshell.org> - 2017-05-11 22:15 +0000
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-11 23:24 +0100
Re: And they say C is obscure David Brown <david.brown@hesbynett.no> - 2017-05-12 10:50 +0200
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-12 09:57 +0100
Re: And they say C is obscure Jerry Stuckle <jstucklex@attglobal.net> - 2017-05-10 16:31 -0400
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-10 07:50 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-05-10 09:00 -0700
Re: And they say C is obscure Philip Lantz <prl@canterey.us> - 2017-05-18 09:31 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-05-18 11:52 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-11 03:03 -0700
Re: And they say C is obscure Keith Thompson <kst-u@mib.org> - 2017-05-11 09:02 -0700
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-05-12 18:34 +0200
Re: And they say C is obscure Richard Heathfield <rjh@cpax.org.uk> - 2017-05-12 18:47 +0100
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 09:03 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 10:11 +0000
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-09 08:28 -0700
Re: And they say C is obscure Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-09 09:40 -0700
Re: And they say C is obscure raltbos@xs4all.nl (Richard Bos) - 2017-05-09 20:26 +0000
Re: And they say C is obscure fir <profesor.fir@gmail.com> - 2017-05-10 00:20 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-08 09:01 -0700
Re: And they say C is obscure John Bode <jfbode1029@gmail.com> - 2017-04-11 09:15 -0700
Re: And they say C is obscure supercat@casperkitty.com - 2017-04-11 09:29 -0700
Re: And they say C is obscure Manfred <noname@invalid.add> - 2017-04-13 16:00 +0200
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 19:45 -0700
Re: And they say C is obscure Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 11:09 -0700
Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-20 09:48 -0700 |
| Message-ID | <ad9e6e40-52af-4137-92da-3818b1637d49@googlegroups.com> |
| In reply to | #108296 |
On Thursday, April 20, 2017 at 10:32:53 AM UTC-5, Scott Lurndal wrote:
> GCC 6.1 for arm64 produces:
...
> changing the call to 'memset' -> '__builtin_memset' produces:
>
> 0000000000000000 <test1>:
> 0: d10043ff sub sp, sp, #0x10
> 4: f90007e0 str x0, [sp,#8]
> 8: f94007e0 ldr x0, [sp,#8]
> c: f900001f str xzr, [x0]
> 10: d503201f nop
> 14: 910043ff add sp, sp, #0x10
> 18: d65f03c0 ret
ARM64 may accommodate unaligned reads, but Cortex-M0 (which is very much
a current-production part) doesn't. I'm not familiar with the ARM64
architecture, but I have no idea why it should be needing to do anything
with the stack.
Here's what gcc 5.4.1 for ARM-32 produces:
[supercat]
> >it produces better code for the second than the first.
>
> Not if you use __builtin_memset instead of memset.
I tried changing memset to __builtin_memset and the 5.4.1 for ARM32 still
generates a call to memset.
test1:
stmfd sp!, {r4, lr}
mov r2, #8
mov r1, #0
bl memset
ldmfd sp!, {r4, lr}
bx lr
test2:
mov r3, #0
strh r3, [r0] @ movhi
strh r3, [r0, #2] @ movhi
strh r3, [r0, #4] @ movhi
strh r3, [r0, #6] @ movhi
bx lr
test3:
mov r2, #0
mov r3, #0
stmia r0, {r2-r3}
bx lr
GCC may work decently on architectures that support unaligned loads and
stores, but manual optimizations seem better on those that don't.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-04-20 18:00 +0000 |
| Message-ID | <3H6KA.17020$0%5.15276@fx38.iad> |
| In reply to | #108299 |
supercat@casperkitty.com writes: >On Thursday, April 20, 2017 at 10:32:53 AM UTC-5, Scott Lurndal wrote: >> GCC 6.1 for arm64 produces: >... >> changing the call to 'memset' -> '__builtin_memset' produces: >> >> 0000000000000000 <test1>: >> 0: d10043ff sub sp, sp, #0x10 >> 4: f90007e0 str x0, [sp,#8] >> 8: f94007e0 ldr x0, [sp,#8] >> c: f900001f str xzr, [x0] >> 10: d503201f nop >> 14: 910043ff add sp, sp, #0x10 >> 18: d65f03c0 ret > >ARM64 may accommodate unaligned reads, but Cortex-M0 (which is very much >a current-production part) doesn't. I'm not familiar with the ARM64 >architecture, but I have no idea why it should be needing to do anything >with the stack. I didn't use -O2. With -O2: Disassembly of section .text: 0000000000000000 <test1>: 0: f900001f str xzr, [x0] 4: d65f03c0 ret 8: d503201f nop c: d503201f nop 0000000000000010 <test2>: 10: 7900001f strh wzr, [x0] 14: 7900041f strh wzr, [x0,#2] 18: 7900081f strh wzr, [x0,#4] 1c: 79000c1f strh wzr, [x0,#6] 20: d65f03c0 ret
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-20 11:34 -0700 |
| Message-ID | <56cf0c54-f211-4d4d-beba-92b8de5d7487@googlegroups.com> |
| In reply to | #108305 |
On Thursday, April 20, 2017 at 1:01:06 PM UTC-5, Scott Lurndal wrote: > I didn't use -O2. With -O2: > 0000000000000000 <test1>: 0: f900001f str xzr, [x0] 4: d65f03c0 ret 8: d503201f nop c: d503201f nop 0000000000000010 <test2>: 10: 7900001f strh wzr, [x0] 14: 7900041f strh wzr, [x0,#2] 18: 7900081f strh wzr, [x0,#4] 1c: 79000c1f strh wzr, [x0,#6] 20: d65f03c0 ret Those are in line with what I'd expect. On architectures where a compiler can use long stores without considering alignment it's easy to replace memset/memcpy/memmove with in-line code. Architectures with alignment restrictions seem to be another story, however. Such things are hardly uncommon in the embedded world (the Cortex M0 seems to be quite popular, for example) and I've not seen gcc apply effective chunking optimizations on such platforms.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-04-20 18:41 +0000 |
| Message-ID | <dh7KA.831$rm.179@fx01.iad> |
| In reply to | #108308 |
supercat@casperkitty.com writes: >On Thursday, April 20, 2017 at 1:01:06 PM UTC-5, Scott Lurndal wrote: >> I didn't use -O2. With -O2: >> >0000000000000000 <test1>: > 0: f900001f str xzr, [x0] > 4: d65f03c0 ret > 8: d503201f nop > c: d503201f nop > >0000000000000010 <test2>: > 10: 7900001f strh wzr, [x0] > 14: 7900041f strh wzr, [x0,#2] > 18: 7900081f strh wzr, [x0,#4] > 1c: 79000c1f strh wzr, [x0,#6] > 20: d65f03c0 ret > >Those are in line with what I'd expect. And it generated the above code if I used 'memset' instead of '__builtin_memset' when compiling with -O2.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-04-09 13:18 -0700 |
| Message-ID | <026b3f5e-2d15-4736-9cec-f31f5818ba2d@googlegroups.com> |
| In reply to | #107910 |
On Sunday, April 9, 2017 at 4:59:52 AM UTC+1, Peabody wrote: > Sorry, but I just can't find it. > > Could someone please explain this: > > for(linepos= 0; > linepos < linelen-3; linepos+= 3, dataframelen++) > > So this is parsing a TI-TXT file, which looks like this: > > @FFE0 > FF FF FF FF 14 FC FF FF FF FF 5E FD FF FF FF FF > 0E FD E6 F9 28 FD FF FF FF FF FF FF FF FF C2 FC > q > > into binary values. So the 3's make sense. > > I understand it up until the ", dataframelen++" which seems to have nothing > to do with the FOR loop. It's like "increment linepos by 3, and while you're > at it, go ahead and increment dataframelen too." Am I reading that right? > is that structure allowed in C? Well, obviously it is, but how does anyone > ever get up to speed in this language. More important, how does anyone check > for errors trying to read stuff like this? > > And while I'm at it, let me ask how you would create an unsigned byte array > exactly 2048 bytes long, and fill it with FFs. > > I guess I need to go to school for this, or give it up and go back to > assembler. It's just really hard trying to understand someone else's code. > > Thanks for any help. > The C for loop is too flexible. The form is for(<initialiser expression>; <termination expression>; <loop counter expression>) almost anything can appear in the expressions, including blanks and the packaging of several levels of logic. However most for loops are of the form for(i=0;i<1<N;i++) if you break that pattern you should have a very good reason, and normally you should not use a for (wrap the logic in a while loop instead). However there is no way of enforcing that style guide.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-09 14:03 -0700 |
| Message-ID | <lntw5xwaxt.fsf@kst-u.example.com> |
| In reply to | #107954 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> The C for loop is too flexible.
I believe that's a minority opinion.
> The form is
>
> for(<initialiser expression>; <termination expression>; <loop counter expression>)
>
> almost anything can appear in the expressions, including blanks and
> the packaging of several levels of logic.
That's one of the two forms; the other has a declaration as the first
clause. Yes, each of the three expressions can be any arbitrary
expression, or can be omitted.
> However most for loops are of the form
>
> for(i=0;i<1<N;i++)
(Typo: "i<1<N" should be "i<N".)
I'd probably write that loop as:
for (int i = 0; i < N; i ++)
unless I had to worry about pre-C99 compilers that don't support it.
It's likely that most for loops are of a form similar to that. There's
no particular reason *all* of them should be.
> if you break that pattern you should have a very good reason, and
> normally you should not use a for (wrap the logic in a while loop
> instead). However there is no way of enforcing that style guide.
The flexibility means, for example, that you can use the same construct
to iterate over a linked list:
for (node *ptr = head; node != NULL; node = node->next)
that you'd use to iterate over an array. It follows the same general
pattern: an initialization to start the iteration, a condition that
tests whether you've finished, and code to step to the next iteration.
Changing it to a while loop would not be an improvement.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-09 22:56 +0100 |
| Message-ID | <96yGA.365951$987.313962@fx20.am4> |
| In reply to | #107958 |
On 09/04/2017 22:03, Keith Thompson wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> [...]
>> The C for loop is too flexible.
>
> I believe that's a minority opinion.
A minority of at least two then.
> The flexibility means, for example, that you can use the same construct
> to iterate over a linked list:
>
> for (node *ptr = head; node != NULL; node = node->next)
>
> that you'd use to iterate over an array.
That's the trouble: it can be practically anything. If trying to
understand code (or transcribe into a generic algorithm or whatever) you
have to stop and analyse a for-statement. The header tends to be written
on one line so you also have to scan it looking for commas and
semicolons to properly identify the different parts.
Here's a nice selection from sample code:
for (x0 = 8; x0; --x0) {
for (i = 0, c = nj.comp; i < nj.ncomp; ++i, ++c) {
for (mbx = mby = 0;;) {
for (;*zTok;zTok++){
for(n=1; z[n] && z[n]!=':' && !sqlite3Isspace(z[n]); n++){}
for(i=0, n=1; zFmt[i]; i++, n++){
for(i=j=0; zFmt[i]; i++){
for(i=*pRoot; i>0; i=iNext){
for(toFree=nBlock*16; toFree<(mem3.nPool*16); toFree *= 2){
for(iFullSz=mem5.szAtom, iLogsize=0; iFullSz<nByte; iFullSz *= 2,
iLogsize++){}
for(n=0, j=mem5.aiFreelist[i]; j>=0; j = MEM5LINK(j)->next, n++){}
for(; (x=(*pre))!=0; pre++) *(--bufpt) = x;
for(idx=precision&0xfff, rounder=0.5; idx>0; idx--, rounder*=0.1){}
for(i=n=0; k!=0 && (ch=escarg[i])!=0; i++, k--){
for (workp2 = workp + coll_symbol_length ; workp < workp2 ;)
for (i = 0, j = 0; i < len0 && ! ISALPHA ((unsigned char)mangled[i]);
i += 1, j += 1)
for (acount = 0;; acount++)
for (result = &node->value.answers; *result; result = &(*result)->next)
for (; ; i--, mask >>= 1)
for (; !fake ;)
for (p = &pfile->free_buffs;; p = &(*p)->next)
for (map = &set->maps[set->used - 1]; ! MAIN_FILE_P (map);
map = INCLUDED_FROM (set, map))
Most of these are far better expressed using while, so:
for(n=0, j=mem5.aiFreelist[i]; j>=0; j = MEM5LINK(j)->next, n++){}
becomes:
n=0;
j=mem5.aiFreelist[i];
while (j>=0) {
j=MEM5LINK(j)->next;
++n;
}
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-10 09:12 +0200 |
| Message-ID | <ocfb3n$g1q$1@dont-email.me> |
| In reply to | #107962 |
On 09/04/17 23:56, bartc wrote:
> On 09/04/2017 22:03, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> [...]
>>> The C for loop is too flexible.
>>
>> I believe that's a minority opinion.
>
> A minority of at least two then.
>
>> The flexibility means, for example, that you can use the same construct
>> to iterate over a linked list:
>>
>> for (node *ptr = head; node != NULL; node = node->next)
>>
>> that you'd use to iterate over an array.
>
> That's the trouble: it can be practically anything. If trying to
> understand code (or transcribe into a generic algorithm or whatever) you
> have to stop and analyse a for-statement. The header tends to be written
> on one line so you also have to scan it looking for commas and
> semicolons to properly identify the different parts.
>
> Here's a nice selection from sample code:
>
> for (x0 = 8; x0; --x0) {
> for (i = 0, c = nj.comp; i < nj.ncomp; ++i, ++c) {
> for (mbx = mby = 0;;) {
> for (;*zTok;zTok++){
> for(n=1; z[n] && z[n]!=':' && !sqlite3Isspace(z[n]); n++){}
> for(i=0, n=1; zFmt[i]; i++, n++){
> for(i=j=0; zFmt[i]; i++){
> for(i=*pRoot; i>0; i=iNext){
> for(toFree=nBlock*16; toFree<(mem3.nPool*16); toFree *= 2){
> for(iFullSz=mem5.szAtom, iLogsize=0; iFullSz<nByte; iFullSz *= 2,
> iLogsize++){}
> for(n=0, j=mem5.aiFreelist[i]; j>=0; j = MEM5LINK(j)->next, n++){}
> for(; (x=(*pre))!=0; pre++) *(--bufpt) = x;
> for(idx=precision&0xfff, rounder=0.5; idx>0; idx--, rounder*=0.1){}
> for(i=n=0; k!=0 && (ch=escarg[i])!=0; i++, k--){
> for (workp2 = workp + coll_symbol_length ; workp < workp2 ;)
> for (i = 0, j = 0; i < len0 && ! ISALPHA ((unsigned char)mangled[i]);
> i += 1, j += 1)
> for (acount = 0;; acount++)
> for (result = &node->value.answers; *result; result = &(*result)->next)
> for (; ; i--, mask >>= 1)
> for (; !fake ;)
> for (p = &pfile->free_buffs;; p = &(*p)->next)
> for (map = &set->maps[set->used - 1]; ! MAIN_FILE_P (map);
> map = INCLUDED_FROM (set, map))
>
>
> Most of these are far better expressed using while, so:
>
> for(n=0, j=mem5.aiFreelist[i]; j>=0; j = MEM5LINK(j)->next, n++){}
>
> becomes:
>
> n=0;
> j=mem5.aiFreelist[i];
>
> while (j>=0) {
> j=MEM5LINK(j)->next;
> ++n;
> }
>
I agree here - I would prefer to see that last one as a while loop. And
the examples you picked are mostly pretty horrible - but then, they were
cherry-picked to be horrible.
The flexibility of C's for loop can be a useful thing, but it can also
be seriously abused. That does not mean the language would have been
better with a "for" syntax restricted to something like BASIC's - it
means people should stop abusing it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-10 08:22 -0700 |
| Message-ID | <lnmvbowan4.fsf@kst-u.example.com> |
| In reply to | #107962 |
bartc <bc@freeuk.com> writes:
> On 09/04/2017 22:03, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> [...]
>>> The C for loop is too flexible.
>>
>> I believe that's a minority opinion.
>
> A minority of at least two then.
>
>> The flexibility means, for example, that you can use the same construct
>> to iterate over a linked list:
>>
>> for (node *ptr = head; node != NULL; node = node->next)
>>
>> that you'd use to iterate over an array.
>
> That's the trouble: it can be practically anything. If trying to
> understand code (or transcribe into a generic algorithm or whatever)
> you have to stop and analyse a for-statement. The header tends to be
> written on one line so you also have to scan it looking for commas and
> semicolons to properly identify the different parts.
>
> Here's a nice selection from sample code:
>
> for (x0 = 8; x0; --x0) {
> for (i = 0, c = nj.comp; i < nj.ncomp; ++i, ++c) {
> for (mbx = mby = 0;;) {
> for (;*zTok;zTok++){
> for(n=1; z[n] && z[n]!=':' && !sqlite3Isspace(z[n]); n++){}
> for(i=0, n=1; zFmt[i]; i++, n++){
> for(i=j=0; zFmt[i]; i++){
> for(i=*pRoot; i>0; i=iNext){
> for(toFree=nBlock*16; toFree<(mem3.nPool*16); toFree *= 2){
> for(iFullSz=mem5.szAtom, iLogsize=0; iFullSz<nByte; iFullSz *= 2,
> iLogsize++){}
> for(n=0, j=mem5.aiFreelist[i]; j>=0; j = MEM5LINK(j)->next, n++){}
> for(; (x=(*pre))!=0; pre++) *(--bufpt) = x;
> for(idx=precision&0xfff, rounder=0.5; idx>0; idx--, rounder*=0.1){}
> for(i=n=0; k!=0 && (ch=escarg[i])!=0; i++, k--){
> for (workp2 = workp + coll_symbol_length ; workp < workp2 ;)
> for (i = 0, j = 0; i < len0 && ! ISALPHA ((unsigned char)mangled[i]);
> i += 1, j += 1)
> for (acount = 0;; acount++)
> for (result = &node->value.answers; *result; result = &(*result)->next)
> for (; ; i--, mask >>= 1)
> for (; !fake ;)
> for (p = &pfile->free_buffs;; p = &(*p)->next)
> for (map = &set->maps[set->used - 1]; ! MAIN_FILE_P (map);
> map = INCLUDED_FROM (set, map))
It isn't, and IMHO it shouldn't be, up to the standard to restrict
what kinds of expressions can appear in a for loop header. It's up
to each programmer.
The vast majority of C for loops I've seen are reasonably
straightforward.
I challenge you to come up with a consistent and reasonable
definition for the for loop that's more restrictive than the
current one. I predict that the resulting wording would be far
more complicated than what's currently in the standard, and that
it would be difficult to understand.
And any such restrictions would not make it the least bit more
difficult to write ugly and convoluted C code. So don't do that.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-10 18:28 +0100 |
| Message-ID | <chPGA.871086$qK5.426570@fx45.am4> |
| In reply to | #107997 |
On 10/04/2017 16:22, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> Here's a nice selection from sample code:
>>
>> for (x0 = 8; x0; --x0) {
>> for (i = 0, c = nj.comp; i < nj.ncomp; ++i, ++c) {
>> for (mbx = mby = 0;;) {
>> for (;*zTok;zTok++){
>> for(n=1; z[n] && z[n]!=':' && !sqlite3Isspace(z[n]); n++){}
>> for(i=0, n=1; zFmt[i]; i++, n++){
>> for(i=j=0; zFmt[i]; i++){
>> for(i=*pRoot; i>0; i=iNext){
>> for(toFree=nBlock*16; toFree<(mem3.nPool*16); toFree *= 2){
>> for(iFullSz=mem5.szAtom, iLogsize=0; iFullSz<nByte; iFullSz *= 2,
>> iLogsize++){}
>> for(n=0, j=mem5.aiFreelist[i]; j>=0; j = MEM5LINK(j)->next, n++){}
>> for(; (x=(*pre))!=0; pre++) *(--bufpt) = x;
>> for(idx=precision&0xfff, rounder=0.5; idx>0; idx--, rounder*=0.1){}
>> for(i=n=0; k!=0 && (ch=escarg[i])!=0; i++, k--){
>> for (workp2 = workp + coll_symbol_length ; workp < workp2 ;)
>> for (i = 0, j = 0; i < len0 && ! ISALPHA ((unsigned char)mangled[i]);
>> i += 1, j += 1)
>> for (acount = 0;; acount++)
>> for (result = &node->value.answers; *result; result = &(*result)->next)
>> for (; ; i--, mask >>= 1)
>> for (; !fake ;)
>> for (p = &pfile->free_buffs;; p = &(*p)->next)
>> for (map = &set->maps[set->used - 1]; ! MAIN_FILE_P (map);
>> map = INCLUDED_FROM (set, map))
>
> It isn't, and IMHO it shouldn't be, up to the standard to restrict
> what kinds of expressions can appear in a for loop header. It's up
> to each programmer.
>
> The vast majority of C for loops I've seen are reasonably
> straightforward.
I took a large file of C code at random. I went to line 123,000 and
searched for the next for-loop which was:
for(i = 0; handler_info[i].name != NULL; i++)
Explain to why that can't be written more clearly as a while-loop,
because it certainly isn't the iterative loop that 'for' (not 'forall')
is associated with in other languages:
i = 0;
while (handler_info[i].name) ++i;
In fact, explain to me what the purpose of 'while' is as hardly anyone
seems to use it! Since any while-loop:
while (cond) body
can be written as:
for (; cond ;) body
Hence my remark that you have to analyse every 'for' to identify which
category it belongs to (endless loop, repeat-n-times, loop from 0 to
N-1, loop from N-1 to 0, loop from A to B, simple while, and 'weird').
>
> I challenge you to come up with a consistent and reasonable
> definition for the for loop that's more restrictive than the
> current one. I predict that the resulting wording would be far
> more complicated than what's currently in the standard, and that
> it would be difficult to understand.
This is the for-loop from Algol-60 (iirc):
for i:=expr until expr [by expr] do body
That's more restrictive that C's, but is is that hard to understand?
> And any such restrictions would not make it the least bit more
> difficult to write ugly and convoluted C code. So don't do that.
Most of my examples above would be difficult to write using such a
restricted for-statement. You'd have to use 'while'. Which would be a
big improvement as now you /know/ any for-statement is a simple
iterative loop, while a while-statement encourages you to set up the
various parts - initialise, condition, increment - vertically rather
than lumped together on one line.
Win-win.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-04-10 17:49 +0000 |
| Message-ID | <xAPGA.157132$Jh.104188@fx17.iad> |
| In reply to | #108004 |
bartc <bc@freeuk.com> writes: >On 10/04/2017 16:22, Keith Thompson wrote: >> bartc <bc@freeuk.com> writes: >I took a large file of C code at random. I went to line 123,000 and >searched for the next for-loop which was: > > for(i = 0; handler_info[i].name != NULL; i++) > >Explain to why that can't be written more clearly as a while-loop, Clarity is in the eye of the beholder. The for loop is perfectly clear, particularly with the C90 grammar.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-10 11:50 -0700 |
| Message-ID | <lnefx0w0z1.fsf@kst-u.example.com> |
| In reply to | #108004 |
bartc <bc@freeuk.com> writes:
> On 10/04/2017 16:22, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> Here's a nice selection from sample code:
>>>
[snip examples of ugly for loops]
>>
>> It isn't, and IMHO it shouldn't be, up to the standard to restrict
>> what kinds of expressions can appear in a for loop header. It's up
>> to each programmer.
>>
>> The vast majority of C for loops I've seen are reasonably
>> straightforward.
>
> I took a large file of C code at random. I went to line 123,000 and
> searched for the next for-loop which was:
>
> for(i = 0; handler_info[i].name != NULL; i++)
>
> Explain to why that can't be written more clearly as a while-loop,
> because it certainly isn't the iterative loop that 'for' (not 'forall')
> is associated with in other languages:
>
> i = 0;
> while (handler_info[i].name) ++i;
I find the for loop at least as clear as the while loop. Of the three
clauses, the first initializes the loop, the second is the condition
under which the loop will continue, and the third steps to the next
iteration.
If you'd rather write it as a while loop, you are of course free to do
so. I note that your while loop is equivalent to the for loop only if
the for loop has an empty body. If it doesn't, the "++i;" will be part
of the body of the while loop, and not clearly distinguished from the
rest of the body.
I understand that you find the while loop clearer. I find the for loop
clearer. I don't expect either of us to change our minds.
> In fact, explain to me what the purpose of 'while' is as hardly anyone
> seems to use it! Since any while-loop:
>
> while (cond) body
>
> can be written as:
>
> for (; cond ;) body
C *could* have omitted the while loop, or the for loop. It could have
omitted all control structures other than conditional gotos. C's for
loop encapsulates three aspects of loop control that I personally find
useful and clear.
I generally wouldn't use a for loop when the first and third clauses are
omitted; I'd use a while loop. If the first *or* third clause is
omitted, I'd have to consider it on a case-by-case basis.
Now if you assume that a loop with the name "for" has to correspond to
the kind of for loop you'll find in, say, Pascal or Algol, then C's for
loop is going to be confusing. Perhaps you'd find it clearer if it had
a different name?
> Hence my remark that you have to analyse every 'for' to identify which
> category it belongs to (endless loop, repeat-n-times, loop from 0 to
> N-1, loop from N-1 to 0, loop from A to B, simple while, and 'weird').
And that analysis shouldn't be difficult -- *if* the code is written
clearly. If it's not written clearly, then it doesn't matter what
language construct it uses.
>> I challenge you to come up with a consistent and reasonable
>> definition for the for loop that's more restrictive than the
>> current one. I predict that the resulting wording would be far
>> more complicated than what's currently in the standard, and that
>> it would be difficult to understand.
>
> This is the for-loop from Algol-60 (iirc):
>
> for i:=expr until expr [by expr] do body
>
> That's more restrictive that C's, but is is that hard to understand?
No, it's easy to understand -- and it's far more restrictive than
C's for loop. If you want to restrict C's for loop that severely,
disallowing anything other than stepping through a uniform sequence
of integer values, that's a valid opinion. I disagree, and your
proposal will break existing code. What you propose is not what
C's for loop means.
>> And any such restrictions would not make it the least bit more
>> difficult to write ugly and convoluted C code. So don't do that.
>
> Most of my examples above would be difficult to write using such a
> restricted for-statement. You'd have to use 'while'. Which would be a
> big improvement as now you /know/ any for-statement is a simple
> iterative loop, while a while-statement encourages you to set up the
> various parts - initialise, condition, increment - vertically rather
> than lumped together on one line.
>
> Win-win.
It would break existing code. No such change will ever happen in a
language called "C". Lose-lose.
Again, your opinion that C's for loop is too complicated is perfectly
valid, even though I don't share it. You're free to restrict your own
use as you like, and/or to implement your own preferred ideas in your
own language.
I seriously doubt that there's anything meaningful left to be said.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-10 20:33 +0100 |
| Message-ID | <86RGA.516614$jb5.255164@fx25.am4> |
| In reply to | #108009 |
On 10/04/2017 19:50, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> i = 0;
>> while (handler_info[i].name) ++i;
>
> I find the for loop at least as clear as the while loop. Of the three
> clauses, the first initializes the loop, the second is the condition
> under which the loop will continue, and the third steps to the next
> iteration.
But you wouldn't put three, especially disjoint, statements on the same
line; they'd be arranged vertically. (Apart from the slightly liberty I
took above. But there, the ")" is a strong separator; the ";" is a weak
separator especially if the things on each side are not executed
sequentially.)
> If you'd rather write it as a while loop, you are of course free to do
> so. I note that your while loop is equivalent to the for loop only if
> the for loop has an empty body.
The original had an empty body; I forgot to show the ";" which was on
the next line.
> C *could* have omitted the while loop, or the for loop.
It could have omitted the while loop as 'for' can do everything while
can. Especially using:
#define while(x) for (;(x);)
Leaving out 'for' wouldn't have been a great loss, as it is hardly a
proper 'for' statement with the special language support that normally
entails. But it would be inconvenient when you /do/ want a simple
iteration. And for those who do show some restraint and use whichever of
'for' and 'while' is most appropriate.
> It could have
> omitted all control structures other than conditional gotos.
No, there is no good reason for that. Syntax of this kind is the
simplest possible thing to add to a language.
(In my C compiler, support for 'while' adds 30 lines of code to the
program, out of about 18,000. A C99 'for' needed over 100 because it's
fiddly.)
> C's for
> loop encapsulates three aspects of loop control that I personally find
> useful and clear.
For an iterative loop, these are aspects you shouldn't need to worry
about. A 'for' /implies/ iteration; you shouldn't have to write it
explicitly!
>Perhaps you'd find it clearer if it had
> a different name?
'for' is misleading, that's for sure.
> And that analysis shouldn't be difficult -- *if* the code is written
> clearly. If it's not written clearly, then it doesn't matter what
> language construct it uses.
No, the language can force the issue by not allowing you to write
obscure code, not in loops anyway. If absolutely anything can go inside
a for-loop, then obviously people will take advantage:
for(i=rand(), j=rand(), printf("%d\n",(i+j)/2);0;);
(A weak attempt as I don't have the imagination to do this stuff properly.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-10 13:06 -0700 |
| Message-ID | <lna87ovxho.fsf@kst-u.example.com> |
| In reply to | #108010 |
bartc <bc@freeuk.com> writes:
> On 10/04/2017 19:50, Keith Thompson wrote:
[...]
>> C *could* have omitted the while loop, or the for loop.
>
> It could have omitted the while loop as 'for' can do everything while
> can. Especially using:
>
> #define while(x) for (;(x);)
>
> Leaving out 'for' wouldn't have been a great loss, as it is hardly a
> proper 'for' statement with the special language support that normally
> entails.
I think that's the root of your objection. You insist on a "for" loop
being similar to the "for" loop that's seen in Algol and Pascal. It
isn't. It could have been called, say, "iterate" with exactly the same
meaning.
I suggest that your use of the word "proper" has no significance.
The extra flexibility of C's for loop relative to Pascal's is
entirely deliberate. The fact that you don't like it is, yet again,
perfectly valid, but not particularly relevant to anthing other
than your own personal preferences.
>> It could have
>> omitted all control structures other than conditional gotos.
>
> No, there is no good reason for that. Syntax of this kind is the
> simplest possible thing to add to a language.
I didn't say there would be a good reason. I merely meant that omitting
all control structures other than conditional gotos would in principal
leave us with a language that could express everything C can express.
(The resulting language would not be one that I would care to use.)
[...]
>>Perhaps you'd find it clearer if it had
>> a different name?
>
> 'for' is misleading, that's for sure.
It misleads you. It doesn't mislead most of the rest of us.
There is no solvable problem here.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-04-10 21:48 +0100 |
| Message-ID | <87k26sugy2.fsf@gmail.com> |
| In reply to | #108011 |
Keith Thompson <kst-u@mib.org> writes: > bartc <bc@freeuk.com> writes: >> 'for' is misleading, that's for sure. > > It misleads you. It doesn't mislead most of the rest of us. That's because he's an idiot. > There is no solvable problem here. You could stop responding to his idiocy.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-10 22:15 +0100 |
| Message-ID | <SBSGA.373491$ez1.265112@fx32.am4> |
| In reply to | #108011 |
On 10/04/2017 21:06, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > I think that's the root of your objection. You insist on a "for" loop > being similar to the "for" loop that's seen in Algol and Pascal. It > isn't. It could have been called, say, "iterate" with exactly the same > meaning. > > I suggest that your use of the word "proper" has no significance. Have a look at this simple looping task here: http://rosettacode.org/wiki/Loops/For Out of 170 languages, just over 30 have C-style for-loop. Nearly 80 have something that looks like an Algol-style loop. (The other 60 did their own thing or I couldn't categorise them at a glance.) The C-style loops were easy to spot; without exception: * The 'i' outer loop control had to be specified three times * The increment op had to be specified explicitly * The loop-terminating condition had to be specified explicitly. More of a DIY for-loop if you ask me; the language hasn't left much to do! (This is what a compiler is for; why not use it?) The looping task here is so common that one would expect a language to provide a dedicated feature for that. Most of these do, but unfortunately the more popular ones seem to have gone the C route. (It doesn't seem to have occurred to anyone (except a few of these languages) that you can have both a dedicated for-loop /and/ a flexible 'loop' like C's.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2017-04-10 18:46 -0700 |
| Message-ID | <e9fcd9b1-821e-42bc-a6b9-780247ea647a@googlegroups.com> |
| In reply to | #108015 |
On Monday, April 10, 2017 at 2:15:45 PM UTC-7, Bart wrote: > On 10/04/2017 21:06, Keith Thompson wrote: > > bartc <***********> writes: > > > I think that's the root of your objection. You insist on a "for" loop > > being similar to the "for" loop that's seen in Algol and Pascal. It > > isn't. It could have been called, say, "iterate" with exactly the same > > meaning. > > > > I suggest that your use of the word "proper" has no significance. > > Have a look at this simple looping task here: > > http://rosettacode.org/wiki/Loops/For > > Out of 170 languages, just over 30 have C-style for-loop. Nearly 80 have > something that looks like an Algol-style loop. (The other 60 did their > own thing or I couldn't categorise them at a glance.) > > The C-style loops were easy to spot; without exception: > > * The 'i' outer loop control had to be specified three times > > * The increment op had to be specified explicitly > > * The loop-terminating condition had to be specified explicitly. > > More of a DIY for-loop if you ask me; the language hasn't left much to > do! (This is what a compiler is for; why not use it?) > > The looping task here is so common that one would expect a language to > provide a dedicated feature for that. Most of these do, but > unfortunately the more popular ones seem to have gone the C route. > > (It doesn't seem to have occurred to anyone (except a few of these > languages) that you can have both a dedicated for-loop /and/ a flexible > 'loop' like C's.) > > -- > bartc http://rosettacode.org/wiki/99_Bottles_of_Beer#Bottled_Version_2 Mike B. :-)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-04-10 21:46 +0000 |
| Message-ID | <n3TGA.5$N93.4@fx06.iad> |
| In reply to | #108011 |
Keith Thompson <kst-u@mib.org> writes: >bartc <bc@freeuk.com> writes: >> Leaving out 'for' wouldn't have been a great loss, as it is hardly a >> proper 'for' statement with the special language support that normally >> entails. > >I think that's the root of your objection. You insist on a "for" loop >being similar to the "for" loop that's seen in Algol and Pascal. It >isn't. It could have been called, say, "iterate" with exactly the same >meaning. Actually, I consider the C 'for' construct to be a natural extension of the ALGOL and Pascal FOR constructs. They all provide an initial condition, a terminal condition and an optional step condition. Pascal, e.g., limits the initial condition to be a numeric (or enumeration) which limits the usefuless of the construct.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-10 23:09 +0100 |
| Message-ID | <ZnTGA.409110$FF4.398340@fx27.am4> |
| In reply to | #108016 |
On 10/04/2017 22:46, Scott Lurndal wrote:
> Keith Thompson <kst-u@mib.org> writes:
>> bartc <bc@freeuk.com> writes:
>
>>> Leaving out 'for' wouldn't have been a great loss, as it is hardly a
>>> proper 'for' statement with the special language support that normally
>>> entails.
>>
>> I think that's the root of your objection. You insist on a "for" loop
>> being similar to the "for" loop that's seen in Algol and Pascal. It
>> isn't. It could have been called, say, "iterate" with exactly the same
>> meaning.
>
> Actually, I consider the C 'for' construct to be a natural
> extension of the ALGOL and Pascal FOR constructs. They all
> provide an initial condition, a terminal condition and an
> optional step condition.
I can't see any connection (apart from the use of the "for" keyword). C
provides a general purpose, lower level construct that can emulate a For
statement from those other languages. But it is more effort, is more
error prone, and has to be done manually.
A extension of those other For statements might be more the sorts of
things that Python allows with For: general purpose iteration over the
values in a range or a list. Much more disciplined than the C
counterpart which allows literally anything:
for (i=0,j=1; rand()!=12345; x[++k]='A'){}
What are the start and end values of the loop index? You can't answer
because there is /no/ loop index. And you can't tell how many iterations
this will do.
--
BARTC
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-04-11 12:40 +0000 |
| Message-ID | <f94HA.155$7O5.87@fx36.iad> |
| In reply to | #108018 |
bartc <bc@freeuk.com> writes:
>On 10/04/2017 22:46, Scott Lurndal wrote:
>>
>> Actually, I consider the C 'for' construct to be a natural
>> extension of the ALGOL and Pascal FOR constructs. They all
>> provide an initial condition, a terminal condition and an
>> optional step condition.
>
>
>for (i=0,j=1; rand()!=12345; x[++k]='A'){}
Initial condition: i=0, j=1;
Terminal condition: rand() != 12345
Step condition: x[++k]='A'
It's pretty damn clear.
>
>What are the start and end values of the loop index? You can't answer
>because there is /no/ loop index. And you can't tell how many iterations
>this will do.
Nor can you tell, a priori, with "do until" or "while" constructs. So what?
[toc] | [prev] | [next] | [standalone]
Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web