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 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-03 20:37 -0700 |
| Message-ID | <1c235943-c6e2-4875-a5d2-d7bd7d904dc3@googlegroups.com> |
| In reply to | #109155 |
On Wednesday, May 3, 2017 at 6:05:40 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > [...] > > We clearly have different ideas about elegance. > > We certainly do. > > > My goal is a > > programming style that is simple and elegant. But elegance is, > > of course, in the eye of the beholder. > > BTW, I sent you an e-mail message earlier today. In reply I answered here. But the fact is that I don't really feel obligated to follow my own advice.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-04 10:22 +0200 |
| Message-ID | <20170504102249.9ffd6badb67379cac49af77c@gmail.com> |
| In reply to | #109153 |
On Wed, 3 May 2017 17:49:53 -0700 (PDT) David Kleinecke <dkleinecke@gmail.com> wrote: > We clearly have different ideas about elegance. My goal is a > programming style that is simple and elegant. But elegance is, > of course, in the eye of the beholder. Elegance is very subjective but programming is logic. Nothing less nothing more. Naming Int a signed integer and Unt an unsigned integer uses a complex logic from the programmer perspective, abusively limiting the length to no more than 3 characters. Nobody would read intuitively Unt as an unsigned integer because most of human languages rely on a radical to extend the collection of words at a small memory and logic cost. Similarly programmers uses standard identifiers or prefix (str, mem, is, ...) to extend libraries.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-04 11:01 +0100 |
| Message-ID | <kZCOA.1178476$F83.296367@fx38.am4> |
| In reply to | #108920 |
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.
C99 introduced the ability to write:
uint64_t
but which requires you to then go to the top of the program and write:
#include <stdint.h>
For short test programs, it be easier to just write 'unsigned long long
int' rather than all that punctuation and jumping about.
It's not really surprising everyone makes up their own shortcuts!
(I don't like the idea of using 'unsigned' as a modifier rather than
being a separate type. In one of my other languages I use:
int always signed (you don't have to scan left - or right -
to see if there's an unsigned lurking)
word same width as int, always unsigned
and 'dint' and 'dword' as double width versions. Or int64, word64 etc
for specific widths. When no one's looking, I might sometimes use i64 or
u64. But all are built-in so there is never need to define your own
aliases or to drag in stdint.h which is still too clumsy for many.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-04 12:18 +0200 |
| Message-ID | <20170504121818.e12842fbcac72ff9662a2616@gmail.com> |
| In reply to | #109180 |
On Thu, 4 May 2017 11:01:00 +0100 bartc <bc@freeuk.com> wrote: > C99 introduced the ability to write: > > uint64_t > > but which requires you to then go to the top of the program and write: > > #include <stdint.h> It requires a 64-bit implementation which could hit performances on non native architecture (96-bit integer architecture for example). You could use uint_least64_t instead but for a short naming I would rather write ullong_t as unsigned long long. I find limits.h is a good source of short names for integer types.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-04 11:55 +0100 |
| Message-ID | <KMDOA.89842$NT.64788@fx33.am4> |
| In reply to | #109181 |
On 04/05/2017 11:18, GOTHIER Nathan wrote:
> On Thu, 4 May 2017 11:01:00 +0100
> bartc <bc@freeuk.com> wrote:
>
>> C99 introduced the ability to write:
>>
>> uint64_t
>>
>> but which requires you to then go to the top of the program and write:
>>
>> #include <stdint.h>
>
> It requires a 64-bit implementation which could hit performances on non native
> architecture (96-bit integer architecture for example).
>
> You could use uint_least64_t instead but for a short naming I would rather
> write ullong_t as unsigned long long.
And yet another name that people prefer to use rather than the official
ones!
> I find limits.h is a good source of short
> names for integer types.
Translating from ULLONG you mean? (I couldn't find ullong_t.)
There seem to be umpteen ways of denoting a type in the language, not
including the ones people invent for themselves:
signed long long int In code (excludes re-orderings, allowed
omissions and, sometimes, repeats)
int64_t stdint.h
[PRI]d64 printf format
lld printf format
ll lL Ll LL constant suffix
LLONG[_MIN/MAX] limits.h
__int64 etc in implementation headers
Of course, the ones with '64' in the name or code don't necessarily
correspond with 'long long'. This is especially true when the start
point is 'signed long int', as equivalents will involve either 32 or 64.
(Is there constant suffix such as '-LL' that can be used to denote a
constant of type int64_t for example?)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-05-04 15:14 +0200 |
| Message-ID | <20170504151425.4a82d24c54aee30ccf754d87@gmail.com> |
| In reply to | #109182 |
On Thu, 4 May 2017 11:55:51 +0100 bartc <bc@freeuk.com> wrote: > And yet another name that people prefer to use rather than the official > ones! Indeed. It shouldn't come as a suprise that programmers are lazy enough to give new names to very long standard ones. > > I find limits.h is a good source of short > > names for integer types. > > Translating from ULLONG you mean? (I couldn't find ullong_t.) Actually I'm not the only one that got the basic idea to follow the track of the standard for consistency. source: https://gcc.gnu.org/bugzilla/attachment.cgi?id=2323 > There seem to be umpteen ways of denoting a type in the language, not > including the ones people invent for themselves: > > signed long long int In code (excludes re-orderings, allowed > omissions and, sometimes, repeats) > > int64_t stdint.h > > [PRI]d64 printf format > > lld printf format > > ll lL Ll LL constant suffix > > LLONG[_MIN/MAX] limits.h > > __int64 etc in implementation headers > > Of course, the ones with '64' in the name or code don't necessarily > correspond with 'long long'. This is especially true when the start > point is 'signed long int', as equivalents will involve either 32 or 64. > > (Is there constant suffix such as '-LL' that can be used to denote a > constant of type int64_t for example?) See 6.4.4.1 from ISO 9899.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-04 09:34 -0700 |
| Message-ID | <ln7f1weg3g.fsf@kst-u.example.com> |
| In reply to | #109182 |
bartc <bc@freeuk.com> writes:
[...]
> There seem to be umpteen ways of denoting a type in the language, not
> including the ones people invent for themselves:
>
> signed long long int In code (excludes re-orderings, allowed
> omissions and, sometimes, repeats)
>
> int64_t stdint.h
Let me just point out, since you seem to be pretending not to be
aware of it, that long long int and int64_t are not necessarily
the same type. int64_t is exactly 64 bits wide, while long long
int is *at least* 64 bits wide (though I've never heard of an
implementation where it's wider than 64 bits). And int64_t can
be an alias for long rather than for long long -- as it is on the
implementation I mostly use.
[...]
> (Is there constant suffix such as '-LL' that can be used to denote a
> constant of type int64_t for example?)
Not directly, but see the INT64_C() macro in N1570 7.20.4.1.
(It expands to a constant of type int_least64_t, not int64_t,
but with implicit conversions that generally doesn't matter.)
I know you think it's unbearably ugly and you'd rather invent your
own language to avoid using it, so you needn't bother saying 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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-04 10:09 -0700 |
| Message-ID | <fb4835a9-2aa5-4577-a207-2ac8fdf57f96@googlegroups.com> |
| In reply to | #109222 |
On Thursday, May 4, 2017 at 11:34:22 AM UTC-5, Keith Thompson wrote: > Let me just point out, since you seem to be pretending not to be > aware of it, that long long int and int64_t are not necessarily > the same type. int64_t is exactly 64 bits wide, while long long > int is *at least* 64 bits wide (though I've never heard of an > implementation where it's wider than 64 bits). And int64_t can > be an alias for long rather than for long long -- as it is on the > implementation I mostly use. The vast majority of code will never be used on any implementation where there would be any reason for "long long" not to be 64 bits. The aliasing issue is a bigger one, though, so it's good you mention it. If two functions need to exchange arrays of data, and one uses type "long long[]" and one uses type "int64_t", the only way to safely exchange data between them is to either write code that explicitly copies the data from storage of one type to storage of another in a way that can't be optimized out, or else use a compiler that recognizes the types as alias-compatible.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-04 18:25 +0100 |
| Message-ID | <QtJOA.1185420$F83.1044687@fx38.am4> |
| In reply to | #109222 |
On 04/05/2017 17:34, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > [...] >> There seem to be umpteen ways of denoting a type in the language, not >> including the ones people invent for themselves: >> >> signed long long int In code (excludes re-orderings, allowed >> omissions and, sometimes, repeats) >> >> int64_t stdint.h > > Let me just point out, since you seem to be pretending not to be > aware of it, I pointed it out in the bit you snipped: BC: > Of course, the ones with '64' in the name or code don't necessarily > correspond with 'long long'. This is especially true when the start > point is 'signed long int', as equivalents will involve either 32 or > 64. But what are the practical consequences? Will people carry on using signed long long int rather than int64_t because they might not be exactly the same type? >> (Is there constant suffix such as '-LL' that can be used to denote a >> constant of type int64_t for example?) > > Not directly, but see the INT64_C() macro in N1570 7.20.4.1. Another one to add to my collection (of type denotations corresponding to 64-bit signed int). -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-04 11:28 -0700 |
| Message-ID | <lny3uccw9b.fsf@kst-u.example.com> |
| In reply to | #109232 |
bartc <bc@freeuk.com> writes:
> On 04/05/2017 17:34, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> [...]
>>> There seem to be umpteen ways of denoting a type in the language, not
>>> including the ones people invent for themselves:
>>>
>>> signed long long int In code (excludes re-orderings, allowed
>>> omissions and, sometimes, repeats)
>>>
>>> int64_t stdint.h
>>
>> Let me just point out, since you seem to be pretending not to be
>> aware of it,
>
> I pointed it out in the bit you snipped:
>
> BC:
> > Of course, the ones with '64' in the name or code don't necessarily
> > correspond with 'long long'. This is especially true when the start
> > point is 'signed long int', as equivalents will involve either 32 or
> > 64.
I missed that. My apologies.
> But what are the practical consequences? Will people carry on using
> signed long long int rather than int64_t because they might not be
> exactly the same type?
I would *hope* that people will use long long when they need a signed
type that's at least 64 bits, and int64_t when they need a
2's-complement signed type that's exactly 64 bits with no padding bits.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-04 11:53 -0700 |
| Message-ID | <8930c4b9-231b-49e4-83b9-e3e1814bc13f@googlegroups.com> |
| In reply to | #109243 |
On Thursday, May 4, 2017 at 1:28:08 PM UTC-5, Keith Thompson wrote: > I would *hope* that people will use long long when they need a signed > type that's at least 64 bits, and int64_t when they need a > 2's-complement signed type that's exactly 64 bits with no padding bits. If a function which is supposed to populate an array doesn't care about whether the elements thereof are exactly 64 bits, and consequently uses "long long", while a function in another part of the code which is supposed to output an array is needs the values to be 64 bits exactly, is it more useful to have the first use "long long" and the second use "int64_t", or would it be better for both to use "int64_t"? If they do use different types, how should one write code which needs to use the first function to produce data and the second function to output it?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-04 13:07 +0200 |
| Message-ID | <oef1qr$4cc$1@dont-email.me> |
| In reply to | #109180 |
On 04/05/17 12:01, bartc 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. 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. > 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. IME, specifying the bit size is a lot more common than giving the size in bytes (though I agree that giving the size in bytes is more common than the log2 of the size in bytes). > >> 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. Agreed. > > C99 introduced the ability to write: > > uint64_t > > but which requires you to then go to the top of the program and write: > > #include <stdint.h> > > For short test programs, it be easier to just write 'unsigned long long > int' rather than all that punctuation and jumping about. "Jump about" ? Any C file bigger than "Hello world" is going to have a bunch of include's at the start, just following the file comments. You put #include <stdint.h> there, along with things like #include <stdbool.h>. Then you use the standard type names when you want fixed size types. Anything else for fixed size types is a relic from pre-C99 days. > > It's not really surprising everyone makes up their own shortcuts! No, not /everyone/ makes up their own shortcuts. People used to make them up before they were standardised, but I think very few people do so now. A small number of C programmers seem to think that names such as "uint64_t" are ugly and that their own preference - u64, u64_t, uint64, etc., is vastly superior. But most people understand that uint64_t is about as clear and concise as you can get, and the benefits of standardised common names far outweighs minor personal preferences. Pretty much the only time I see non-standard names for fixed size types is in code that has a history stretching back before C99, and code written by people who think "#define RTN return" is a good idea. (Of course, lots of code is quite happy with "unsigned long long int" rather than size specific types.) > > (I don't like the idea of using 'unsigned' as a modifier rather than > being a separate type. In one of my other languages I use: > > int always signed (you don't have to scan left - or right - > to see if there's an unsigned lurking) > word same width as int, always unsigned > > and 'dint' and 'dword' as double width versions. Or int64, word64 etc > for specific widths. When no one's looking, I might sometimes use i64 or > u64. But all are built-in so there is never need to define your own > aliases or to drag in stdint.h which is still too clumsy for many.) > People who think "dragging in" a standard header is "too clumsy" should look for a different profession or hobby.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-05-04 14:19 +0100 |
| Message-ID | <ETFOA.1462267$qK5.1417297@fx45.am4> |
| In reply to | #109183 |
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. I've done the same with individual for-loops to try and figure out what it was that it was doing. Some seem to think that structured code doesn't apply to for-loops. >> 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. > > IME, specifying the bit size is a lot more common than giving the size > in bytes (though I agree that giving the size in bytes is more common > than the log2 of the size in bytes). Perhaps you don't recall using integer*4 and such in Fortran. However, specifying bit-widths is the most flexible of all the methods; you can't easily denote a 17-bit type otherwise. >> 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. > > Agreed. Other than for 'short'. You tend not to see 'short int'. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-04 16:44 +0200 |
| Message-ID | <oefej0$i8u$1@dont-email.me> |
| In reply to | #109193 |
On 04/05/17 15:19, bartc wrote:
> 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. I've done the same with individual
> for-loops to try and figure out what it was that it was doing.
Oh, I can understand it for /some/ for loops. Sometimes it is clearer
(usually for some personal subjective value of "clearer") to use "while"
loops, even though someone else might have written it as a "for" loop.
If someone had written "for (; cond ;) ...", I would be much happier
seeing it as "while (cond) ...". But if I correctly interpreted David
K's posts, he would also change:
for (int i = 0; i < 10; i++) ...
into:
Int i = 0;
while (i < 10) {
...
i++;
}
which seems a big step backwards to me.
(Usually it is a bad idea to change someone else's working code just to
"improve" the style, of course.)
>
> Some seem to think that structured code doesn't apply to for-loops.
>
Some people have odd ideas about what "structured code" means. And yes,
some people put things into their for-loop clauses that I would not like
to see there. But most for loops are usually fine as they are.
>>> 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.
>>
>> IME, specifying the bit size is a lot more common than giving the size
>> in bytes (though I agree that giving the size in bytes is more common
>> than the log2 of the size in bytes).
>
> Perhaps you don't recall using integer*4 and such in Fortran.
>
I vividly recall never having used Fortran in my life. I have used
/many/ languages, to at least some extent, over the years - but I have
happily avoided Fortran (and also COBOL).
> However, specifying bit-widths is the most flexible of all the methods;
> you can't easily denote a 17-bit type otherwise.
>
I have only once had need of a 17-bit type, but I was programming in
Pascal at the time.
>>> 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.
>>
>> Agreed.
>
> Other than for 'short'. You tend not to see 'short int'.
>
You would see it as "short int" in /my/ code, never "short". But you
would not see it often - you would normally see int16_t.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-04 13:09 -0700 |
| Message-ID | <0ebb51af-956a-4f98-a441-8ab5004d7427@googlegroups.com> |
| In reply to | #109212 |
On Thursday, May 4, 2017 at 7:45:11 AM UTC-7, David Brown wrote:
> On 04/05/17 15:19, bartc wrote:
> > On 04/05/2017 12:07, David Brown wrote:
> >
> Oh, I can understand it for /some/ for loops. Sometimes it is clearer
> (usually for some personal subjective value of "clearer") to use "while"
> loops, even though someone else might have written it as a "for" loop.
> If someone had written "for (; cond ;) ...", I would be much happier
> seeing it as "while (cond) ...". But if I correctly interpreted David
> K's posts, he would also change:
>
> for (int i = 0; i < 10; i++) ...
>
> into:
>
> Int i = 0;
> while (i < 10) {
> ...
> i++;
> }
>
> which seems a big step backwards to me.
A lot depends on what goes on in the {...}. If i is never
used (happens) then
i = 10;
while (i--) { ...}
works. If i is used only once then that occurrence can be
give the ++. Otherwise it is often OK to increment the last
time i occurs in the {...}. A separate i++ is rarely needed.
> (Usually it is a bad idea to change someone else's working code just to
> "improve" the style, of course.)
>
> >
> > Some seem to think that structured code doesn't apply to for-loops.
> >
>
> Some people have odd ideas about what "structured code" means. And yes,
> some people put things into their for-loop clauses that I would not like
> to see there. But most for loops are usually fine as they are.
>
> >>> 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.
> >>
> >> IME, specifying the bit size is a lot more common than giving the size
> >> in bytes (though I agree that giving the size in bytes is more common
> >> than the log2 of the size in bytes).
> >
> > Perhaps you don't recall using integer*4 and such in Fortran.
> >
>
> I vividly recall never having used Fortran in my life. I have used
> /many/ languages, to at least some extent, over the years - but I have
> happily avoided Fortran (and also COBOL).
>
> > However, specifying bit-widths is the most flexible of all the methods;
> > you can't easily denote a 17-bit type otherwise.
> >
>
> I have only once had need of a 17-bit type, but I was programming in
> Pascal at the time.
>
> >>> 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.
> >>
> >> Agreed.
> >
> > Other than for 'short'. You tend not to see 'short int'.
> >
>
> You would see it as "short int" in /my/ code, never "short". But you
> would not see it often - you would normally see int16_t.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-05 08:17 +1200 |
| Message-ID | <en1gjnFnb5bU3@mid.individual.net> |
| In reply to | #109260 |
On 05/ 5/17 08:09 AM, David Kleinecke wrote:
> On Thursday, May 4, 2017 at 7:45:11 AM UTC-7, David Brown wrote:
>> On 04/05/17 15:19, bartc wrote:
>>> On 04/05/2017 12:07, David Brown wrote:
>>>
>> Oh, I can understand it for /some/ for loops. Sometimes it is clearer
>> (usually for some personal subjective value of "clearer") to use "while"
>> loops, even though someone else might have written it as a "for" loop.
>> If someone had written "for (; cond ;) ...", I would be much happier
>> seeing it as "while (cond) ...". But if I correctly interpreted David
>> K's posts, he would also change:
>>
>> for (int i = 0; i < 10; i++) ...
>>
>> into:
>>
>> Int i = 0;
>> while (i < 10) {
>> ...
>> i++;
>> }
>>
>> which seems a big step backwards to me.
>
> A lot depends on what goes on in the {...}. If i is never
> used (happens) then
> i = 10;
> while (i--) { ...}
> works. If i is used only once then that occurrence can be
> give the ++. Otherwise it is often OK to increment the last
> time i occurs in the {...}. A separate i++ is rarely needed.
That mixes the logic in the loop with the mechanics of the loop. Using
for() keeps them separate and avoids silly bugs such incrementing i in
the wrong place, more than once or (for a short time!) never.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-04 22:26 +0200 |
| Message-ID | <oeg2kf$tsv$1@dont-email.me> |
| In reply to | #109260 |
On 04/05/17 22:09, David Kleinecke wrote:
> On Thursday, May 4, 2017 at 7:45:11 AM UTC-7, David Brown wrote:
>> On 04/05/17 15:19, bartc wrote:
>>> On 04/05/2017 12:07, David Brown wrote:
>>>
>> Oh, I can understand it for /some/ for loops. Sometimes it is clearer
>> (usually for some personal subjective value of "clearer") to use "while"
>> loops, even though someone else might have written it as a "for" loop.
>> If someone had written "for (; cond ;) ...", I would be much happier
>> seeing it as "while (cond) ...". But if I correctly interpreted David
>> K's posts, he would also change:
>>
>> for (int i = 0; i < 10; i++) ...
>>
>> into:
>>
>> Int i = 0;
>> while (i < 10) {
>> ...
>> i++;
>> }
>>
>> which seems a big step backwards to me.
>
> A lot depends on what goes on in the {...}. If i is never
> used (happens) then
> i = 10;
> while (i--) { ...}
> works. If i is used only once then that occurrence can be
> give the ++. Otherwise it is often OK to increment the last
> time i occurs in the {...}. A separate i++ is rarely needed.
>
>
There are lots of ways a for loop like the one above can be re-written
using while. The point is, why? It will almost certainly not result in
clearer code (Ian gave some reasons for that). It will almost certainly
not result in more efficient object code.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-04 13:38 -0700 |
| Message-ID | <8488d0b1-59d8-4e25-a9a0-2071c8fcfca0@googlegroups.com> |
| In reply to | #109265 |
On Thursday, May 4, 2017 at 1:27:05 PM UTC-7, David Brown wrote:
> On 04/05/17 22:09, David Kleinecke wrote:
> > On Thursday, May 4, 2017 at 7:45:11 AM UTC-7, David Brown wrote:
> >> On 04/05/17 15:19, bartc wrote:
> >>> On 04/05/2017 12:07, David Brown wrote:
> >>>
> >> Oh, I can understand it for /some/ for loops. Sometimes it is clearer
> >> (usually for some personal subjective value of "clearer") to use "while"
> >> loops, even though someone else might have written it as a "for" loop.
> >> If someone had written "for (; cond ;) ...", I would be much happier
> >> seeing it as "while (cond) ...". But if I correctly interpreted David
> >> K's posts, he would also change:
> >>
> >> for (int i = 0; i < 10; i++) ...
> >>
> >> into:
> >>
> >> Int i = 0;
> >> while (i < 10) {
> >> ...
> >> i++;
> >> }
> >>
> >> which seems a big step backwards to me.
> >
> > A lot depends on what goes on in the {...}. If i is never
> > used (happens) then
> > i = 10;
> > while (i--) { ...}
> > works. If i is used only once then that occurrence can be
> > give the ++. Otherwise it is often OK to increment the last
> > time i occurs in the {...}. A separate i++ is rarely needed.
> >
> >
>
> There are lots of ways a for loop like the one above can be re-written
> using while. The point is, why? It will almost certainly not result in
> clearer code (Ian gave some reasons for that). It will almost certainly
> not result in more efficient object code.
Well then it doesn't matter which way one goes. If one
objects to "for" constructs on esthetic grounds - like I
do - "while" is available. And vice versa.
There is a school of thought that there should always be
only one way to do things. I don't belong.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-04 22:49 +0200 |
| Message-ID | <oeg3uc$3oo$1@dont-email.me> |
| In reply to | #109268 |
On 04/05/17 22:38, David Kleinecke wrote:
> On Thursday, May 4, 2017 at 1:27:05 PM UTC-7, David Brown wrote:
>> On 04/05/17 22:09, David Kleinecke wrote:
>>> On Thursday, May 4, 2017 at 7:45:11 AM UTC-7, David Brown wrote:
>>>> On 04/05/17 15:19, bartc wrote:
>>>>> On 04/05/2017 12:07, David Brown wrote:
>>>>>
>>>> Oh, I can understand it for /some/ for loops. Sometimes it is clearer
>>>> (usually for some personal subjective value of "clearer") to use "while"
>>>> loops, even though someone else might have written it as a "for" loop.
>>>> If someone had written "for (; cond ;) ...", I would be much happier
>>>> seeing it as "while (cond) ...". But if I correctly interpreted David
>>>> K's posts, he would also change:
>>>>
>>>> for (int i = 0; i < 10; i++) ...
>>>>
>>>> into:
>>>>
>>>> Int i = 0;
>>>> while (i < 10) {
>>>> ...
>>>> i++;
>>>> }
>>>>
>>>> which seems a big step backwards to me.
>>>
>>> A lot depends on what goes on in the {...}. If i is never
>>> used (happens) then
>>> i = 10;
>>> while (i--) { ...}
>>> works. If i is used only once then that occurrence can be
>>> give the ++. Otherwise it is often OK to increment the last
>>> time i occurs in the {...}. A separate i++ is rarely needed.
>>>
>>>
>>
>> There are lots of ways a for loop like the one above can be re-written
>> using while. The point is, why? It will almost certainly not result in
>> clearer code (Ian gave some reasons for that). It will almost certainly
>> not result in more efficient object code.
>
> Well then it doesn't matter which way one goes. If one
> objects to "for" constructs on esthetic grounds - like I
> do - "while" is available. And vice versa.
>
> There is a school of thought that there should always be
> only one way to do things. I don't belong.
>
Apparently you /are/ of the school of thought that there should only be
one way of doing things. Most C programmers aim to use "for" loops when
that is clearer, and "while" loops when they are clearer. There are
good reasons why the language has multiple ways of writing loops.
What you seem to want to do, however, is restrict the language to a
subset - specifically excluding "for" loops. And you are willing to
make a mess of existing code, rendering it almost unintelligible to
other programmers, simply because you don't like C's "for" syntax (or
its standard types).
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-04 19:58 -0700 |
| Message-ID | <ed43b027-71e7-4506-946b-1ff3c877f567@googlegroups.com> |
| In reply to | #109269 |
On Thursday, May 4, 2017 at 1:49:29 PM UTC-7, David Brown wrote:
> On 04/05/17 22:38, David Kleinecke wrote:
> > On Thursday, May 4, 2017 at 1:27:05 PM UTC-7, David Brown wrote:
> >> On 04/05/17 22:09, David Kleinecke wrote:
> >>> On Thursday, May 4, 2017 at 7:45:11 AM UTC-7, David Brown wrote:
> >>>> On 04/05/17 15:19, bartc wrote:
> >>>>> On 04/05/2017 12:07, David Brown wrote:
> >>>>>
> >>>> Oh, I can understand it for /some/ for loops. Sometimes it is clearer
> >>>> (usually for some personal subjective value of "clearer") to use "while"
> >>>> loops, even though someone else might have written it as a "for" loop.
> >>>> If someone had written "for (; cond ;) ...", I would be much happier
> >>>> seeing it as "while (cond) ...". But if I correctly interpreted David
> >>>> K's posts, he would also change:
> >>>>
> >>>> for (int i = 0; i < 10; i++) ...
> >>>>
> >>>> into:
> >>>>
> >>>> Int i = 0;
> >>>> while (i < 10) {
> >>>> ...
> >>>> i++;
> >>>> }
> >>>>
> >>>> which seems a big step backwards to me.
> >>>
> >>> A lot depends on what goes on in the {...}. If i is never
> >>> used (happens) then
> >>> i = 10;
> >>> while (i--) { ...}
> >>> works. If i is used only once then that occurrence can be
> >>> give the ++. Otherwise it is often OK to increment the last
> >>> time i occurs in the {...}. A separate i++ is rarely needed.
> >>>
> >>>
> >>
> >> There are lots of ways a for loop like the one above can be re-written
> >> using while. The point is, why? It will almost certainly not result in
> >> clearer code (Ian gave some reasons for that). It will almost certainly
> >> not result in more efficient object code.
> >
> > Well then it doesn't matter which way one goes. If one
> > objects to "for" constructs on esthetic grounds - like I
> > do - "while" is available. And vice versa.
> >
> > There is a school of thought that there should always be
> > only one way to do things. I don't belong.
> >
>
> Apparently you /are/ of the school of thought that there should only be
> one way of doing things. Most C programmers aim to use "for" loops when
> that is clearer, and "while" loops when they are clearer. There are
> good reasons why the language has multiple ways of writing loops.
>
> What you seem to want to do, however, is restrict the language to a
> subset - specifically excluding "for" loops. And you are willing to
> make a mess of existing code, rendering it almost unintelligible to
> other programmers, simply because you don't like C's "for" syntax (or
> its standard types).
You still misunderstand what I am doing. I am looking for
simplicity and elegance. I am not "seriously" coding. I usually
don't even bother to compile. I look at what I have produced and
ask - is this easier to understand?
But I observe that "easier to understand" is a very elusive
concept. I have spent enough time doing forensic programming -
by which I mean documenting what existing undocumented programs
actually do - to appreciate simplicity and elegance.
[toc] | [prev] | [next] | [standalone]
Page 4 of 13 — ← Prev page 1 2 3 [4] 5 6 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web