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 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-04-22 14:56 -0700 |
| Message-ID | <925e96ac-bdc2-4c49-9992-94e52a6c3bc0@googlegroups.com> |
| In reply to | #108342 |
On Saturday, April 22, 2017 at 11:16:55 AM UTC-5, Bart wrote:
> I expect 0x7fffffff+1 to be equal to 0x80000000. Which normally equates
> to MIN_INT. Then I would expect 0<0x80000000 to be false so that no
> iterations are performed.
Allowing a compiler to have INT_MAX+1 yield a value which may arbitrarily
behave as INT_MIN or as a number which is one larger than INT_MAX will
permit useful optimizations in many cases; if applying an (int) cast to
any value outside the range of "int" would force its truncation and sign
extension, then any semantics which could be achieved on a system that
always performs such truncation would still be achievable in code that
would generally be just as clear--if not clearer--than the original.
Given an expression like:
long long l = i1*i2;
requiring a compiler to sign-extend the bottom 32-bits of the product may
yield slower code than would result from just using a 64-bit product
directly. Likewise, given something like:
const int x = ..somevalue..;
const long long L = ..somevalue..;
for (i=0; i<100; i++)
{ ...
doSomethingWith(i*x+L);
}
it may be faster for a compiler to initialize a temporary variable to x+L and
add x once for each loop iteration, than to have to compute a 32-bit value for
i*x, sign-extend that, and add L.
Giving compilers the freedom to treat sub-expressions as longer types can
enable many useful optimizations; if code really wants values truncated to
the original type, it should explicitly specify it in a fashion analogous
to e.g. (float)(f+1.0f) > f. In the absence of a cast, a system which does
not promise to refrain from doing so could use extended precision when
evaluating the sub-expression f+1.0f and retain that precision into the
comparison. Adding the cast would force any extra precision to be discarded.
> Only because the language has said it is incorrect for EVERY possible
> implementation, even the ones where it is well-defined. And gcc takes
> advantage of that.
Where does the language say it's incorrect for every possible implementation?
It says it's "non-portable OR erroneous", but a statement "X is Y or Z"
does not in any way, shape, or form imply that X is Z except in cases where
X isn't Y.
If one recognizes that the Standard makes no attempt to mandate that any
implementation be suitable for any particular purpose, the fact that the
Standard would not regard a behavior as making an implementation non-
conforming does not imply any judgment on the part of the Committee that
the behavior would not make the implementation unsuitable for some or
many purposes.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-04-30 16:49 +0200 |
| Message-ID | <oe4tco$g5p$1@dont-email.me> |
| In reply to | #108342 |
On 22/04/2017 18:16, bartc wrote:
> I expect 0x7fffffff+1 to be equal to 0x80000000. Which normally equates
> to MIN_INT. Then I would expect 0<0x80000000 to be false so that no
> iterations are performed.
Let's consider a slightly different situation.
int foo(int n) {
return n * 2 / 2;
}
Does anyone disagree that an optimizing compiler would
determine that this is the identity function, and would
drop the calls altogether, by replacing foo(x) with x.
Yet, if a non-optimizing compiler (e.g. gcc -O0) compiles the
code literally, and the user calls foo with x = 1_500_000_000,
then the actual result would be -647483648.
I suppose the compiler could warn: "Assuming n * 2 never overflows",
but one would get such a warning for *every* multiplication. I'd
wager that warning would not be very popular, and many would
disable it.
Regards.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-04-30 16:02 +0100 |
| Message-ID | <87a86yhrai.fsf@bsb.me.uk> |
| In reply to | #108770 |
Noob <root@127.0.0.1> writes:
> On 22/04/2017 18:16, bartc wrote:
>
>> I expect 0x7fffffff+1 to be equal to 0x80000000. Which normally equates
>> to MIN_INT. Then I would expect 0<0x80000000 to be false so that no
>> iterations are performed.
>
> Let's consider a slightly different situation.
>
> int foo(int n) {
> return n * 2 / 2;
> }
>
> Does anyone disagree that an optimizing compiler would
> determine that this is the identity function, and would
> drop the calls altogether, by replacing foo(x) with x.
Yes, I would! It's a small point but if, for example, x is double
then foo(x) is not the identity function and can't be replaced by x.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-04-30 11:51 -0500 |
| Message-ID | <ad5cgcts5eplp10u0pcdgh9iivm524946g@4ax.com> |
| In reply to | #108771 |
On Sun, 30 Apr 2017 16:02:45 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:
>Noob <root@127.0.0.1> writes:
>
>> On 22/04/2017 18:16, bartc wrote:
>>
>>> I expect 0x7fffffff+1 to be equal to 0x80000000. Which normally equates
>>> to MIN_INT. Then I would expect 0<0x80000000 to be false so that no
>>> iterations are performed.
>>
>> Let's consider a slightly different situation.
>>
>> int foo(int n) {
>> return n * 2 / 2;
>> }
>>
>> Does anyone disagree that an optimizing compiler would
>> determine that this is the identity function, and would
>> drop the calls altogether, by replacing foo(x) with x.
>
>Yes, I would! It's a small point but if, for example, x is double
>then foo(x) is not the identity function and can't be replaced by x.
Perhaps a clearer, and more accurate, statement would be that we'd
expect an optimizing compiler to replace the call to foo() with
whatever the conversion of the parameter to int is.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-04-30 21:42 +0200 |
| Message-ID | <oe5ehk$dmm$1@dont-email.me> |
| In reply to | #108771 |
On 30/04/2017 17:02, Ben Bacarisse wrote:
> Noob writes:
>
>> On 22/04/2017 18:16, bartc wrote:
>>
>>> I expect 0x7fffffff+1 to be equal to 0x80000000. Which normally equates
>>> to MIN_INT. Then I would expect 0<0x80000000 to be false so that no
>>> iterations are performed.
>>
>> Let's consider a slightly different situation.
>>
>> int foo(int n) {
>> return n * 2 / 2;
>> }
>>
>> Does anyone disagree that an optimizing compiler would
>> determine that this is the identity function, and would
>> drop the calls altogether, by replacing foo(x) with x.
>
> Yes, I would! It's a small point but if, for example, x is double
> then foo(x) is not the identity function and can't be replaced by x.
Nice nit. Allow me to rephrase.
An optimizing compiler would replace foo(x) with (int)x
Regards.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-30 17:35 +0100 |
| Message-ID | <unoNA.1049563$nT1.597350@fx44.am4> |
| In reply to | #108770 |
On 30/04/2017 15:49, Noob wrote:
> On 22/04/2017 18:16, bartc wrote:
>
>> I expect 0x7fffffff+1 to be equal to 0x80000000. Which normally equates
>> to MIN_INT. Then I would expect 0<0x80000000 to be false so that no
>> iterations are performed.
>
> Let's consider a slightly different situation.
>
> int foo(int n) {
> return n * 2 / 2;
> }
>
> Does anyone disagree that an optimizing compiler would
> determine that this is the identity function, and would
> drop the calls altogether, by replacing foo(x) with x.
Only if it does the same when it's unsigned int.
I see the above operation as a left shift followed by a right shift.
With unsigned, this has would have no effect when the top bit is 0 (as a
zero will be shifted back in).
With signed, I think it has no effect when the top two bits are the same.
> Yet, if a non-optimizing compiler (e.g. gcc -O0) compiles the
> code literally, and the user calls foo with x = 1_500_000_000,
> then the actual result would be -647483648.
If I do the same with unsigned x=3 billion, and using an unsigned
version of foo, then the result will be 85251635, whether optimised or not.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-04-30 11:57 -0500 |
| Message-ID | <vi5cgc51gojjifro1q2mqv8cir4lfgv6jn@4ax.com> |
| In reply to | #108776 |
On Sun, 30 Apr 2017 17:35:39 +0100, bartc <bc@freeuk.com> wrote:
>On 30/04/2017 15:49, Noob wrote:
>> On 22/04/2017 18:16, bartc wrote:
>>
>>> I expect 0x7fffffff+1 to be equal to 0x80000000. Which normally equates
>>> to MIN_INT. Then I would expect 0<0x80000000 to be false so that no
>>> iterations are performed.
>>
>> Let's consider a slightly different situation.
>>
>> int foo(int n) {
>> return n * 2 / 2;
>> }
>>
>> Does anyone disagree that an optimizing compiler would
>> determine that this is the identity function, and would
>> drop the calls altogether, by replacing foo(x) with x.
>
>Only if it does the same when it's unsigned int.
That makes no sense.
>I see the above operation as a left shift followed by a right shift.
That's not how multiplication and division are defined in C.
>With unsigned, this has would have no effect when the top bit is 0 (as a
>zero will be shifted back in).
>
>With signed, I think it has no effect when the top two bits are the same.
>
>> Yet, if a non-optimizing compiler (e.g. gcc -O0) compiles the
>> code literally, and the user calls foo with x = 1_500_000_000,
>> then the actual result would be -647483648.
>
>If I do the same with unsigned x=3 billion, and using an unsigned
>version of foo, then the result will be 85251635, whether optimised or not.
While true, that completely misses the point. The OP used a signed
integer for a reason. It's also different if the function took a
float (and assuming IEEE math), but again, he didn't do that. This is
an example of where the compiler taking advantage of undefined
behavior (signed integer overflow), can remove "undefined" behavior
when optimization is *enabled*. Leading to even more difficulty about
warning of such a thing.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-04-30 18:44 +0100 |
| Message-ID | <iopNA.363590$0L.286761@fx12.am4> |
| In reply to | #108780 |
On 30/04/2017 17:57, Robert Wessel wrote:
> On Sun, 30 Apr 2017 17:35:39 +0100, bartc <bc@freeuk.com> wrote:
>
>> On 30/04/2017 15:49, Noob wrote:
>>> int foo(int n) {
>>> return n * 2 / 2;
>>> }
>>>
>>> Does anyone disagree that an optimizing compiler would
>>> determine that this is the identity function, and would
>>> drop the calls altogether, by replacing foo(x) with x.
>>
>> Only if it does the same when it's unsigned int.
>
>
> That makes no sense.
If you saw this anywhere else:
f(x) = x*2/2
You might be justified in calling f an identity function, whether x was
integer or float.
It's harder to justify it within the context of a programming language
where x has a fixed range and untidy things can happen at the extremes
of the range.
But if you're going to do so, you don't want to make exceptions
according to some subtle difference in representation.
I wouldn't, myself, call foo() an identity function, as I'd prefer the
expression (n*2)/2 to be evaluated as it is. However, with n*(2/2), you
can probably eliminate the multiply without much controversy.
>
>> I see the above operation as a left shift followed by a right shift.
>
>
> That's not how multiplication and division are defined in C.
It's more than likely how they would be implemented (for powers of two
anyway!). And it's how multiplying and dividing by powers of ten is done
in pen and paper calculations for decimal (add zeros or move the decimal
point).
> While true, that completely misses the point. The OP used a signed
> integer for a reason.
Actually, I think most people type 'int', even when unsigned would do,
because it's quicker than either typing 'unsigned int', or having to
commit to a width, and typing 'uint32_t' followed by checking that
stdint.h has been included.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-04-30 11:34 -0700 |
| Message-ID | <959d5007-8ac8-42f9-a6d9-b5e23feda0de@googlegroups.com> |
| In reply to | #108785 |
On Sunday, April 30, 2017 at 10:44:53 AM UTC-7, Bart wrote:
> On 30/04/2017 17:57, Robert Wessel wrote:
> > On Sun, 30 Apr 2017 17:35:39 +0100, bartc <bc@freeuk.com> wrote:
> >
> >> On 30/04/2017 15:49, Noob wrote:
>
> >>> int foo(int n) {
> >>> return n * 2 / 2;
> >>> }
> >>>
> >>> Does anyone disagree that an optimizing compiler would
> >>> determine that this is the identity function, and would
> >>> drop the calls altogether, by replacing foo(x) with x.
> >>
> >> Only if it does the same when it's unsigned int.
> >
> >
> > That makes no sense.
>
> If you saw this anywhere else:
>
> f(x) = x*2/2
>
> You might be justified in calling f an identity function, whether x was
> integer or float.
>
> It's harder to justify it within the context of a programming language
> where x has a fixed range and untidy things can happen at the extremes
> of the range.
>
> But if you're going to do so, you don't want to make exceptions
> according to some subtle difference in representation.
>
> I wouldn't, myself, call foo() an identity function, as I'd prefer the
> expression (n*2)/2 to be evaluated as it is. However, with n*(2/2), you
> can probably eliminate the multiply without much controversy.
>
> >
> >> I see the above operation as a left shift followed by a right shift.
> >
> >
> > That's not how multiplication and division are defined in C.
>
> It's more than likely how they would be implemented (for powers of two
> anyway!). And it's how multiplying and dividing by powers of ten is done
> in pen and paper calculations for decimal (add zeros or move the decimal
> point).
>
> > While true, that completely misses the point. The OP used a signed
> > integer for a reason.
>
> Actually, I think most people type 'int', even when unsigned would do,
> because it's quicker than either typing 'unsigned int', or having to
> commit to a width, and typing 'uint32_t' followed by checking that
> stdint.h has been included.
If one is thinking calculation signed int is more natural
but unsigned is more natural in (I believe) most uses of C.
But I fear it is far too late to make "int" mean "unsigned
int". I usually cheat by typedeffing "Int" as "unsigned int"
and using Int the "default" type.
PS: I have a general practice of making all type names
camel case - Bool, Long, LongLong, Void, etc. So sometimes
I let Int be signed and Unt be unsigned integers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-04-30 12:03 -0700 |
| Message-ID | <lnk261k99s.fsf@kst-u.example.com> |
| In reply to | #108789 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> If one is thinking calculation signed int is more natural
> but unsigned is more natural in (I believe) most uses of C.
> But I fear it is far too late to make "int" mean "unsigned
> int". I usually cheat by typedeffing "Int" as "unsigned int"
> and using Int the "default" type.
Please never ask me to read your code.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-04-30 15:30 -0700 |
| Message-ID | <4f4af26d-e5a6-4696-a31a-943d8d46ea5a@googlegroups.com> |
| In reply to | #108793 |
On Sunday, April 30, 2017 at 12:03:50 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > [...] > > If one is thinking calculation signed int is more natural > > but unsigned is more natural in (I believe) most uses of C. > > But I fear it is far too late to make "int" mean "unsigned > > int". I usually cheat by typedeffing "Int" as "unsigned int" > > and using Int the "default" type. > > Please never ask me to read your code. I may some day post some code. Feel free to ignore it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-04-30 21:18 +0200 |
| Message-ID | <oe5d3k$6fr$1@dont-email.me> |
| In reply to | #108789 |
On 30/04/17 20:34, David Kleinecke wrote: > On Sunday, April 30, 2017 at 10:44:53 AM UTC-7, Bart wrote: >> Actually, I think most people type 'int', even when unsigned would do, >> because it's quicker than either typing 'unsigned int', or having to >> commit to a width, and typing 'uint32_t' followed by checking that >> stdint.h has been included. > > If one is thinking calculation signed int is more natural > but unsigned is more natural in (I believe) most uses of C. > But I fear it is far too late to make "int" mean "unsigned > int". I usually cheat by typedeffing "Int" as "unsigned int" > and using Int the "default" type. That strikes me as an extraordinarily bad idea. And I have seen many bad ideas in C programming. I use a lot more unsigned types in my coding than is common in C - often they are a more natural choice in low-level embedded programming. But I write "uint32_t", or sometimes "unsigned int". Then anyone reading the code can understand exactly what the types are. If you call your type "Int", anyone looking at your code will first be confused as to why there is a capital there. Then they will assume it is an "int", and perhaps you normally code in Pascal rather than C. I doubt if anyone would consider it likely that you meant an "unsigned int" - it would be viewed as so unlikely that many would not bother to check. > > PS: I have a general practice of making all type names > camel case - Bool, Long, LongLong, Void, etc. So sometimes > I let Int be signed and Unt be unsigned integers. > So sometimes you use Int to mean "signed int", and sometimes you use it to mean "unsigned int". I thought it would be hard to come up with a worse idea than using "Int" for "unsigned int" - but it seems I underestimated you! If a type has a standard name, use it. If you have some serious aversion to writing bool, long, etc., then at the very least make sure that Bool, Long, etc., are defined exactly as the normal lower case versions.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-04-30 15:33 -0700 |
| Message-ID | <36d67442-8861-41b5-b5b3-f71681740e59@googlegroups.com> |
| In reply to | #108795 |
On Sunday, April 30, 2017 at 12:18:23 PM UTC-7, David Brown wrote: > On 30/04/17 20:34, David Kleinecke wrote: > > On Sunday, April 30, 2017 at 10:44:53 AM UTC-7, Bart wrote: > > >> Actually, I think most people type 'int', even when unsigned would do, > >> because it's quicker than either typing 'unsigned int', or having to > >> commit to a width, and typing 'uint32_t' followed by checking that > >> stdint.h has been included. > > > > If one is thinking calculation signed int is more natural > > but unsigned is more natural in (I believe) most uses of C. > > But I fear it is far too late to make "int" mean "unsigned > > int". I usually cheat by typedeffing "Int" as "unsigned int" > > and using Int the "default" type. > > That strikes me as an extraordinarily bad idea. And I have seen many > bad ideas in C programming. > > I use a lot more unsigned types in my coding than is common in C - often > they are a more natural choice in low-level embedded programming. But I > write "uint32_t", or sometimes "unsigned int". Then anyone reading the > code can understand exactly what the types are. > > If you call your type "Int", anyone looking at your code will first be > confused as to why there is a capital there. Then they will assume it > is an "int", and perhaps you normally code in Pascal rather than C. I > doubt if anyone would consider it likely that you meant an "unsigned > int" - it would be viewed as so unlikely that many would not bother to > check. > > > > > PS: I have a general practice of making all type names > > camel case - Bool, Long, LongLong, Void, etc. So sometimes > > I let Int be signed and Unt be unsigned integers. > > > > So sometimes you use Int to mean "signed int", and sometimes you use it > to mean "unsigned int". I thought it would be hard to come up with a > worse idea than using "Int" for "unsigned int" - but it seems I > underestimated you! > > If a type has a standard name, use it. If you have some serious > aversion to writing bool, long, etc., then at the very least make sure > that Bool, Long, etc., are defined exactly as the normal lower case > versions. The kind of code I read and write rather rarely has any simple types other than Bool and Void. Most of the types are typedefs of structs. ty
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-01 16:27 +0200 |
| Message-ID | <oe7ge5$p9u$1@dont-email.me> |
| In reply to | #108820 |
On 01/05/17 00:33, David Kleinecke wrote: > On Sunday, April 30, 2017 at 12:18:23 PM UTC-7, David Brown wrote: >> >> So sometimes you use Int to mean "signed int", and sometimes you use it >> to mean "unsigned int". I thought it would be hard to come up with a >> worse idea than using "Int" for "unsigned int" - but it seems I >> underestimated you! >> >> If a type has a standard name, use it. If you have some serious >> aversion to writing bool, long, etc., then at the very least make sure >> that Bool, Long, etc., are defined exactly as the normal lower case >> versions. > > The kind of code I read and write rather rarely has any simple > types other than Bool and Void. Most of the types are typedefs > of structs. > ty > It's fine to give your own types your own names. All I am saying is don't give existing standard types new names that are confusing or pointless, and don't pick names that are confusingly like existing standard types.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-01 10:16 -0700 |
| Message-ID | <935683a9-7c2e-4f71-adcc-998d8a7fe0b4@googlegroups.com> |
| In reply to | #108872 |
On Monday, May 1, 2017 at 7:27:33 AM UTC-7, David Brown wrote:
> On 01/05/17 00:33, David Kleinecke wrote:
> > On Sunday, April 30, 2017 at 12:18:23 PM UTC-7, David Brown wrote:
>
> >>
> >> So sometimes you use Int to mean "signed int", and sometimes you use it
> >> to mean "unsigned int". I thought it would be hard to come up with a
> >> worse idea than using "Int" for "unsigned int" - but it seems I
> >> underestimated you!
> >>
> >> If a type has a standard name, use it. If you have some serious
> >> aversion to writing bool, long, etc., then at the very least make sure
> >> that Bool, Long, etc., are defined exactly as the normal lower case
> >> versions.
> >
> > The kind of code I read and write rather rarely has any simple
> > types other than Bool and Void. Most of the types are typedefs
> > of structs.
> > ty
> >
>
> It's fine to give your own types your own names. All I am saying is
> don't give existing standard types new names that are confusing or
> pointless, and don't pick names that are confusingly like existing
> standard types.
I agree with that in general but we may differ in detail. I
include
typedef signed int Int;
typedef unsigned int Unt;
typedef void Void;
in order to start all type names with a capital. I find the
convention of starting type name with a capital helpful - I
suspect other people may deplore it. De gustibus.
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.
I know there are other versions of this stuff. Most of the
others are hideous.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-01 11:34 -0700 |
| Message-ID | <lnvapkh1eb.fsf@kst-u.example.com> |
| In reply to | #108899 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, May 1, 2017 at 7:27:33 AM UTC-7, David Brown wrote:
>> On 01/05/17 00:33, David Kleinecke wrote:
>> > On Sunday, April 30, 2017 at 12:18:23 PM UTC-7, David Brown wrote:
>> >> So sometimes you use Int to mean "signed int", and sometimes you use it
>> >> to mean "unsigned int". I thought it would be hard to come up with a
>> >> worse idea than using "Int" for "unsigned int" - but it seems I
>> >> underestimated you!
>> >>
>> >> If a type has a standard name, use it. If you have some serious
>> >> aversion to writing bool, long, etc., then at the very least make sure
>> >> that Bool, Long, etc., are defined exactly as the normal lower case
>> >> versions.
>> >
>> > The kind of code I read and write rather rarely has any simple
>> > types other than Bool and Void. Most of the types are typedefs
>> > of structs.
>> > ty
>>
>> It's fine to give your own types your own names. All I am saying is
>> don't give existing standard types new names that are confusing or
>> pointless, and don't pick names that are confusingly like existing
>> standard types.
>
> I agree with that in general but we may differ in detail. I
> include
> typedef signed int Int;
> typedef unsigned int Unt;
> typedef void Void;
> in order to start all type names with a capital. I find the
> convention of starting type name with a capital helpful - I
> suspect other people may deplore it. De gustibus.
You can do that if you like. I don't like it, but you're not required
to conform to my personal taste. (If I were to do something like that,
I'd find "Uint" much clearer than "Unt".)
> 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.
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.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-03 12:43 -0700 |
| Message-ID | <d324d0ed-f01a-40fe-97a4-7f73aa40e51d@googlegroups.com> |
| In reply to | #108920 |
On Monday, May 1, 2017 at 11:34:27 AM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Monday, May 1, 2017 at 7:27:33 AM UTC-7, David Brown wrote: > >> On 01/05/17 00:33, David Kleinecke wrote: > >> > On Sunday, April 30, 2017 at 12:18:23 PM UTC-7, David Brown wrote: > >> >> So sometimes you use Int to mean "signed int", and sometimes you use it > >> >> to mean "unsigned int". I thought it would be hard to come up with a > >> >> worse idea than using "Int" for "unsigned int" - but it seems I > >> >> underestimated you! > >> >> > >> >> If a type has a standard name, use it. If you have some serious > >> >> aversion to writing bool, long, etc., then at the very least make sure > >> >> that Bool, Long, etc., are defined exactly as the normal lower case > >> >> versions. > >> > > >> > The kind of code I read and write rather rarely has any simple > >> > types other than Bool and Void. Most of the types are typedefs > >> > of structs. > >> > ty > >> > >> It's fine to give your own types your own names. All I am saying is > >> don't give existing standard types new names that are confusing or > >> pointless, and don't pick names that are confusingly like existing > >> standard types. > > > > I agree with that in general but we may differ in detail. I > > include > > typedef signed int Int; > > typedef unsigned int Unt; > > typedef void Void; > > in order to start all type names with a capital. I find the > > convention of starting type name with a capital helpful - I > > suspect other people may deplore it. De gustibus. > > You can do that if you like. I don't like it, but you're not required > to conform to my personal taste. (If I were to do something like that, > I'd find "Uint" much clearer than "Unt".) > > > 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. > > 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. I experiment with things outside the box. I generally rewrite other people's source code in different styles and look at the result. I decided that using Int for unsigned integers was not a great idea - regardless of whether it was the way things "should" have been done - for the reasons you adduce. I fear I did not make that clear earlier. The Unt idea, on the other hand, seem to be acceptable. I see no reason for the extra letter in Uint.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-03 12:54 -0700 |
| Message-ID | <lnvaphemww.fsf@kst-u.example.com> |
| In reply to | #109133 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> I experiment with things outside the box. I generally rewrite
> other people's source code in different styles and look at the
> result. I decided that using Int for unsigned integers was not
> a great idea - regardless of whether it was the way things "should"
> have been done - for the reasons you adduce. I fear I did not make
> that clear earlier.
Glad to hear it!
> The Unt idea, on the other hand, seem to be
> acceptable. I see no reason for the extra letter in Uint.
If I saw the word "Unt" in isolation, I would have no idea what
it means. (My first thought was "Untermenschen".) Chopping off the
first letter of "integer" to form an abbreviation is something I find
strongly counterintuitive; it almost completely loses the mental
association with the word "integer". Apparently your intuition
differs from mine.
On the other hand, there is ample precedent for using "uint" as an
abbreviation for "unsigned int" or "unsigned integer".
If you find "Unt" clear enough for your own purposes, that's fine.
If your intent is to communicate with others, I suggest that "Unt"
would be a barrier to that communication. (One minor data point:
I've found myself typing "Uint" several times while writing this,
and had to go back and delete the 'i'.)
Personally I find little or no value in creating abbreviated names for
existing types. If I want to refer to type unsigned int, I'll type
either "unsigned int" or "unsigned".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-05-03 17:49 -0700 |
| Message-ID | <a801c87b-fd02-4217-8536-7f2f5e7102ac@googlegroups.com> |
| In reply to | #109135 |
On Wednesday, May 3, 2017 at 12:54:48 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > [...] > > I experiment with things outside the box. I generally rewrite > > other people's source code in different styles and look at the > > result. I decided that using Int for unsigned integers was not > > a great idea - regardless of whether it was the way things "should" > > have been done - for the reasons you adduce. I fear I did not make > > that clear earlier. > > Glad to hear it! > > > The Unt idea, on the other hand, seem to be > > acceptable. I see no reason for the extra letter in Uint. > > If I saw the word "Unt" in isolation, I would have no idea what > it means. (My first thought was "Untermenschen".) Chopping off the > first letter of "integer" to form an abbreviation is something I find > strongly counterintuitive; it almost completely loses the mental > association with the word "integer". Apparently your intuition > differs from mine. > > On the other hand, there is ample precedent for using "uint" as an > abbreviation for "unsigned int" or "unsigned integer". > > If you find "Unt" clear enough for your own purposes, that's fine. > If your intent is to communicate with others, I suggest that "Unt" > would be a barrier to that communication. (One minor data point: > I've found myself typing "Uint" several times while writing this, > and had to go back and delete the 'i'.) > > Personally I find little or no value in creating abbreviated names for > existing types. If I want to refer to type unsigned int, I'll type > either "unsigned int" or "unsigned". 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-03 18:05 -0700 |
| Message-ID | <lnk25xe8iq.fsf@kst-u.example.com> |
| In reply to | #109153 |
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.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web