Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #60096 > unrolled thread
| Started by | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| First post | 2015-04-15 11:46 -0700 |
| Last post | 2015-04-30 01:40 -0700 |
| Articles | 20 on this page of 318 — 32 participants |
Back to article view | Back to comp.lang.c
Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 11:46 -0700
Re: Readability part I - code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-15 19:55 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:00 -0700
Re: Readability part I - code Xcott Craver <xcottcraver@gmail.com> - 2015-04-15 13:19 -0700
Re: Readability part I - code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-16 13:08 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:25 -0700
Re: Readability part I - code pa@see.signature.invalid (Pierre Asselin) - 2015-04-16 01:01 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:37 -0700
Re: Readability part I - code pa@see.signature.invalid (Pierre Asselin) - 2015-05-01 02:07 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 04:29 -0700
Readability part I - code asetofsymbols@gmail.com - 2015-04-16 00:13 -0700
Readability part I - code asetofsymbols@gmail.com - 2015-04-16 00:34 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:46 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-04-30 05:54 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 04:37 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-01 11:48 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-02 23:59 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-08 20:52 +0000
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-08 16:15 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-09 16:14 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 09:11 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 00:19 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 02:51 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-30 20:14 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 05:10 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-01 06:10 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 09:17 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-16 11:01 +0200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-16 04:26 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-04-16 13:19 -0500
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-17 09:20 +0200
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-04-17 08:21 -0400
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-17 15:04 +0200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 06:18 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-04-17 12:24 -0500
Re: Readability part I - code Greg Martin <greg.at.softsprocket@dot.com> - 2015-04-17 15:58 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 04:10 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-30 13:47 +0200
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-04-30 13:48 +0100
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-30 16:35 +0200
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-04-30 10:00 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 06:25 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-02 15:53 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 10:42 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-04 09:41 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 07:01 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-06 09:34 +0200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-06 04:33 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-06 13:51 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 11:51 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-07 21:49 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 13:22 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-06 15:27 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-06 09:11 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-06 21:00 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-07 00:20 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-06 10:43 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-06 13:11 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 19:48 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-07 11:51 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 12:26 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-07 16:52 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-07 20:22 -0500
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-08 02:56 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-08 10:53 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 18:30 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-08 09:27 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-08 11:06 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-09 09:31 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-10 08:01 +1200
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-09 13:13 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-10 08:51 +1200
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-09 16:45 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 13:28 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 19:36 -0700
Re: Readability part I - code Robert Wessel <robertwessel2@yahoo.com> - 2015-05-06 22:13 -0500
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-07 11:56 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 14:16 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 11:43 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 12:02 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-07 13:36 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 15:09 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-07 17:13 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-07 18:07 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-05-08 11:35 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 11:41 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 13:59 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-10 10:27 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-10 10:50 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-10 19:09 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 04:54 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 13:19 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-12 05:26 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 08:31 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 16:40 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 10:28 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-10 11:39 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 05:33 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-07 17:59 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 09:20 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:37 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:40 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:46 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-11 09:53 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 13:47 -0500
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-11 20:04 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-11 12:39 -0700
Re: Readability part I - code Nathan Wagner <nw@hydaspes.if.org> - 2015-05-12 07:34 +0000
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-12 10:58 +0000
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-11 21:00 +0100
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-11 21:18 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-11 23:37 +0100
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 00:07 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-11 16:52 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 01:19 +0100
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 01:43 +0100
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-12 11:00 +0000
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 12:33 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 13:25 +0100
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:01 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 08:26 -0700
Re: Readability part I - code Ike Naar <ike@iceland.freeshell.org> - 2015-05-14 19:58 +0000
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-14 20:15 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 07:25 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-21 08:50 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-25 02:06 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-25 09:25 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 07:35 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 15:53 +0100
Re: Readability part I - code Martin Shobe <martin.shobe@yahoo.com> - 2015-07-10 10:20 -0500
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 16:30 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 10:49 -0700
Re: Readability part I - code Philip Lantz <prl@canterey.us> - 2015-07-10 11:19 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 07:47 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-13 20:20 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 02:57 -0700
Re: Readability part I - code "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-13 12:27 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 03:21 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-15 17:35 +0000
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-07-15 18:46 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-15 11:35 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 08:47 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-20 21:24 +0000
Re: Readability part I - code Richard Damon <Richard@Damon-Family.org> - 2015-07-21 08:43 -0400
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-07-21 13:26 -0400
Re: Readability part I - code Richard Damon <Richard@Damon-Family.org> - 2015-07-21 22:11 -0400
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-22 04:03 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 02:30 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-22 07:14 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 08:24 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-21 23:39 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-22 11:51 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-23 07:35 +1200
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 06:36 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 07:25 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 08:44 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-10 16:53 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:57 -0700
Re: Readability part I - code Öö Tiib <ootiib@hot.ee> - 2015-05-23 06:27 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-23 16:07 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-23 19:10 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 06:25 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-24 12:24 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 22:49 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 12:49 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 22:56 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 09:07 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 17:29 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:52 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-11 19:45 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 04:27 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-15 17:50 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 08:48 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:21 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-23 21:30 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-26 11:30 -0700
Re: Readability part I - code Robert Wessel <robertwessel2@yahoo.com> - 2015-07-26 16:16 -0500
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-26 23:04 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 15:15 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 09:12 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-12 17:28 +1200
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 11:09 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 11:43 +0100
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-12 05:16 -0700
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-12 05:34 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-05-12 22:52 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 03:45 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-21 12:53 +0100
Re: Readability part I - code asetofsymbols@gmail.com - 2015-05-21 11:01 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-21 20:18 +0100
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-21 21:47 +0100
Re: Readability part I - code Kusalananda <kusalananda@example.com> - 2015-05-24 07:12 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:59 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 09:18 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-22 07:15 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:53 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-07-11 14:09 +1200
Re: Readability part I - code Reinhardt Behm <rbehm@hushmail.com> - 2015-07-11 10:37 +0800
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 12:51 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-07-12 10:20 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 07:23 -0700
Re: Readability part I - code jadill33@gmail.com - 2015-05-11 13:30 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-11 21:56 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 23:14 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 08:15 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 16:38 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-12 11:38 -0500
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 17:58 +0100
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-12 13:44 -0500
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-12 11:32 -0500
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-12 11:14 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 03:27 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-21 08:41 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 18:12 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-05-24 19:20 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:51 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 11:35 -0700
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-07-10 14:54 -0400
Re: Readability part I - code James Kuyper <jameskuyper@verizon.net> - 2015-07-10 15:10 -0400
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 20:51 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 13:22 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 20:47 +0000
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 17:05 -0700
Re: Readability part I - code Rosario19 <Ros@invalid.invalid> - 2015-07-11 11:04 +0200
Re: Readability part I - code Reinhardt Behm <rbehm@hushmail.com> - 2015-07-11 18:06 +0800
Re: Readability part I - code Rosario19 <Ros@invalid.invalid> - 2015-07-11 14:57 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 09:20 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-11 20:06 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 04:55 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-11 13:26 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 06:29 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 13:49 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-21 07:12 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-21 15:26 +0000
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-22 11:36 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 13:50 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-24 23:01 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:42 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 17:37 +0000
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-07-10 10:59 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 16:47 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-16 17:03 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 06:52 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 11:23 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 23:52 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-20 09:29 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-24 14:56 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 08:30 -0700
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-10 11:04 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-07-10 18:39 -0500
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 17:02 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-11 01:23 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 17:48 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 10:50 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 06:55 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 15:23 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 08:14 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 07:53 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 22:04 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 14:51 -0700
Re: Readability part I - code Richard Damon <Richard@Damon-Family.org> - 2015-07-11 20:05 -0400
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:31 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 18:24 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 19:00 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-13 13:24 +0100
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-13 06:11 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 23:09 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-11 23:21 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-11 17:35 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:43 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 10:31 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 16:12 +0100
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 18:02 +0100
Re: Readability part I - code Philip Lantz <prl@canterey.us> - 2015-07-12 11:16 -0700
Re: Readability part I - code Bartc <bc@freeuk.com> - 2015-07-12 21:06 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 15:44 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 16:15 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 13:50 -0700
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-11 20:13 +0000
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 23:01 +0100
Re: Readability part I - code Keith Thompson <kst-u@mib.org> - 2015-07-11 17:28 -0700
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:53 +0100
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 00:45 +0000
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-12 01:55 +0100
Re: Readability part I - code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 02:44 +0000
Re: Readability part I - code Robert Wessel <robertwessel2@yahoo.com> - 2015-07-12 16:51 -0500
Re: Readability part I - code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-11 10:25 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 07:52 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-07-11 09:25 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 13:15 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-08 16:15 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-11 11:35 -0700
Re: Readability part I - code Stephen Sprunk <stephen@sprunk.org> - 2015-05-11 23:56 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-12 11:53 -0700
Re: Readability part I - code Richard Heathfield <rjh@cpax.org.uk> - 2015-05-12 20:01 +0100
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 07:09 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:12 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 07:43 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-25 14:51 -0700
Re: Readability part I - code raltbos@xs4all.nl (Richard Bos) - 2015-05-26 09:17 +0000
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-10 07:44 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 03:19 -0700
Re: Readability part I - code David Brown <david.brown@hesbynett.no> - 2015-04-30 14:04 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-01 08:07 -0700
Re: Readability part I - code Ian Collins <ian-news@hotmail.com> - 2015-05-02 09:18 +1200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 10:10 -0700
Re: Readability part I - code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-03 10:43 -0700
Re: Readability part I - code Melzzzzz <mel@zzzzz.com> - 2015-05-03 19:47 +0200
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-03 13:40 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-04 12:10 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 06:45 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-05 09:06 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-05 20:27 -0700
Re: Readability part I - code David Kleinecke <dkleinecke@gmail.com> - 2015-05-06 10:33 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-06 19:33 -0700
Re: Readability part I - code Les Cargill <lcargill99@comcast.com> - 2015-04-16 12:28 -0500
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 03:42 -0700
Re: Readability part I - code Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-30 01:40 -0700
Page 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-07 12:26 -0700 |
| Message-ID | <87zj5gi3y7.fsf@kst-u.example.com> |
| In reply to | #61708 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Wednesday, May 6, 2015 at 7:48:57 PM UTC-7, Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>> > (A digression: The form of `sizeof` that applies to a parenthesized
>> > type name isn't something I'd call an operator, since its "operand"
>> > isn't a expression. I'd call it a special form of expression,
>> > disinct from the `sizeof expr` form. But the standard calls it a
>> > unary operator in both forms, so I'll go along with it.)
>>
>> IMO it's better in this context to think of a type-name as an
>> unusual form of operand.
>>
>> Also, you might want to consider, eg, 'sizeof (int[ n++ ])', where
>> evaluating the type-name has semantic consequences.
>
> I assume you mean "if you treat sizeof as a function". As I
> understand it all that matters in a "sizeof (...) is the type of
> the value in .... The "n++" should be ignored.
Did you miss the fact that the operand is a parenthesized type name,
and the type happens to be a VLA?
N1570 6.5.3.4p2:
If the type of the operand is a variable length array type, the
operand is evaluated; otherwise, the operand is not evaluated
and the result is an integer constant.
Evaluating `sizeof (int[n++])` does in fact cause `n` to be
incremented. (It's also ugly code that nobody should every write,
but compiler implementers don't have the luxury of assuming that
nobody ever will.)
The idea of "evaluating" a type name is a bit iffy, but in this
case the semantics are IMHO clear enough. At the very least, the
value of n must be determined to determine the size of `int[n++]`.
Determining the value of n without evaluating `n++` would be strange.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-05-07 16:52 -0700 |
| Message-ID | <98ec92b2-4a80-44c8-9647-897c61262427@googlegroups.com> |
| In reply to | #61716 |
On Thursday, May 7, 2015 at 8:27:04 PM UTC+1, Keith Thompson wrote: > > The idea of "evaluating" a type name is a bit iffy, but in this > case the semantics are IMHO clear enough. At the very least, the > value of n must be determined to determine the size of `int[n++]`. > Determining the value of n without evaluating `n++` would be strange. > C doesn't have a typename type. So there's no typeof keyword. But if you did add it, it would be natural to have functions like maxval, minval, epsilon, levels_of_indirection and so on that took typenames.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-07 20:22 -0500 |
| Message-ID | <mih32t$b0o$1@dont-email.me> |
| In reply to | #61736 |
On 07-May-15 18:52, Malcolm McLean wrote: > On Thursday, May 7, 2015 at 8:27:04 PM UTC+1, Keith Thompson wrote: >> The idea of "evaluating" a type name is a bit iffy, but in this >> case the semantics are IMHO clear enough. At the very least, the >> value of n must be determined to determine the size of `int[n++]`. >> Determining the value of n without evaluating `n++` would be >> strange. > > C doesn't have a typename type. So there's no typeof keyword. But if > you did add it, it would be natural to have functions like maxval, > minval, epsilon, levels_of_indirection and so on that took typenames. Many/most of those would also make sense if they were operators that worked the same way as sizeof, which could eliminate a lot of the cruft in <limits.h>. I'd much rather write "maxvalof var" than have to look up what type "var" is and then use something like MAX_INT, which could become wrong when someone changes "var"'s type later. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-05-08 02:56 +0100 |
| Message-ID | <87y4kzvnm3.fsf@bsb.me.uk> |
| In reply to | #61741 |
Stephen Sprunk <stephen@sprunk.org> writes: > On 07-May-15 18:52, Malcolm McLean wrote: >> On Thursday, May 7, 2015 at 8:27:04 PM UTC+1, Keith Thompson wrote: >>> The idea of "evaluating" a type name is a bit iffy, but in this >>> case the semantics are IMHO clear enough. At the very least, the >>> value of n must be determined to determine the size of `int[n++]`. >>> Determining the value of n without evaluating `n++` would be >>> strange. >> >> C doesn't have a typename type. So there's no typeof keyword. But if >> you did add it, it would be natural to have functions like maxval, >> minval, epsilon, levels_of_indirection and so on that took typenames. > > Many/most of those would also make sense if they were operators that > worked the same way as sizeof, which could eliminate a lot of the cruft > in <limits.h>. > > I'd much rather write "maxvalof var" than have to look up what type > "var" is and then use something like MAX_INT, which could become wrong > when someone changes "var"'s type later. You'd write maxvalof typeof var if maxvalof only worked with types. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-05-08 10:53 -0500 |
| Message-ID | <miim3s$n7m$1@dont-email.me> |
| In reply to | #61743 |
On 07-May-15 20:56, Ben Bacarisse wrote: > Stephen Sprunk <stephen@sprunk.org> writes: >> On 07-May-15 18:52, Malcolm McLean wrote: >>> C doesn't have a typename type. So there's no typeof keyword. But >>> if you did add it, it would be natural to have functions like >>> maxval, minval, epsilon, levels_of_indirection and so on that >>> took typenames. >> >> Many/most of those would also make sense if they were operators >> that worked the same way as sizeof, which could eliminate a lot of >> the cruft in <limits.h>. >> >> I'd much rather write "maxvalof var" than have to look up what >> type "var" is and then use something like MAX_INT, which could >> become wrong when someone changes "var"'s type later. > > You'd write maxvalof typeof var if maxvalof only worked with types. See "if they were operators that worked the same was as sizeof"; since sizeof can be applied to both types and variables, then I am assuming that maxvalof could be as well. It doesn't seem like that would be any harder to specify or implement, so just follow the precedent. typeof would also be useful, but as someone said, that would mean adding a typename type, which would be a much more significant change to the core language. Unless it could only be used in cases like this, which would severely limit its usefulness: T a; ... typeof(a) b; S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-07 18:30 -0700 |
| Message-ID | <87egmrj1o1.fsf@kst-u.example.com> |
| In reply to | #61736 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, May 7, 2015 at 8:27:04 PM UTC+1, Keith Thompson wrote:
>> The idea of "evaluating" a type name is a bit iffy, but in this
>> case the semantics are IMHO clear enough. At the very least, the
>> value of n must be determined to determine the size of `int[n++]`.
>> Determining the value of n without evaluating `n++` would be strange.
>>
> C doesn't have a typename type.
> So there's no typeof keyword. But if you did add it, it would be natural
> to have functions like maxval, minval, epsilon, levels_of_indirection
> and so on that took typenames.
Ada has something similar, but using a special syntactic form called
"attributes". In some cases, attributes can even designate functions
rather than values. The prefix can be a type, an expression, an object
name, etc.
For example, the maximum value of the type Integer is Integer'Last; its
size in bits is Integer'Size.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-08 09:27 -0700 |
| Message-ID | <8dfc1d75-5a34-4380-bab8-a3fd7e1244ed@googlegroups.com> |
| In reply to | #61716 |
On Thursday, May 7, 2015 at 12:27:04 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> > On Wednesday, May 6, 2015 at 7:48:57 PM UTC-7, Tim Rentsch wrote:
> >> Keith Thompson <kst-u@mib.org> writes:
> >>
> >> > (A digression: The form of `sizeof` that applies to a parenthesized
> >> > type name isn't something I'd call an operator, since its "operand"
> >> > isn't a expression. I'd call it a special form of expression,
> >> > disinct from the `sizeof expr` form. But the standard calls it a
> >> > unary operator in both forms, so I'll go along with it.)
> >>
> >> IMO it's better in this context to think of a type-name as an
> >> unusual form of operand.
> >>
> >> Also, you might want to consider, eg, 'sizeof (int[ n++ ])', where
> >> evaluating the type-name has semantic consequences.
> >
> > I assume you mean "if you treat sizeof as a function". As I
> > understand it all that matters in a "sizeof (...) is the type of
> > the value in .... The "n++" should be ignored.
>
> Did you miss the fact that the operand is a parenthesized type name,
> and the type happens to be a VLA?
>
> N1570 6.5.3.4p2:
>
> If the type of the operand is a variable length array type, the
> operand is evaluated; otherwise, the operand is not evaluated
> and the result is an integer constant.
>
> Evaluating `sizeof (int[n++])` does in fact cause `n` to be
> incremented. (It's also ugly code that nobody should every write,
> but compiler implementers don't have the luxury of assuming that
> nobody ever will.)
>
> The idea of "evaluating" a type name is a bit iffy, but in this
> case the semantics are IMHO clear enough. At the very least, the
> value of n must be determined to determine the size of `int[n++]`.
> Determining the value of n without evaluating `n++` would be strange.
>
> --
> 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"
I think we may have a difference in different versions of C.
I always use C90 for reasons I wont go into here. In the C90 standard
6.3.3.4 starts out:
The sizeof operator yields the size (in bytes) of its operand,
which may be an expression or the parenthesized name of a type.
The size is determined from the type of the operand, which is not
itself evaluated. The result is an integer constant.
I think the C90 is silent on the question of what happens if the alleged
type name is not, in fact, a legitimate type name as "int[n++]" is not
in C90. I ignored that fact to get to the point about sizeof.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-08 11:06 -0700 |
| Message-ID | <873837hrl0.fsf@kst-u.example.com> |
| In reply to | #61772 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Thursday, May 7, 2015 at 12:27:04 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> > On Wednesday, May 6, 2015 at 7:48:57 PM UTC-7, Tim Rentsch wrote:
[...]
>> >> IMO it's better in this context to think of a type-name as an
>> >> unusual form of operand.
>> >>
>> >> Also, you might want to consider, eg, 'sizeof (int[ n++ ])', where
>> >> evaluating the type-name has semantic consequences.
>> >
>> > I assume you mean "if you treat sizeof as a function". As I
>> > understand it all that matters in a "sizeof (...) is the type of
>> > the value in .... The "n++" should be ignored.
>>
>> Did you miss the fact that the operand is a parenthesized type name,
>> and the type happens to be a VLA?
[...]
> I think we may have a difference in different versions of C.
>
> I always use C90 for reasons I wont go into here. In the C90 standard
> 6.3.3.4 starts out:
> The sizeof operator yields the size (in bytes) of its operand,
> which may be an expression or the parenthesized name of a type.
> The size is determined from the type of the operand, which is not
> itself evaluated. The result is an integer constant.
> I think the C90 is silent on the question of what happens if the alleged
> type name is not, in fact, a legitimate type name as "int[n++]" is not
> in C90. I ignored that fact to get to the point about sizeof.
Right, C90 didn't have VLAs. They were introduced in C99. At the same
time, the semantics of sizeof were updated to allow for it to apply to
VLAs.
If you want to restrict yourself to C90 for some reason, that's fine,
but it's not the current standard, and you can't expect the rest of us
to read your mind or to ignore the more recent editions of the standard.
You provided no basis for your statement that
The "n++" should be ignored.
And in fact there are no circumstances in which that's correct. In C90
(or in C11 with an implementation that doesn't support VLAs), the "n++"
should not be ignored; it must be flagged as a constraint violation. In
C99 or C11 with VLA support, it must be evaluated.
If you want to discuss a version of the standard other than the current
one, that's fine, but please let us know you're doing so.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-09 09:31 -0700 |
| Message-ID | <7134a864-252b-4e1d-b1d2-7a66359e34c6@googlegroups.com> |
| In reply to | #61777 |
On Friday, May 8, 2015 at 11:06:27 AM UTC-7, Keith Thompson wrote: > If you want to restrict yourself to C90 for some reason, that's fine, > but it's not the current standard, and you can't expect the rest of us > to read your mind or to ignore the more recent editions of the standard. > You provided no basis for your statement that > > The "n++" should be ignored. > > And in fact there are no circumstances in which that's correct. In C90 > (or in C11 with an implementation that doesn't support VLAs), the "n++" > should not be ignored; it must be flagged as a constraint violation. In > C99 or C11 with VLA support, it must be evaluated. > > If you want to discuss a version of the standard other than the current > one, that's fine, but please let us know you're doing so. I have carefully always specified that I mean C90. And I will continue to do so. The standard says "The size is determined from the type of the operand, which is not itself evaluated." I think that makes it pretty clear that the n++ is not evaluated. I use (most of) C90 because I want simple readily understood code. I see no reason for the mad rush to add features.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-05-10 08:01 +1200 |
| Message-ID | <cr77c4Frc3aU1@mid.individual.net> |
| In reply to | #61806 |
David Kleinecke wrote: > On Friday, May 8, 2015 at 11:06:27 AM UTC-7, Keith Thompson wrote: > >> If you want to restrict yourself to C90 for some reason, that's fine, >> but it's not the current standard, and you can't expect the rest of us >> to read your mind or to ignore the more recent editions of the standard. >> You provided no basis for your statement that >> >> The "n++" should be ignored. >> >> And in fact there are no circumstances in which that's correct. In C90 >> (or in C11 with an implementation that doesn't support VLAs), the "n++" >> should not be ignored; it must be flagged as a constraint violation. In >> C99 or C11 with VLA support, it must be evaluated. >> >> If you want to discuss a version of the standard other than the current >> one, that's fine, but please let us know you're doing so. > > I have carefully always specified that I mean C90. And I will continue to > do so. > > The standard says "The size is determined from the type of the operand, > which is not itself evaluated." I think that makes it pretty clear that > the n++ is not evaluated. It is also pretty clear, as Keith stated, that the expression would be a constraint violation in C90, so it can't be ignored. But I guess you are correct in saying it's not evaluated, invalid code seldom is... > I use (most of) C90 because I want simple readily understood code. I see > no reason for the mad rush to add features. Any C programmer who doesn't understand modern C code isn't much of a C programmer. Even from a tortoise's perspective, 16 years isn't a mad rush. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-05-09 13:13 -0700 |
| Message-ID | <312507fb-9ccd-49a9-8372-f453f25bb33e@googlegroups.com> |
| In reply to | #61809 |
On Saturday, May 9, 2015 at 9:01:17 PM UTC+1, Ian Collins wrote: > David Kleinecke wrote: > > Any C programmer who doesn't understand modern C code isn't > much of a C programmer. Even from a tortoise's perspective, > 16 years isn't a mad rush. > But programming ability has very little to do with knowing the language. The more complicated the problem, the simpler you want the language to be, as a general rule.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-05-10 08:51 +1200 |
| Message-ID | <cr7a9nFrc3aU2@mid.individual.net> |
| In reply to | #61810 |
Malcolm McLean wrote: > On Saturday, May 9, 2015 at 9:01:17 PM UTC+1, Ian Collins wrote: >> David Kleinecke wrote: >> >> Any C programmer who doesn't understand modern C code isn't >> much of a C programmer. Even from a tortoise's perspective, >> 16 years isn't a mad rush. >> > But programming ability has very little to do with knowing the > language. The more complicated the problem, the simpler you > want the language to be, as a general rule. That's a pretty stupid "general rule". The simplest language I have had the pleasure (and believe it or not, it was a pleasure) of programming in was PDP11 machine code. I very much doubt you would want to code a complicated the problem in machine code. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-09 16:45 -0700 |
| Message-ID | <87pp69gvsd.fsf@kst-u.example.com> |
| In reply to | #61806 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, May 8, 2015 at 11:06:27 AM UTC-7, Keith Thompson wrote:
>> If you want to restrict yourself to C90 for some reason, that's fine,
>> but it's not the current standard, and you can't expect the rest of us
>> to read your mind or to ignore the more recent editions of the standard.
>> You provided no basis for your statement that
>>
>> The "n++" should be ignored.
>>
>> And in fact there are no circumstances in which that's correct. In C90
>> (or in C11 with an implementation that doesn't support VLAs), the "n++"
>> should not be ignored; it must be flagged as a constraint violation. In
>> C99 or C11 with VLA support, it must be evaluated.
>>
>> If you want to discuss a version of the standard other than the current
>> one, that's fine, but please let us know you're doing so.
>
> I have carefully always specified that I mean C90. And I will continue to
> do so.
You didn't mention C90 in the article in which you claimed (still
incorrectly) that the "n++" should be ignored. I don't intend to keep
track of who insists on assuming C90 and who doesn't, so I suggest
mentioning it in each article in which it's relevant.
> The standard says "The size is determined from the type of the
> operand, which is not itself evaluated." I think that makes it
> pretty clear that the n++ is not evaluated.
No, *the standard* says that the operand is evaluated unless it's a VLA.
Just so you know, I'm referring to the current C11 standard; C99 says
the same thing.
> I use (most of) C90 because I want simple readily understood
> code. I see no reason for the mad rush to add features.
I have absolutely no objection to your choice to stick with C90 (though
I don't share your opinion).
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-07 13:28 -0700 |
| Message-ID | <kfnbnhwgmiq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61708 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Wednesday, May 6, 2015 at 7:48:57 PM UTC-7, Tim Rentsch wrote: >> Keith Thompson <kst-u@mib.org> writes: >> >>> (A digression: The form of `sizeof` that applies to a parenthesized >>> type name isn't something I'd call an operator, since its "operand" >>> isn't a expression. I'd call it a special form of expression, >>> disinct from the `sizeof expr` form. But the standard calls it a >>> unary operator in both forms, so I'll go along with it.) >> >> IMO it's better in this context to think of a type-name as an >> unusual form of operand. >> >> Also, you might want to consider, eg, 'sizeof (int[ n++ ])', where >> evaluating the type-name has semantic consequences. > > I assume you mean "if you treat sizeof as a function". No, I wasn't talking about that, just about how to regard the '(type-name)' part in that form of sizeof.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-06 19:36 -0700 |
| Message-ID | <kfnwq0lglkw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61632 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Wednesday, May 6, 2015 at 7:28:05 AM UTC-7, Ben Bacarisse wrote: > >>> I don't really understand myself. C only has a handful of >>> keywords, >> >> You have large hands. I count 44. It's still 33 even if you >> reject all the new ones. > > If you look at each word, symbol and symbol combination as a token > (outside of strings) then C90 has 78 built in tokens. A compiler > should have a tokenizer at its front end so all it sees is tokens. > Sizeof is just another token at the same level as, say, &. There are obvious differences between keywords and other C tokens. Lumping them together just for the sake of lumping them together is silly.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-05-06 22:13 -0500 |
| Message-ID | <5kllka131c4n1bklb81fotu1e0kaj7ljph@4ax.com> |
| In reply to | #61660 |
On Wed, 06 May 2015 19:36:47 -0700, Tim Rentsch <txr@alumni.caltech.edu> wrote: >David Kleinecke <dkleinecke@gmail.com> writes: > >> On Wednesday, May 6, 2015 at 7:28:05 AM UTC-7, Ben Bacarisse wrote: >> >>>> I don't really understand myself. C only has a handful of >>>> keywords, >>> >>> You have large hands. I count 44. It's still 33 even if you >>> reject all the new ones. >> >> If you look at each word, symbol and symbol combination as a token >> (outside of strings) then C90 has 78 built in tokens. A compiler >> should have a tokenizer at its front end so all it sees is tokens. >> Sizeof is just another token at the same level as, say, &. > >There are obvious differences between keywords and other C >tokens. Lumping them together just for the sake of lumping >them together is silly. I think his point was more that punctuators are pretty close to being keywords (the only difference being that keywords are indistinguishable from identifiers, except by their explicit inclusion in a list). Of the top of my head I can't see what difference it would make if the language spec put all the punctuators in the keyword section, and eliminated that as a separate category of token. There are, of course, far more than 78 tokens, as the various literals, strings, and a few other things are also tokens.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-05-07 11:56 -0700 |
| Message-ID | <7a892836-ee67-4be5-beef-a30f82ed2dd8@googlegroups.com> |
| In reply to | #61662 |
On Wednesday, May 6, 2015 at 8:13:19 PM UTC-7, robert...@yahoo.com wrote: > On Wed, 06 May 2015 19:36:47 -0700, Tim Rentsch > <txr@alumni.caltech.edu> wrote: > > >David Kleinecke <dkleinecke@gmail.com> writes: > > > >> On Wednesday, May 6, 2015 at 7:28:05 AM UTC-7, Ben Bacarisse wrote: > >> > >>>> I don't really understand myself. C only has a handful of > >>>> keywords, > >>> > >>> You have large hands. I count 44. It's still 33 even if you > >>> reject all the new ones. > >> > >> If you look at each word, symbol and symbol combination as a token > >> (outside of strings) then C90 has 78 built in tokens. A compiler > >> should have a tokenizer at its front end so all it sees is tokens. > >> Sizeof is just another token at the same level as, say, &. > > > >There are obvious differences between keywords and other C > >tokens. Lumping them together just for the sake of lumping > >them together is silly. > > > I think his point was more that punctuators are pretty close to being > keywords (the only difference being that keywords are > indistinguishable from identifiers, except by their explicit inclusion > in a list). Of the top of my head I can't see what difference it > would make if the language spec put all the punctuators in the keyword > section, and eliminated that as a separate category of token. > > There are, of course, far more than 78 tokens, as the various > literals, strings, and a few other things are also tokens. There are 78 built-in tokens. There is an arbitrary number of additional tokens. A tokenizer will probably number them 79, 80 etc. as it encounters them. The compiler proper never sees anything except these token numbers but probably keeps a table of name-number correlations around for error reporting and such like.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-07 14:16 -0700 |
| Message-ID | <kfn3838gkbo.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61662 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Wed, 06 May 2015 19:36:47 -0700, Tim Rentsch > <txr@alumni.caltech.edu> wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: >> >>> On Wednesday, May 6, 2015 at 7:28:05 AM UTC-7, Ben Bacarisse wrote: >>> >>>>> I don't really understand myself. C only has a handful of >>>>> keywords, >>>> >>>> You have large hands. I count 44. It's still 33 even if you >>>> reject all the new ones. >>> >>> If you look at each word, symbol and symbol combination as a token >>> (outside of strings) then C90 has 78 built in tokens. A compiler >>> should have a tokenizer at its front end so all it sees is tokens. >>> Sizeof is just another token at the same level as, say, &. >> >> There are obvious differences between keywords and other C >> tokens. Lumping them together just for the sake of lumping >> them together is silly. > > I think his point was more that punctuators are pretty close to > being keywords (the only difference being that keywords are > indistinguishable from identifiers, except by their explicit > inclusion in a list). Of the top of my head I can't see what > difference it would make if the language spec put all the > punctuators in the keyword section, and eliminated that as a > separate category of token. One difference is that keywords are keywords only in phases 7 and 8, but punctuators are punctuators (and so distinct tokens) from phase 3 onward. A keyword may be #define'd to have its meaning changed, but a punctuator cannot. And of course the most obvious difference (mentioned upthread I believe but lost to snipping) is that keywords match the syntax rules for identifiers and hence might be mistaken for one - if you don't know an identifier is a keyword then it could be mistaken for a regular identifier. No danger of that happening with a punctuator.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-05-07 11:43 -0700 |
| Message-ID | <kfnoalwgrdp.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #61597 |
David Brown <david.brown@hesbynett.no> writes: > On 05/05/15 16:01, Tim Rentsch wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> [snip] >>> >>> Beyond that, it is much more subjective. /I/ think "(a == 2)" is >>> easier to read than "(a==2)", but I accept that some people might >>> have different opinions. >> >> I get that this is what you think. What I'm trying to ask >> about is why you think it, in particular for what you said >> about a form like 'if( a == 2 )'. If all you can say is >> that you don't like it that isn't very helpful. > > You are asking why I prefer "if (a == 2)" to "if( a == 2 )" ? That isn't how I would have phrased it, but something along those lines, yes. > "If" is a keyword, not a function, and should stand clear as a > keyword. Syntax highlighting editors generally show keywords in a > different colour from function names, and if I am writing code on > paper I underline keywords as highlighting. I believe the spacing > in "if (a == 2)" better reflects how parts of that code hang > together. [snip re: ==] First let me say I appreciate the response. I didn't get much from your answer, beyond a general sense that one form is a better match to how you think of the construct. The principle that keywords should be kept separate seems a bit contrived; after all, people write 'break;' not 'break ;'. Of course it's true that 'if' is not a function call, but they are similar on a syntactic level. The statement about highlighting seems out of place; one the main points of highlighting is that it occurs in a dimension that is orthogonal to what is going on at the character level - the 'if' can be highlighted either way. The last sentence seems like says almost nothing, roughly akin to "I like it because it better reflects how I think it should be." I don't mean to say that there is no substance to your view here, just that there doesn't seem to be much in the writing that describes it. What am I missing? To be fair I should turn around and explain my own reactions and give you a chance to comment on those. First there is a physiological aspect. My eyes simply have to work a little bit harder when if() parentheses are adjacent to the condition being tested. I don't have any trouble seeing the 'if', and putting the left parenthesis next to it doesn't interfere with that. The condition, on the other hand, is where the cognitive action is, so I want that to stand out with as little nearby distraction as possible. Normally I use two spaces on the inside of if() parentheses (and likewise for while(), etc), for this reason. (Doing that also helps distinguish an if() from a function call, but my primary motivation is to help my eyes pick out the test being done.) On a cognitive level, there are two factors. One, parentheses that go with if's are noise characters; the only reason they are there is because the syntax would be ambiguous without them. I understand why they are necessary, but I want them out of the way so as not to have to remind myself why they can't be removed, because they look redundant. Two, putting parentheses away from the 'if' but adjacent to the condition expression is somewhat at odds with the syntax - it would look like they belong to the expression, but they don't, they are part of the if(). I have the same kind of reaction, mentally, to 'if (a == b)' as I would to an expression written like 'a+b * c'. It makes my brain hurt. To summarize, I favor 'if( a == b )' over 'if (a==b)' because the first form takes less effort both physically and mentally, as detailed above. Make sense?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-05-07 12:02 -0700 |
| Message-ID | <874mnojjn4.fsf@kst-u.example.com> |
| In reply to | #61710 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> To summarize, I favor 'if( a == b )' over 'if (a==b)' because the
> first form takes less effort both physically and mentally, as
> detailed above. Make sense?
Yes. And I favor 'if (a == b)' over 'if( a == b )' for the same reason.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 4 of 16 — ← Prev page 1 2 3 [4] 5 6 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web