Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #108327 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2017-04-22 09:06 +0100 |
| Last post | 2017-04-26 08:53 +0200 |
| Articles | 20 on this page of 245 — 25 participants |
Back to article view | Back to comp.lang.c
gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 09:06 +0100
Re: gcc failure (optimised/non-optimised) Andrew Cooper <amc96@cam.ac.uk> - 2017-04-22 09:49 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 10:52 +0100
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 11:37 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:07 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 08:33 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-28 22:32 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-28 14:53 -0700
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-29 07:00 +0100
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 11:19 +0100
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-29 11:30 +0100
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-22 16:12 +0200
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:16 +0100
Re: gcc failure (optimised/non-optimised) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-23 05:41 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-23 14:14 -0700
Re: gcc failure (optimised/non-optimised) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-24 04:04 -0500
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:22 +0100
Re: gcc failure (optimised/non-optimised) "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-24 12:05 -0400
Re: gcc rules OK (optimised/non-optimised) "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-24 17:06 -0400
Re: gcc rules OK (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 15:06 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:31 +0000
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-04-22 09:29 +0000
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 10:47 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 11:36 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 13:50 +0000
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 15:35 +0100
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:36 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 08:37 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-25 11:07 +0200
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-25 11:57 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 09:34 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 11:25 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:57 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 13:38 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-28 22:38 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-22 08:35 -0700
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 17:16 +0100
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-22 18:55 +0100
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-22 21:04 +0200
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-22 21:51 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-22 14:56 -0700
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 16:49 +0200
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-30 16:02 +0100
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-04-30 11:51 -0500
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 21:42 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-30 17:35 +0100
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-04-30 11:57 -0500
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-30 18:44 +0100
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 11:34 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 12:03 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:30 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-30 21:18 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:33 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-01 16:27 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-01 10:16 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:34 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 12:43 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-03 12:54 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 17:49 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-03 18:05 -0700
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-03 20:37 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 10:22 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 11:01 +0100
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 12:18 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 11:55 +0100
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 15:14 +0200
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-04 09:34 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 10:09 -0700
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 18:25 +0100
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-04 11:28 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 11:53 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 13:07 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 14:19 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 16:44 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:09 -0700
Re: gcc failure (optimised/non-optimised) Ian Collins <ian-news@hotmail.com> - 2017-05-05 08:17 +1200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 22:26 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:38 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-04 22:49 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 19:58 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:32 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-05 12:53 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 13:51 -0700
Re: gcc failure (optimised/non-optimised) Ian Collins <ian-news@hotmail.com> - 2017-05-05 08:58 +1200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 14:45 -0700
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-05-05 06:41 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-05 10:40 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-06 13:21 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-06 11:26 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-06 22:52 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-07 19:01 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 11:09 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-07 19:48 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 11:17 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 06:36 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 16:21 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 09:16 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 21:20 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 13:07 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-08 22:46 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 14:38 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-08 21:16 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 15:09 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 15:14 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 15:43 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 16:56 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 16:57 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 17:27 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-08 17:41 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 06:16 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-09 12:11 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-10 09:58 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-10 09:40 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-10 12:05 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-09 13:55 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 09:26 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-09 13:56 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 14:19 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-10 14:22 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-10 09:26 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-10 17:36 -0500
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-11 01:12 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-10 21:15 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-11 10:41 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-11 15:32 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-12 01:54 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-12 07:45 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-12 23:52 -0500
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 12:57 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-10 21:56 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-11 10:45 +0200
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-11 14:43 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-12 10:55 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-12 07:30 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-12 09:02 -0700
Re: gcc failure (optimised/non-optimised) "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-14 13:14 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-14 16:04 -0500
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-10 17:33 -0500
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-09 13:51 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 09:14 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-08 21:07 +0000
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-05-09 18:30 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:44 +0200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:42 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-05 14:10 +0000
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 17:12 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-04 15:08 +0000
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 12:24 -0500
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-04 18:29 +0100
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-04 18:07 +0000
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-04 20:15 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-04 15:47 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 01:22 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-04 18:57 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 09:30 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 01:25 -0700
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-05 10:33 +0200
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 10:10 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 12:49 +0200
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-05 18:31 -0700
Re: gcc failure (optimised/non-optimised) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-05-05 22:18 -0600
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-07 23:58 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 07:33 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 13:04 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-08 07:51 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-05-08 19:01 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-09 06:39 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-10 06:42 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:53 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-05 00:33 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-05 10:54 +0200
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:31 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 12:27 -0500
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 02:10 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-07 22:56 -0500
Re: gcc failure (optimised/non-optimised) David Kleinecke <dkleinecke@gmail.com> - 2017-05-04 13:00 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-04 15:15 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 14:06 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-05 00:43 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-04 13:31 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-01 21:52 +0200
Re: gcc failure (optimised/non-optimised) GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-01 23:16 +0200
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-05-02 09:19 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 17:28 -0700
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-01 13:12 +0000
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 22:23 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 10:08 -0700
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-30 22:32 +0200
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 13:59 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-30 17:47 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-04-30 21:49 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-30 11:24 -0700
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 12:45 -0700
Re: gcc failure (optimised/non-optimised) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-04-23 23:11 -0700
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 10:46 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 13:23 +0200
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 15:38 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 17:31 +0200
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-24 17:15 +0100
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 10:36 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 12:06 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 14:03 -0700
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-25 11:09 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 10:25 -0700
Re: gcc failure (optimised/non-optimised) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-04-27 05:51 +0000
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-01 09:08 +0000
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-05-01 10:48 +0100
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 11:39 +0100
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-05-01 13:54 +0200
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 08:55 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 12:18 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 11:03 -0700
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 13:13 -0500
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 19:47 +0100
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-05-01 18:51 +0000
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 14:06 -0500
Re: gcc failure (optimised/non-optimised) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-01 21:05 +0100
Re: gcc failure (optimised/non-optimised) Robert Wessel <robertwessel2@yahoo.com> - 2017-05-01 16:06 -0500
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 14:19 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 08:41 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-10 10:07 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 08:44 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 09:03 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 09:51 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:30 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-05-01 11:41 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-05-01 11:51 -0700
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-24 08:51 -0700
Re: gcc failure (optimised/non-optimised) Keith Thompson <kst-u@mib.org> - 2017-04-24 12:13 -0700
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-05-01 09:11 +0000
Re: gcc failure (optimised/non-optimised) Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-27 14:04 -0700
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-22 10:57 +0100
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 11:38 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 13:43 +0000
Re: gcc failure (optimised/non-optimised) Gareth Owen <gwowen@gmail.com> - 2017-04-22 18:22 +0100
Re: gcc failure (optimised/non-optimised) gazelle@shell.xmission.com (Kenny McCormack) - 2017-04-22 17:48 +0000
Re: gcc failure (optimised/non-optimised) supercat@casperkitty.com - 2017-04-22 14:24 -0700
Re: gcc failure (optimised/non-optimised) joel.rees@gmail.com - 2017-04-27 03:03 -0700
Re: gcc failure (optimised/non-optimised) James Kuyper <jameskuyper@verizon.net> - 2017-04-27 10:12 -0400
Re: gcc failure (optimised/non-optimised) raltbos@xs4all.nl (Richard Bos) - 2017-04-22 21:48 +0000
Re: gcc failure (optimised/non-optimised) James Harris <james.harris.1@gmail.com> - 2017-04-24 10:14 +0100
Re: gcc failure (optimised/non-optimised) bartc <bc@freeuk.com> - 2017-04-24 10:33 +0100
Re: gcc failure (optimised/non-optimised) David Brown <david.brown@hesbynett.no> - 2017-04-24 13:32 +0200
Re: gcc failure (optimised/non-optimised) scott@slp53.sl.home (Scott Lurndal) - 2017-04-24 13:47 +0000
Re: gcc failure (optimised/non-optimised) Noob <root@127.0.0.1> - 2017-04-26 08:53 +0200
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2017-05-05 22:18 -0600 |
| Message-ID | <1bfugivcs5.fsf@pfeifferfamily.net> |
| In reply to | #109387 |
joel.rees@gmail.com writes:
> On Friday, May 5, 2017 at 5:25:12 PM UTC+9, Tim Rentsch wrote:
>> joel.rees@somewhere writes:
>>
>> > [.. on uses of for() and while() ..]
>> >
>> > Just out of curiosity, what do you think is the best way to specify a
>> > loop whose only terminating condition is most efficiently tested
>> > somewhere between the entry point and the loop point?
>>
>> It depends a lot on what is done before and after the exit test.
>> Usually I see the presence of a "loop and a half" as an indicator
>> that the code needs to be re-thought or re-written, or both.
>
> I've wasted an awful lot of time re-thinking code so I can move
> the test to the top or bottom, and trying to decide whether the
> loop is more clearly expressed as a counted or enumerated loop,
> or as a general loop.
>
> The exit point often moves as my understanding of the loop improves,
> but not always to one end or the other.
>
> I shouldn't say, "wasted", although my bosses generally did. It
> helped write bug-free, maintainable code.
>
> I've found that no clear rule exists to claim a good common form.
> In particular, exit flags can get in the way as easily as clarify.
>
> Well, one rule -- keep the expressed loop short. Use macros when
> it helps, use subroutines if you have to.
>
> But it strikes me as ironic that the once-recommended idiom for an
> indeterminate loop (My vocabulary memory yesterday was off, wasn't
> it?) is now looked upon with such disdain.
>
> (And the dialectic idiom for a mask is practically standard.
> Go figure.)
Yeah, at one time I was taking points off for student programs that used
a loop-and-a-half (hope it didn't make a difference between an A and a B
for anybody...). I'd like to have something clearer than
while (1) {
... stuff ...
if (condition) break;
... stuff ...
if (condition) break;
... stuff ...
if (condition) break;
... stuff ...
}
(which looks great written like that, but tends to be just obscure when
I come accross it in real code) but I sure haven't come up with any good
ideas.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-07 23:58 -0700 |
| Message-ID | <kfnefvzvnqa.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #109387 |
joel.rees@gmail.com writes:
> On Friday, May 5, 2017 at 5:25:12 PM UTC+9, Tim Rentsch wrote:
>> joel.rees@somewhere writes:
>>
>>> [.. on uses of for() and while() ..]
>>>
>>> Just out of curiosity, what do you think is the best way to specify a
>>> loop whose only terminating condition is most efficiently tested
>>> somewhere between the entry point and the loop point?
>>
>> It depends a lot on what is done before and after the exit test.
>> Usually I see the presence of a "loop and a half" as an indicator
>> that the code needs to be re-thought or re-written, or both.
>
> I've wasted an awful lot of time re-thinking code so I can move
> the test to the top or bottom, and trying to decide whether the
> loop is more clearly expressed as a counted or enumerated loop,
> or as a general loop.
>
> The exit point often moves as my understanding of the loop improves,
> but not always to one end or the other.
>
> I shouldn't say, "wasted", although my bosses generally did. It
> helped write bug-free, maintainable code.
>
> I've found that no clear rule exists to claim a good common form.
> In particular, exit flags can get in the way as easily as clarify.
>
> Well, one rule -- keep the expressed loop short. Use macros when
> it helps, use subroutines if you have to.
>
> But it strikes me as ironic that the once-recommended idiom for an
> indeterminate loop (My vocabulary memory yesterday was off, wasn't
> it?) is now looked upon with such disdain.
I think you misunderstood what I was trying to say. I don't
think using a "loop and a half" pattern is always wrong, only
that seeing one often indicates the code would benefit from
some re-thinking or re-writing. Apparently that matches your
experience (the reaction of your bosses notwithstanding).
Having said that, I will add that "leave in the middle" type
loops should be rare enough so that it's better not to have an
established idiom for how to write one. Instead it should be
treated in much the same way as other uncommon patterns, eg,
possibly preceded by a comment like this
// I looked at other approaches for the following but
// couldn't find a better way of writing it. Any ideas?
This reaction is corollary to a more general principle that we
shouldn't try to find a "standard pattern" for every possible
situation - it's better to have a small number of standard
patterns and just flag exceptions to those, where one does the
best one can and lets the chips fall where they may.
A few miscellaneous further comments...
I agree on keeping loop bodies short. Function bodies also.
IME using flags as part of a loop control is almost always a poor
choice. More specifically, a flag introduced for the sole
purpose of avoiding an intermediate loop exit is inferior to
using an explicit control transfer. I believe I have never
seen an exception to this principle.
Last but not least, there is an important special case that
deserves mention, namely, searching for something where an
intermediate exit is taken when the searched-for item has been
found. This situation comes up often enough to be recognized as
a common pattern. When it does, usually I find it helps to have
a separate function for the search loop, and use 'return' to
produce the found value. Some developers think having more than
one 'return' in a function should be avoided like the plague.
Personally I don't think that's true, but even granting merit to
the principle of avoiding intermediate return statements, this
use case is important enough so that an exception should be
made for it. (All IMCO, of course, in case that needs saying.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-08 07:33 -0700 |
| Message-ID | <11090418-e885-4725-ae1b-ca5da70dc017@googlegroups.com> |
| In reply to | #109468 |
On Monday, May 8, 2017 at 1:58:47 AM UTC-5, Tim Rentsch wrote:
> I think you misunderstood what I was trying to say. I don't
> think using a "loop and a half" pattern is always wrong, only
> that seeing one often indicates the code would benefit from
> some re-thinking or re-writing. Apparently that matches your
> experience (the reaction of your bosses notwithstanding).
The code:
while((n = fread(...whatever)) != 0)
...doSomething;
uses a loop-and-a-half construct, but hides it by cramming the first half
and its associated side effects into the controlling expression. I would
suggest that a loop-and-a-half construct that accommodated a statement
before the conditional test rather than an expression would be helpful.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-14 13:04 -0700 |
| Message-ID | <kfnmvafqk66.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #109498 |
supercat@casperkitty.com writes: > On Monday, May 8, 2017 at 1:58:47 AM UTC-5, Tim Rentsch wrote: >> I think you misunderstood what I was trying to say. I don't >> think using a "loop and a half" pattern is always wrong, only >> that seeing one often indicates the code would benefit from >> some re-thinking or re-writing. Apparently that matches your >> experience (the reaction of your bosses notwithstanding). > > The code: > > while((n = fread(...whatever)) != 0) > ...doSomething; > > uses a loop-and-a-half construct, [...]. It is not a loop-and-a-half as I mean the term, as I explained in another response in this thread. > I would > suggest that Note to people interested in improving their writing - the phrase "I would suggest that" should be revised out of every sentence in which it occurs. Cf "Elements of Style", by Strunk and White. > a loop-and-a-half construct that accommodated a statement > before the conditional test rather than an expression would be helpful. Your mental oven seems to have a broken timer. You would do better if you could learn not to just blurt out the first half-baked idea that pops into your head.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-08 07:51 -0700 |
| Message-ID | <1e0fec8d-3d7b-45b5-a3dd-d2bf3d575b21@googlegroups.com> |
| In reply to | #109468 |
On Monday, May 8, 2017 at 1:58:47 AM UTC-5, Tim Rentsch wrote:
> Some developers think having more than
> one 'return' in a function should be avoided like the plague.
> Personally I don't think that's true, but even granting merit to
> the principle of avoiding intermediate return statements, this
> use case is important enough so that an exception should be
> made for it. (All IMCO, of course, in case that needs saying.)
A lot of people misunderstood what it means for a function to have a single
exit point, mainly because they haven't dealt with the alternative. In the
old days (and, for awhile, on some *really* constrained systems where saving
a couple bytes of RAM could be a big deal) a lot of "functions" were invoked
not with a subroutine call, but with a goto. Code might do something
loosely equivalent to:
unsigned char gameInProgress:
ShowTitleScreen:
...
goto ShowScore;
TitleScreenAfterScore:
...
goto ShowTitleScreen;
ShowGameplayScreen:
...
goto ShowScore;
GameplayScreenAfterScore:
...
goto ShowGameplayScreen
ShowScore:
...
if (gameInProgress)
goto GameplayScreenAfterScore;
else
goto TitleScreenAfterScore;
After code invoked ShowScore, there would be two places control could go
after that: to TitleScreenAfterScore or GameplayScreenAfterScore; while it
might typically go to the former when invoked during the title screen and
the latter when invoked during gameplay, nothing about the code structure
would guarantee that.
By comparison, any particular call to a C function which doesn't directly
or indirectly use longjmp can be guaranteed to always return control to
the same spot: the instruction following the call. Since nearly all
languages support a subroutine-call construct, and almost all systems have
adequate resources to make use of it (the code pattern above, btw, would
be common on the Atari 2600--a popular video game system with a total of
128 bytes of RAM; a lot of games used up every single byte, and a two-byte
reduction in stack usage could be extremely valuable).
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-08 19:01 -0700 |
| Message-ID | <8a7eb4ff-1bde-4c7e-8e89-512bd817bc78@googlegroups.com> |
| In reply to | #109468 |
On Monday, May 8, 2017 at 3:58:47 PM UTC+9, Tim Rentsch wrote:
> joel rees@somewhere
> > On Friday, May 5, 2017 at 5:25:12 PM UTC+9, Tim Rentsch wrote:
> >> joel.rees@somewhere writes:
> >>
> >>> [.. on uses of for() and while() ..]
> >>>
> >>> Just out of curiosity, what do you think is the best way to specify a
> >>> loop whose only terminating condition is most efficiently tested
> >>> somewhere between the entry point and the loop point?
> >>
> >> It depends a lot on what is done before and after the exit test.
> >> Usually I see the presence of a "loop and a half" as an indicator
> >> that the code needs to be re-thought or re-written, or both.
> >
> > I've wasted an awful lot of time re-thinking code so I can move
> > the test to the top or bottom, and trying to decide whether the
> > loop is more clearly expressed as a counted or enumerated loop,
> > or as a general loop.
> >
> > The exit point often moves as my understanding of the loop improves,
> > but not always to one end or the other.
> >
> > I shouldn't say, "wasted", although my bosses generally did. It
> > helped write bug-free, maintainable code.
> >
> > I've found that no clear rule exists to claim a good common form.
> > In particular, exit flags can get in the way as easily as clarify.
> >
> > Well, one rule -- keep the expressed loop short. Use macros when
> > it helps, use subroutines if you have to.
> >
> > But it strikes me as ironic that the once-recommended idiom for an
> > indeterminate loop (My vocabulary memory yesterday was off, wasn't
> > it?) is now looked upon with such disdain.
>
> I think you misunderstood what I was trying to say. I don't
> think using a "loop and a half" pattern is always wrong, only
> that seeing one often indicates the code would benefit from
> some re-thinking or re-writing. Apparently that matches your
> experience (the reaction of your bosses notwithstanding).
I'm glad to know that much.
I've found that the more code I write, (with a nod to, I think it was supercat's thought) ...
My brain isn't working well today. Let's try this. Would you consider
while ( ( ch = getchar() ) != FEOF )
{
/* body with no other exit */
}
to be a loop-and-a-half?
> Having said that, I will add that "leave in the middle" type
> loops should be rare enough so that it's better not to have an
> established idiom for how to write one.
I'm finding that pretty much everything is leave-in-the-middle, but I consider the above while to be prettied-up leave-in-the-middle. When it's concise and clear, it's concise and clear, but when it hides something that I need to remember is happening, I'll break it out and use the for (;;) to flag it as indeterminate and use an if ( test ) { break; } to get out:
for (;;)
{
/* stuff that happens every loop,
// but must happen before the test makes sense on the first pass
*/
if ( test )
{
/* cleanup that has to happen */
break;
}
/* The rest of the loop */
}
Some of what happens in the code before the test is stuff like conditioning a buffer. It could be hidden, in the case of something like getchar() by burying the standard call in an accessor function, but there are two problems with that.
One problem is C's lack of namespace nesting for function calls.
The other is that calls in loops really should be limited. Nested calls more so.
A huge part of the current code churn is that we are asking the optimizers to do too much. Every optimization is an opportunity for miscommunication between the compiler architects, the compiler implementors, the application architects, and the application implementors. (Not to mention the end-users.)
A lot of things seem to work, much in the same way that early embedded programming that ignored the possibility of alternate bus-masters and interrupts doing unexpected things to data just worked:
Chance, and the use of (long) idioms that were "known" to work, and avoidance of non-idiomatic stuff because "it was scary".
And the predominance of hardware that deliberately avoided concurrence.
Now that the primary desktop CPU manufacture finds that Moore's law is no longer getting them out of the corners they love to paint themselves into with their roadmaps and big promises, they finally, thirty years later than the competition they killed, are bringing concurrence into their hardware.
Piecewise. Wrapped up in unnecessary hardware to avoid exposing all the stupidities of what they have done in the past. And continuing to use their influence in the standards bodies to keep the industry out of the "dark corners" they are still unwilling to deal with.
Maybe you think I've gone of on a rant, and I have. But whether I'm ranting or not makes no difference. The standards are still "guiding" the industry away from solutions while the big players try to build captive solutions that prop up their sagging bottom lines.
> Instead it should be
> treated in much the same way as other uncommon patterns, eg,
> possibly preceded by a comment like this
>
> // I looked at other approaches for the following but
> // couldn't find a better way of writing it. Any ideas?
>
> This reaction is corollary to a more general principle that we
> shouldn't try to find a "standard pattern" for every possible
> situation - it's better to have a small number of standard
> patterns and just flag exceptions to those, where one does the
> best one can and lets the chips fall where they may.
>
> A few miscellaneous further comments...
>
> I agree on keeping loop bodies short. Function bodies also.
>
> IME using flags as part of a loop control is almost always a poor
> choice. More specifically, a flag introduced for the sole
> purpose of avoiding an intermediate loop exit is inferior to
> using an explicit control transfer. I believe I have never
> seen an exception to this principle.
>
> Last but not least, there is an important special case that
> deserves mention, namely, searching for something where an
> intermediate exit is taken when the searched-for item has been
> found. This situation comes up often enough to be recognized as
> a common pattern. When it does, usually I find it helps to have
> a separate function for the search loop, and use 'return' to
> produce the found value. Some developers think having more than
> one 'return' in a function should be avoided like the plague.
> Personally I don't think that's true, but even granting merit to
> the principle of avoiding intermediate return statements, this
> use case is important enough so that an exception should be
> made for it. (All IMCO, of course, in case that needs saying.)
We depend way too much on patterns -- on other people's idioms.
(Sorry to vent at you. I know that this is the way the world has always been, and the way it will tend to be in the future. I'm an idealist. :-/)
--
Joel Rees
randomly ranting:
http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-09 06:39 -0700 |
| Message-ID | <9e84521a-c3eb-4a88-84ee-311f9291625e@googlegroups.com> |
| In reply to | #109562 |
On Monday, May 8, 2017 at 9:01:27 PM UTC-5, joel...@gmail.com wrote: > A huge part of the current code churn is that we are asking the optimizers to do too much. Every optimization is an opportunity for miscommunication between the compiler architects, the compiler implementors, the application architects, and the application implementors. (Not to mention the end-users.) My philosophy is that if I want the compiler to generate machine code that does X, I should write code that does X. I shouldn't have to write code that does Y and Z and pretend to be happy when an optimizer figures out that it can replace Y and Z with code that does X, *which is what I wanted to write in the first place*. Further, if I write code that does X, but write code that does Y, I shouldn't be annoyed if a compiler generates machine code that does Y even though X would be more efficient, unless the only reason I wrote Y was that the compiler would decide that if I had written I wouldn't really have meant it. C was invented to replace the need for assembly language in many situations. I find odd the idea that as optimizers make compilers less and less suitable for that purpose, I'm told that I should be writing in assembly language, when the whole *purpose* of C was to avoid the need for that. > A lot of things seem to work, much in the same way that early embedded programming that ignored the possibility of alternate bus-masters and interrupts doing unexpected things to data just worked: A lot rested on the principle which the authors of the Standard explicitly mentioned in the rationale about translation limits, but which is equally applicable elsewhere: the Standard doesn't try to probe out every last detail about things a quality implementation should support, since an implementation that can support the features required by the Standard would naturally support useful abilities beyond. On some platforms it may be expensive to ensure that something like x*y > z will never do anything other than yield 1, yield 0, or trap with predictable consequences. On the vast majority of platforms, offering that level of behavioral guarantee would cost essentially *nothing*. The authors of the Standard recognized that the cost-benefit ratios of defining different behaviors would be different on implementations targeting different platforms and application fields, and they were less qualified that implementation writers to make judgments about how individual implementations should behave. Unfortunately, some implementation writers seem to believe that "non-portable or erroneous" is synonymous with "erroneous". > Chance, and the use of (long) idioms that were "known" to work, and avoidance of non-idiomatic stuff because "it was scary". > > And the predominance of hardware that deliberately avoided concurrence. And compilers which valued compatibility over "performance".
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-10 06:42 -0700 |
| Message-ID | <kfnfugcu8tl.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #109562 |
joel.rees@gmail.com writes:
> On Monday, May 8, 2017 at 3:58:47 PM UTC+9, Tim Rentsch wrote:
>> joel rees@somewhere
>>> On Friday, May 5, 2017 at 5:25:12 PM UTC+9, Tim Rentsch wrote:
>>>> joel.rees@somewhere writes:
>>>>
>>>>> [.. on uses of for() and while() ..]
>>>>>
>>>>> Just out of curiosity, what do you think is the best way to specify a
>>>>> loop whose only terminating condition is most efficiently tested
>>>>> somewhere between the entry point and the loop point?
>>>>
>>>> It depends a lot on what is done before and after the exit test.
>>>> Usually I see the presence of a "loop and a half" as an indicator
>>>> that the code needs to be re-thought or re-written, or both.
>
> [..some areas of agreement..]
>
> Let's try this. Would you consider
>
> while ( ( ch = getchar() ) != FEOF )
> {
> /* body with no other exit */
> }
>
> to be a loop-and-a-half?
I don't, and it's important to understand my comments in that
light. The distinction I am making is based on how the code is
understood or conceptualized, not on a rigid classification of
the underlying semantics.
Let me clarify that and say loop predicates that are very
complicated (which this one is not) may raise red flags for other
reasons. But those reasons don't fall under the heading of LAAH
or LITM, as I might normally use those terms.
>> Having said that, I will add that "leave in the middle" type
>> loops should be rare enough so that it's better not to have an
>> established idiom for how to write one.
>
> I'm finding that pretty much everything is leave-in-the-middle,
> but I consider the above while to be prettied-up
> leave-in-the-middle. When it's concise and clear, it's concise
> and clear, but when it hides something that I need to remember is
> happening, I'll break it out and use the for (;;) to flag it as
> indeterminate and use an if ( test ) { break; } to get out:
>
> for (;;)
> {
> /* stuff that happens every loop,
> // but must happen before the test makes sense on the first pass
> */
> if ( test )
> {
> /* cleanup that has to happen */
> break;
> }
> /* The rest of the loop */
> }
In most cases I expect I would have the opposite reaction, that
this way of structuring the code reveals details that are better
not shown at this level of refinement. That reaction may prompt
changes to how the rest of the loop is written -- I am a firm
believer in conceptual integrity at each level of refinement.
> Some of what happens in the code before the test is stuff like
> conditioning a buffer. It could be hidden, in the case of
> something like getchar() by burying the standard call in an
> accessor function, but there are two problems with that.
>
> One problem is C's lack of namespace nesting for function calls.
I don't know what you mean by this.
> The other is that calls in loops really should be limited. Nested
> calls more so.
This comment greatly surprises me. Can you say more about
what you think the limitations should be, and why you think
they are important.
> [..various concerns about optimization and hardware..]
>
> Maybe you think I've gone of on a rant, and I have.
I don't think it has much bearing on what we have been
discussing, but I wouldn't particularly call it a rant.
Especially not by comp.lang.c standards. ;)
> But whether
> I'm ranting or not makes no difference. The standards are still
> "guiding" the industry away from solutions while the big players
> try to build captive solutions that prop up their sagging bottom
> lines.
I don't completely understand this comment, but perhaps it's
better to leave it for another day.
>> [..various stylistic remarks..]
>
> We depend way too much on patterns -- on other people's idioms.
I don't think favoring patterns is in and of itself a bad thing.
What I do think is bad is the idea that every circumstance should
be expressed in some standard pattern (or even worse, that there
is only one appropriate choice of pattern for any given case).
Some programming situations fit nicely into common constructions,
but others do not, and it's a mistake to pretend otherwise.
> (Sorry to vent at you. [...])
I didn't take it as being directed at me -- more like a response
to what I was saying rather than at me. And I hope you take my
remarks here likewise.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-05 10:53 +0200 |
| Message-ID | <oehebu$rvf$1@dont-email.me> |
| In reply to | #109279 |
On 05/05/17 00:47, joel.rees@gmail.com wrote:
> On Friday, May 5, 2017 at 3:18:28 AM UTC+9, GOTHIER Nathan wrote:
>> On Thu, 04 May 2017 18:07:42 GMT
>> scott@somewhere (Scott Lurndal) wrote:
>>
>>> For you, perhaps. For all other programmers, how do you know?
>>>
>>> The pattern, 'for (;cond;) {}' is highly usual in my experience,
>>> and the OP (and you) said _all_ 'for' -> 'while'.
>>
>> It is only a bad hack from bad programmers.
>
> Just out of curiosity, what do you think is the best way to specify
> a loop whose only terminating condition is most efficiently tested
> somewhere between the entry point and the loop point?
>
> Do you like the vernacular:
>
> for (;;)
> {
> /* stuff */
> if ( condition ) break;
> /* stuff */
> }
>
> ?
>
I always prefer "while (true)" to "for (;;)". It looks less like a
strange smiley :-)
And I would also consider pulling the loop out into its own function and
using "return" rather than "break". I'd certainly go that route before
looking at "goto".
Another option is:
bool stillChecking = true;
while (stillChecking) {
...
if (condition) {
stillChecking = true;
} else {
...
}
}
Or a do-while loop.
It is hard to give a "best" solution, because it depends too much on the
details.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-05 00:33 +0100 |
| Message-ID | <gTOOA.1186818$F83.857633@fx38.am4> |
| In reply to | #109237 |
On 04/05/2017 19:07, Scott Lurndal wrote:
> bartc <bc@freeuk.com> writes:
>> On 04/05/2017 18:24, Robert Wessel wrote:
>>> On Thu, 04 May 2017 15:08:41 GMT, scott@slp53.sl.home (Scott Lurndal)
>>
>>>> It's a completely unreasonable habit that leads to constant
>>>> code churn when the next programmer who is capable of understanding
>>>> the c "for" construct changes it back from while to for.
>>>
>>>
>>> One might hope that the next programmer is more reticent to change
>>> working code mere because he doesn't like the style.
>>
>> It's less likely that someone would want to change 'while (cond) {}' to
>> 'for (;cond;) {}' than the other way around. You'd hope.
>
> For you, perhaps. For all other programmers, how do you know?
>
> The pattern, 'for (;cond;) {}' is highly usual in my experience,
> and the OP (and you) said _all_ 'for' -> 'while'.
>
I haven't got many C sources on my machine, but I can see these examples
(often multiple instances of each):
for (; workp < p - chars_length ;)
for (; !fake ;)
for (; nregs--;)
for (; size--;)
for(;c;)
for(;c--;)
for(; --oparg >= 0;) {
for(;s < end;) {
for (; VARRAY_ACTIVE_SIZE (stack) > 0; )
for (; tp_node; )
for(; i < 40; ) {
These all pure while loops. The trouble is that in this form, you don't
know that: you have to pause look more carefully to check that they are
in fact plain while loops.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-05 10:54 +0200 |
| Message-ID | <oeheeh$rvf$2@dont-email.me> |
| In reply to | #109282 |
On 05/05/17 01:33, bartc wrote:
> On 04/05/2017 19:07, Scott Lurndal wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 04/05/2017 18:24, Robert Wessel wrote:
>>>> On Thu, 04 May 2017 15:08:41 GMT, scott@slp53.sl.home (Scott Lurndal)
>>>
>>>>> It's a completely unreasonable habit that leads to constant
>>>>> code churn when the next programmer who is capable of understanding
>>>>> the c "for" construct changes it back from while to for.
>>>>
>>>>
>>>> One might hope that the next programmer is more reticent to change
>>>> working code mere because he doesn't like the style.
>>>
>>> It's less likely that someone would want to change 'while (cond) {}' to
>>> 'for (;cond;) {}' than the other way around. You'd hope.
>>
>> For you, perhaps. For all other programmers, how do you know?
>>
>> The pattern, 'for (;cond;) {}' is highly usual in my experience,
>> and the OP (and you) said _all_ 'for' -> 'while'.
>>
>
> I haven't got many C sources on my machine, but I can see these examples
> (often multiple instances of each):
>
> for (; workp < p - chars_length ;)
> for (; !fake ;)
> for (; nregs--;)
> for (; size--;)
> for(;c;)
> for(;c--;)
> for(; --oparg >= 0;) {
> for(;s < end;) {
> for (; VARRAY_ACTIVE_SIZE (stack) > 0; )
> for (; tp_node; )
> for(; i < 40; ) {
>
> These all pure while loops. The trouble is that in this form, you don't
> know that: you have to pause look more carefully to check that they are
> in fact plain while loops.
>
It is easy to find examples of this sort of style. But that does not
mean it is common, as a fraction of loops in general.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-04 13:31 -0700 |
| Message-ID | <61ec7fa2-7240-4178-aacc-0f6aa4c43315@googlegroups.com> |
| In reply to | #109231 |
On Thursday, May 4, 2017 at 10:24:49 AM UTC-7, robert...@yahoo.com wrote: > On Thu, 04 May 2017 15:08:41 GMT, scott@slp53.sl.home (Scott Lurndal) > wrote: > > >bartc <bc@freeuk.com> writes: > >>On 04/05/2017 12:07, David Brown wrote: > >> > >>>> U followed by a number n which is the [byte] width as 2**n is > >>>> rather perverse. > >>> > >>> The poster here seems to think that perverse is a good thing. He has > >>> also decided that the "for" syntax in C does not look like C, and so > >>> when working with other people's code he first goes through it to > >>> replace all for-loops with while-loops. > >> > >>That's not that unreasonable. > > > > It's a completely unreasonable habit that leads to constant > >code churn when the next programmer who is capable of understanding > >the c "for" construct changes it back from while to for. > > > One might hope that the next programmer is more reticent to change > working code mere because he doesn't like the style. I'm re-working existing code to study the effect of coding style and presentation and not to meddle with existing working code. I use other people's code in order to insure my ideas don't get ingrown into my own style. Most of what I edit is code in the Gtk+ world and I have to admit I remain baffled by the reasons for the existence of the baroque object-orientation that Gtk+ coders use.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-04 12:27 -0500 |
| Message-ID | <r0pmgc1vgksbdhgc07pg4ng9n9u8p6gagg@4ax.com> |
| In reply to | #109180 |
On Thu, 4 May 2017 11:01:00 +0100, bartc <bc@freeuk.com> wrote: >U followed by a number n which is the width as 2**n is rather perverse. >U64 in that scheme would be an unsigned int so wide that most of the >world's production of RAM chips would need to be commandeered just to >have enough memory to store one number. While production of disk drives (including SSD-like devices) now likely exceeds 2**64 bytes per year (at least by a bit), it's unlikely that RAM production, even cumulative, has reached that point.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-05 02:10 -0700 |
| Message-ID | <kfnpofnwtxd.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #109233 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Thu, 4 May 2017 11:01:00 +0100, bartc <bc@freeuk.com> wrote:
>
>> U followed by a number n which is the width as 2**n is rather perverse.
>> U64 in that scheme would be an unsigned int so wide that most of the
>> world's production of RAM chips would need to be commandeered just to
>> have enough memory to store one number.
>
> While production of disk drives (including SSD-like devices) now
> likely exceeds 2**64 bytes per year (at least by a bit), it's unlikely
> that RAM production, even cumulative, has reached that point.
I don't know if I would say unlikely (ie, for all RAM produced);
to me it seems closer to an even money bet. Some statistics:
Total number of computers sold (through 2015): 4,187,000,000
As of 2014, there were 1.9 billion Android devices in use
(sources:
http://www.statisticbrain.com/computer-sales-statistics/
https://www.quora.com/How-many-iPhone-users-are-in-the-world-currently-How-many-Android-users-are-in-the-world-currently
)
Probably at least 1 GB each on the average, which is already
about 62.5 bits. And there are other devices not counted
in these numbers (eg iPhones). By now the total must at
least be hovering near 64 bits if it hasn't already crossed
it.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-07 22:56 -0500 |
| Message-ID | <51rvgclk01glbdlhujjdof4gfmd1hah2gu@4ax.com> |
| In reply to | #109311 |
On Fri, 05 May 2017 02:10:22 -0700, Tim Rentsch <txr@alumni.caltech.edu> wrote: >Robert Wessel <robertwessel2@yahoo.com> writes: > >> On Thu, 4 May 2017 11:01:00 +0100, bartc <bc@freeuk.com> wrote: >> >>> U followed by a number n which is the width as 2**n is rather perverse. >>> U64 in that scheme would be an unsigned int so wide that most of the >>> world's production of RAM chips would need to be commandeered just to >>> have enough memory to store one number. >> >> While production of disk drives (including SSD-like devices) now >> likely exceeds 2**64 bytes per year (at least by a bit), it's unlikely >> that RAM production, even cumulative, has reached that point. > >I don't know if I would say unlikely (ie, for all RAM produced); >to me it seems closer to an even money bet. Some statistics: > > Total number of computers sold (through 2015): 4,187,000,000 > > As of 2014, there were 1.9 billion Android devices in use > >(sources: > http://www.statisticbrain.com/computer-sales-statistics/ > https://www.quora.com/How-many-iPhone-users-are-in-the-world-currently-How-many-Android-users-are-in-the-world-currently >) > >Probably at least 1 GB each on the average, which is already >about 62.5 bits. And there are other devices not counted >in these numbers (eg iPhones). By now the total must at >least be hovering near 64 bits if it hasn't already crossed >it. Probably true, especially given the massive proliferation of smartphones and expansions of their memories in the last decade.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-04 13:00 -0700 |
| Message-ID | <4f98f0e7-d1df-40fc-88d7-450720e14cac@googlegroups.com> |
| In reply to | #109180 |
On Thursday, May 4, 2017 at 3:00:55 AM UTC-7, Bart wrote: > On 01/05/2017 19:34, Keith Thompson wrote: > > David Kleinecke <dkleinecke@gmail.com> writes: > > >> But I am not an admirer of the built-in C type system. I would > >> prefer something along the lines of > >> U0 : unsigned char > >> S0 : signed char > >> U1 : unsigned 16-bits > >> S1 : signed 16-bits > >> U2 : unsigned 32-bits > >> U3 : unsigned 64-bits > >> U4 : unsigned 128-bits > >> etc. > >> and other names for things like 48-bit types. > > > > You can do that too if you insist. > > U followed by a number n which is the width as 2**n is rather perverse. > U64 in that scheme would be an unsigned int so wide that most of the > world's production of RAM chips would need to be commandeered just to > have enough memory to store one number. > > More common is U8, U16, U32, U64 (number of bits), or sometimes U1, U2, > U4, U8 (number of bytes), although both sets confusingly have U8. > > > What I strongly object to is your suggestion of defining a type "Int" as > > an alias for "unsigned int". That would be utterly misleading to any > > reader who's familiar with C. > > > >> I know there are other versions of this stuff. Most of the > >> others are hideous. > > > > I usually prefer to accept the language as it is rather than using > > tricks to transform it into a style I prefer. Such tricks require the > > reader to understand both the underlying language and the dialect you've > > invented. > > The base language, as it is, requires you to use: > > unsigned long long int > > for 64 bits unsigned. That's if you prefer to include the 'int' > otherwise it looks a bit sloppy to declare a type using only modifiers > and not the thing you're modifying. I would see "short" as 16 bits, "int" as 32 bits and "long" as 64 bits. I don't think the C89 standard requires one to use "long long". I would use "long long" for 128 bit integers which I have concluded (after a rather long analysis of multiplication) is likely to be the longest integer size ever needed. I imagine allowing multiplication of 64 bit integers implies a 128 bit integer - in the hardware if not in the C code. In my opinion the treatment of multiplication in C has never been satisfactory (and conversely division) but apparently compilers can "optimize" around the clumsiness.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-04 15:15 -0500 |
| Message-ID | <oi2ngc9sjmevv6f4vf0bgefh0c50uukr68@4ax.com> |
| In reply to | #109256 |
On Thu, 4 May 2017 13:00:11 -0700 (PDT), David Kleinecke <dkleinecke@gmail.com> wrote: >On Thursday, May 4, 2017 at 3:00:55 AM UTC-7, Bart wrote: >> On 01/05/2017 19:34, Keith Thompson wrote: >> > David Kleinecke <dkleinecke@gmail.com> writes: >> >> >> But I am not an admirer of the built-in C type system. I would >> >> prefer something along the lines of >> >> U0 : unsigned char >> >> S0 : signed char >> >> U1 : unsigned 16-bits >> >> S1 : signed 16-bits >> >> U2 : unsigned 32-bits >> >> U3 : unsigned 64-bits >> >> U4 : unsigned 128-bits >> >> etc. >> >> and other names for things like 48-bit types. >> > >> > You can do that too if you insist. >> >> U followed by a number n which is the width as 2**n is rather perverse. >> U64 in that scheme would be an unsigned int so wide that most of the >> world's production of RAM chips would need to be commandeered just to >> have enough memory to store one number. >> >> More common is U8, U16, U32, U64 (number of bits), or sometimes U1, U2, >> U4, U8 (number of bytes), although both sets confusingly have U8. >> >> > What I strongly object to is your suggestion of defining a type "Int" as >> > an alias for "unsigned int". That would be utterly misleading to any >> > reader who's familiar with C. >> > >> >> I know there are other versions of this stuff. Most of the >> >> others are hideous. >> > >> > I usually prefer to accept the language as it is rather than using >> > tricks to transform it into a style I prefer. Such tricks require the >> > reader to understand both the underlying language and the dialect you've >> > invented. >> >> The base language, as it is, requires you to use: >> >> unsigned long long int >> >> for 64 bits unsigned. That's if you prefer to include the 'int' >> otherwise it looks a bit sloppy to declare a type using only modifiers >> and not the thing you're modifying. > >I would see "short" as 16 bits, "int" as 32 bits and >"long" as 64 bits. I don't think the C89 standard requires >one to use "long long". There is no long long in C89 as all, except as an implementation extension. >I would use "long long" for 128 >bit integers which I have concluded (after a rather >long analysis of multiplication) is likely to be the >longest integer size ever needed. A 128 bit type would actually be adequate for most currency calculations, and only in a few places would you have to worry about rounding errors and overflows on intermediate results. >I imagine allowing multiplication of 64 bit integers implies >a 128 bit integer - in the hardware if not in the C code. No, there have been machines that do not include a width doubling multiply. Providing only an n*n->n bit multiplication will roughly halve the size of fast multiplier hardware compared to a n*n->2n multiplier, and improve its latency as well. For slower, more iterative multipliers, the area reduction will be smaller, but the latency improvement will be more substantial (one the order of four times). Machines have also included both forms, often with the non-widening form being faster.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-04 14:06 -0700 |
| Message-ID | <cecd57ce-9751-4277-8371-60081f9652cf@googlegroups.com> |
| In reply to | #109262 |
On Thursday, May 4, 2017 at 3:15:17 PM UTC-5, robert...@yahoo.com wrote: > A 128 bit type would actually be adequate for most currency > calculations, and only in a few places would you have to worry about > rounding errors and overflows on intermediate results. Properly rounding current calculations doesn't require large amounts of numerical precision, but instead requires storing fractions using separate numerators and denominators except at points where things are supposed to be explicitly rounded. If several line items in an order are for things that are supposed to sell 24/$1.00 on a mix-and-match basis, and the total cost of an order is supposed to be bankers'-rounded to the nearest penny, figuring the price of items at $0.0416667 each would make the cost of three items 0.125001 even though it should round down to $0.12, while figuring them as $.0416666 each would make the cost of nine items $0.3749994 even though it should round up to $0.38. One could use a million digits of precision and still get the same incorrectly-rounded results. If one figures the total price as $3/24 or $9/24, however, multiplying by 100 and then computing a quotient with remainder would yield 12r12 and 37r12, both of which can be recognized as exactly on a half-penny boundary and thus rounded correctly.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-05 00:43 -0500 |
| Message-ID | <bg3ogchn3dhstcngh40tg4d4820vd1ukrf@4ax.com> |
| In reply to | #109272 |
On Thu, 4 May 2017 14:06:42 -0700 (PDT), supercat@casperkitty.com wrote: >On Thursday, May 4, 2017 at 3:15:17 PM UTC-5, robert...@yahoo.com wrote: >> A 128 bit type would actually be adequate for most currency >> calculations, and only in a few places would you have to worry about >> rounding errors and overflows on intermediate results. > >Properly rounding current calculations doesn't require large amounts of >numerical precision, but instead requires storing fractions using separate >numerators and denominators except at points where things are supposed to >be explicitly rounded. If several line items in an order are for things >that are supposed to sell 24/$1.00 on a mix-and-match basis, and the total >cost of an order is supposed to be bankers'-rounded to the nearest penny, >figuring the price of items at $0.0416667 each would make the cost of >three items 0.125001 even though it should round down to $0.12, while >figuring them as $.0416666 each would make the cost of nine items $0.3749994 >even though it should round up to $0.38. One could use a million digits of >precision and still get the same incorrectly-rounded results. If one figures >the total price as $3/24 or $9/24, however, multiplying by 100 and then >computing a quotient with remainder would yield 12r12 and 37r12, both of >which can be recognized as exactly on a half-penny boundary and thus >rounded correctly. Rounding also applies after simple multiplication (say price * percentage) and (decimal) right scaling. But yes, extra care needs to be taken if division is involved. Applying amounts that don't divide evenly into the number of items present is always an issue, and actually leads to some intractable problems. A common example is showing how a tax applies to the individual line items. You can't actually do it in such a way that it satisfies everyone. Consider four $.25 line items, for an order total of $1.00, and assume 3% tax. So do you show $.01 on three items and zero on the fourth (which gets people asking why the fourth, identically priced, item has different tax)? Zero on all of them (why doesn't the tax on the line items add up to the tax on the whole order)? $.01 on all of them (same as problem as before)? Display the tax to extra decimal places (doesn't actually solve any of the prior problems, and pisses people off because of the extra clutter on the invoice)? That doesn't change the fact that all of those things are much easier if you have a big enough type to do the work in. And 64 bits is not generally large enough (it's almost always big enough for a storage format, but not for intermediate results). 128 bits is enough room to do many of the intermediate calculations in a straight-forward way.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-04 13:31 -0700 |
| Message-ID | <b6d21e11-30d4-44c4-819e-2d0c230d7ea5@googlegroups.com> |
| In reply to | #109256 |
On Thursday, May 4, 2017 at 3:00:19 PM UTC-5, David Kleinecke wrote: > I would see "short" as 16 bits, "int" as 32 bits and > "long" as 64 bits. I don't think the C89 standard requires > one to use "long long". I would use "long long" for 128 > bit integers which I have concluded (after a rather > long analysis of multiplication) is likely to be the > longest integer size ever needed. For a long time, the extremely vast majority of C implementations which had types for 8, 16, and 32 bits would define char as 8 bits, short as 16 bits, int as either 16 or 32 bits, and long as 32 bits. The flexibility of types to represent other sizes was mainly only exploited on machines for which the common sizes would have been unavailable; the main requirement for code to be portable among the vast majority of microcomputers was to use "short" in places that needed to be 16 bits, and "long" in places that needed to be 32. For some reason, when 64-bit types became available, some people thought that it would be better to repurpose as 64 bits the "long" type that had been 32 bits on nearly all microcomputer implementations (I'd be curious to know of *any* general-purpose microcomputer implementations that made it longer than 32 bits prior to C99), rather than use a new type name to describe the newly-available 64-bit type. The fact that "int" could be either 16 bits or 32 bits was useful for making code operate efficiently on both 8/16-bit microcomputers where individual data items were limited to 64K or less, and on 32-bit microcomputers that could handle larger structures. The fact that "short" gets promoted to "int" helps ensure that size computations which involve e.g. multiplying two 16-bit values will get promoted to 32 bits on platforms where objects could be larger than 64K (since such platforms generally make "int" 32 bits). I don't know why people want to keep changing the sizes associated with the built-in type names. A platform where "int" is 64 bits would be required by the Standard to make "long" be 64 bits as well, but aside from that I don't know why programmers that want to have new types don't want to have new names for them?
[toc] | [prev] | [next] | [standalone]
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web