Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #147715 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2019-11-07 10:39 -0500 |
| Last post | 2019-11-11 00:56 +0000 |
| Articles | 20 on this page of 220 — 19 participants |
Back to article view | Back to comp.lang.c
mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 10:39 -0500
Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-07 07:48 -0800
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-07 16:02 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 11:34 -0500
Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-07 08:41 -0800
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 13:02 -0500
Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-07 10:37 -0800
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 14:38 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 16:44 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 13:01 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 10:39 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 10:52 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 11:12 +0100
Re: mergesort code segfaulting on smallish arrays Barry Schwarz <schwarzb@delq.com> - 2019-11-07 12:28 -0800
Re: mergesort code segfaulting on smallish arrays jadill33@gmail.com - 2019-11-07 13:13 -0800
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-08 00:55 +0000
Re: mergesort code segfaulting on smallish arrays jadill33@gmail.com - 2019-11-08 05:30 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 14:50 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 09:31 -0500
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 09:39 -0500
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-08 17:53 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 13:15 -0500
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-08 20:01 +0000
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 00:24 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 09:44 -0500
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 15:45 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 14:30 -0500
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 12:41 -0500
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 19:29 +0000
Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 14:59 -0500
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 22:00 +0000
Re: mergesort code segfaulting on smallish arrays Ian Collins <ian-news@hotmail.com> - 2019-11-10 11:24 +1300
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 22:48 +0000
Re: mergesort code segfaulting on smallish arrays Ian Collins <ian-news@hotmail.com> - 2019-11-10 12:09 +1300
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 14:46 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:11 +0000
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 17:27 +0100
Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-09 14:53 -0800
Re: mergesort code segfaulting on smallish arrays Ian Collins <ian-news@hotmail.com> - 2019-11-10 12:02 +1300
Re: mergesort code segfaulting on smallish arrays Ian Collins <ian-news@hotmail.com> - 2019-11-09 09:25 +1300
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-09 20:18 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 21:55 -0500
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-10 09:49 +0000
Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-07 10:34 -0800
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-07 16:12 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 12:19 -0500
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-07 17:42 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 13:32 -0500
Re: mergesort code segfaulting on smallish arrays Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-11-07 11:15 -0700
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-07 21:57 +0000
Re: mergesort code segfaulting on smallish arrays Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-11-07 19:11 -0700
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-07 21:57 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 09:21 +0100
Re: mergesort code segfaulting on smallish arrays chad <cdalten@gmail.com> - 2019-11-08 04:10 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 13:21 +0100
Re: mergesort code segfaulting on smallish arrays chad <cdalten@gmail.com> - 2019-11-13 04:12 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 13:55 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 09:20 -0500
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 10:23 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 16:36 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 11:56 -0500
Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-08 09:42 -0800
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 13:39 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 17:14 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 12:00 -0500
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:27 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-15 08:17 +0100
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 13:16 -0800
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-15 22:35 +0000
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-16 13:34 -0800
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-16 23:01 +0000
Re: mergesort code segfaulting on smallish arrays Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-17 08:34 +0000
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-17 09:13 +0000
Re: mergesort code segfaulting on smallish arrays Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-17 09:30 +0000
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-17 13:53 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 10:27 +0100
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-17 09:44 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 10:50 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 07:26 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 18:07 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 12:40 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 20:41 +0100
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:28 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 06:14 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 08:03 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 02:20 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 08:21 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 08:30 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 12:50 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 19:18 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 14:27 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 07:46 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 09:32 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-13 09:34 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 16:01 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 17:19 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-13 16:32 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 17:50 +0100
Re: mergesort code segfaulting on smallish arrays chad <cdalten@gmail.com> - 2019-11-13 11:09 -0800
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-13 19:18 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 20:31 +0100
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 17:12 -0800
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 20:26 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 06:16 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 06:40 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-14 01:11 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 10:41 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 06:42 +0100
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 21:56 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 10:42 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 06:39 +0100
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 21:38 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 14:33 +0100
Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-08 05:44 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 14:48 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 15:01 +0100
Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-08 08:00 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 17:12 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-08 16:34 +0000
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-12 17:05 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 18:07 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-08 23:50 +0000
Re: mergesort code segfaulting on smallish arrays Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 19:55 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 17:27 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-09 19:33 +0000
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-09 18:05 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 05:58 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 12:39 +0000
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 12:48 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 14:38 +0100
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-10 13:42 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 14:46 +0100
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-10 14:04 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:05 +0100
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-10 14:09 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:19 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:06 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:22 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:30 +0000
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:36 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:59 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 15:26 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:56 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 15:21 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 16:28 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 15:38 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 16:58 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 16:59 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 16:24 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 17:37 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-10 17:22 +0000
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 18:04 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 19:10 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 19:14 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-11 02:14 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-10 22:07 -0500
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-11 22:16 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-11 06:52 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-11 10:33 -0800
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-11 23:28 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 10:56 +0100
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-12 02:35 -0800
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-12 15:01 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 16:08 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-12 15:53 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 16:56 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-11 13:45 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 08:00 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 17:03 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 08:27 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 17:29 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 08:18 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 17:27 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 08:43 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 18:01 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 09:41 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 18:44 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 11:00 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 20:03 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 11:22 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 20:24 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 11:44 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 06:23 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-13 06:40 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 16:34 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-13 08:41 -0800
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-11 11:24 -0800
Re: mergesort code segfaulting on smallish arrays Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-10 05:13 -0800
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-09 19:36 +0000
Re: mergesort code segfaulting on smallish arrays Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-10 05:27 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 05:25 +0100
Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 11:30 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 17:49 +0100
Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 12:21 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 18:53 +0100
Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 13:33 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 19:37 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 18:51 +0000
Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 14:46 -0500
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 15:35 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:48 +0000
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 15:35 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:39 +0100
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 19:54 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 19:55 +0100
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 21:34 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 21:37 +0100
Re: mergesort code segfaulting on smallish arrays Robert Wessel <robertwessel2@yahoo.com> - 2019-11-11 11:12 -0600
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 15:28 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:41 +0100
Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-09 12:47 -0800
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 15:08 +0100
Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-10 14:30 -0800
Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-09 12:43 -0800
Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 17:16 -0500
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-09 19:27 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 05:55 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-10 16:45 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 17:53 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-11 00:56 +0000
Page 11 of 11 — ← Prev page 1 … 9 10 [11]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-10 14:48 +0000 |
| Message-ID | <ZqVxF.170442$u64.12272@fx35.am4> |
| In reply to | #147895 |
On 10/11/2019 14:35, David Brown wrote: > On 09/11/2019 19:51, Bart wrote: >> My two private languages have used 64-bit 'int' for a while now. It's >> perfect, as you rarely need to worry about things overflowing; it will >> accommodate most things you want to do. >> > > When you are dealing with a new language, or one without significant > existing code, a 64-bit basic type is a good idea. So I agree with your > decision for your own languages. > > But C and C++ are not such languages, and making changes to what people > assume is not to be done lightly. That's funny because C makes a big deal of it not pinning down the exact size of an int. You'd think that would make it much easier in that language! It is easy to say that any > well-written C code that works with 32-bit int should continue to work > with 64-bit int - but it is not always that way in practice, and not all > code is well-written. There is also the fact that some code could get > significantly slower if int gets bigger, due to lower cache hit rates > and higher memory bus loads. That would also have been the case when int moved from 16 bits to 32 bits. It is the case anyway when programs move from a 32-bit to 64-bit processor, as pointers become double the size. Including some structs increasing in size not just because of pointers, but by extra padding to preserve alignment. Anyway I think there might be a case for C that moves to 64-bit everything (integer constants, auto-promotion etc) but 'int' itself is a synonym for int32_t. But there will be lots of subtle changes in behaviour, some useful (overflow of int32*int32 no longer undefined for example, as the calculation is done as int64*int64 and the result will be in range).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-10 15:35 +0100 |
| Message-ID | <qq977t$8p2$2@dont-email.me> |
| In reply to | #147837 |
On 09/11/2019 19:37, Bonita Montero wrote: >> How sure you you of that? They may not exist on the 'Desktop', but many >> things still exist in the embedded market. Saturating math is even an >> advertised feature on some machines (typically DSPs) > > CPUs with didn't use 2's complement vanished in the 70s. > You really haven't understood the difference between representation and overflow behaviour, have you?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 15:39 +0100 |
| Message-ID | <qq97f9$8h8$1@news.albasani.net> |
| In reply to | #147896 |
>>> How sure you you of that? They may not exist on the 'Desktop', but many >>> things still exist in the embedded market. Saturating math is even an >>> advertised feature on some machines (typically DSPs) >> CPUs with didn't use 2's complement vanished in the 70s. > You really haven't understood the difference between representation and > overflow behaviour, have you? I've understood, but not you. In fact, with 2's complement, any value of high - low when they're both signed can be converted to an unsigned value of the same width and you get the proper distance.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-10 19:54 +0100 |
| Message-ID | <qq9mdg$6ok$1@dont-email.me> |
| In reply to | #147898 |
On 10/11/2019 15:39, Bonita Montero wrote: >>>> How sure you you of that? They may not exist on the 'Desktop', but many >>>> things still exist in the embedded market. Saturating math is even an >>>> advertised feature on some machines (typically DSPs) > >>> CPUs with didn't use 2's complement vanished in the 70s. > >> You really haven't understood the difference between representation >> and overflow behaviour, have you? > > I've understood, but not you. In fact, with 2's complement, any value > of high - low when they're both signed can be converted to an unsigned > value of the same width and you get the proper distance. When "high" and "low" are signed int, you can't calculate any value of "high - low". If you want wrapping semantics on the operation, and you are using C or C++, you need to cast them to unsigned /first/, before the operation. Not after the subtraction.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 19:55 +0100 |
| Message-ID | <qq9mfn$331$1@news.albasani.net> |
| In reply to | #147922 |
> When "high" and "low" are signed int, you can't calculate any value of > "high - low". If you want wrapping semantics on the operation, and you > are using C or C++, you need to cast them to unsigned /first/, before > the operation. Not after the subtraction. Doesn't actually matter if you convert them before or not on all archi- tectures for decades.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-10 21:34 +0100 |
| Message-ID | <qq9s8e$cbd$2@dont-email.me> |
| In reply to | #147923 |
On 10/11/2019 19:55, Bonita Montero wrote: >> When "high" and "low" are signed int, you can't calculate any value of >> "high - low". If you want wrapping semantics on the operation, and >> you are using C or C++, you need to cast them to unsigned /first/, >> before the operation. Not after the subtraction. > > Doesn't actually matter if you convert them before or not on all archi- > tectures for decades. That would be true - /if/ the C language, or at least C compilers, guaranteed two's complement wrapping. They don't. I've already shown you examples of how MSVC does not have two's complement wrapping for signed integer overflow, and it is well known that gcc and clang don't support it. There is a fair chance that you would get the answer you wanted due to luck. I don't see luck as a good basis for writing code.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 21:37 +0100 |
| Message-ID | <qq9sdm$jgc$1@news.albasani.net> |
| In reply to | #147925 |
>>> When "high" and "low" are signed int, you can't calculate any value >>> of "high - low". If you want wrapping semantics on the operation, >>> and you are using C or C++, you need to cast them to unsigned >>> /first/, before the operation. Not after the subtraction. >> Doesn't actually matter if you convert them before or not on all archi- >> tectures for decades. > That would be true - /if/ the C language, or at least C compilers, > guaranteed two's complement wrapping. They do what the CPU's capabilties are. And the capabilities of all today's CPUs guarantee that if you subtract high - low where both are signed, you can convert this to unsigned safely. What the standard says is irrelevant theory here.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-11-11 11:12 -0600 |
| Message-ID | <fd5jsepb3m13ecl08qnfps9bniaf3msnqq@4ax.com> |
| In reply to | #147837 |
On Sat, 9 Nov 2019 19:37:03 +0100, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> How sure you you of that? They may not exist on the 'Desktop', but many >> things still exist in the embedded market. Saturating math is even an >> advertised feature on some machines (typically DSPs) > >CPUs with didn't use 2's complement vanished in the 70s. Unisys is still selling Clearpath IX systems that have the old Univac 2200 ISA (9-bit bytes, ones' complement). And while all the new boxes are emulated on Intel chips, I believe there is still a fair market in the last generation of "real" hardware (and at least as of a few years ago, you could even buy one from Unisys). There's even a C (89) compiler.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-10 15:28 +0100 |
| Message-ID | <qq96ph$69a$1@dont-email.me> |
| In reply to | #147836 |
On 09/11/2019 19:33, Richard Damon wrote: > On 11/9/19 12:53 PM, Bonita Montero wrote: > >>> My guess is that if/when we get to 128 bit processors, there may well be >>> a need for int to grow up to 64 (or even 128 bits) and we will add types >>> like short short (and maybe even long short). The language might also >>> evolve to assume the 8-bit byte and make the fixed sized types the >>> natural types. >> >> I think there will be never CPUs with 128 bit general-purpose registers. >> Everything beyond 64 bit is used for large-integer-arithmetics and that >> will be composed of smaller data types handled in assembly or with in- >> trinsic compiler-functions. RISC-V is designed to support 32-bit, 64-bit and 128-bit versions, but I don't think the details of the 128-bit variant are fully completed, simply because no one sees it as likely that there will be a need for an implementation any time soon.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 15:41 +0100 |
| Message-ID | <qq97i8$8h8$2@news.albasani.net> |
| In reply to | #147893 |
> RISC-V is designed to support 32-bit, 64-bit and 128-bit versions, but > I don't think the details of the 128-bit variant are fully completed, > simply because no one sees it as likely that there will be a need for > an implementation any time soon. I think you can be pretty sure that no one will build a CPU with 128 bit integer-register. Their use would be too rare that this wouldn't justify the effort.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-11-09 12:47 -0800 |
| Message-ID | <lnwoc83hgi.fsf@kst-u.example.com> |
| In reply to | #147831 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 11/9/19 11:49 AM, Bonita Montero wrote:
[...]
>> There should be no compiler with an int larger than 32 bit.
>
> Yes, I currently know of none, which is why that assumption may be
> acceptable, but it is possible.
I've used machines with 64-bit short, int, long, and long long
(Cray vector machines). char probably would have been 64 bits if
there hasn't been a requirement for UNIX compatibility.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-10 15:08 +0100 |
| Message-ID | <qq95kr$unn$1@dont-email.me> |
| In reply to | #147831 |
On 09/11/2019 18:21, Richard Damon wrote: > On 11/9/19 11:49 AM, Bonita Montero wrote: >>> high and low are signed, so their difference will be signed (and then >>> the answer converted to unsigned. >> >> Pure theory. There is actually no machine where the differencee >> can't be represented in an unsigned as long as low is <= high. > > It isn't that the difference can't be expressed as an unsigned (which > actually it can't on every machine, as UNSIGNED_MAX might be equal to > INT_MAX, this normally happening on machines that use sign-magnitude > representation), but that integer overflow is undefined. I know of > machines that INT_MAX - INT_MIN would yield INT_MAX, because they used > saturating mathematics (these were machines used for signal processing). > > It may well be that on every machine that YOU have used, signed overflow > has quietly wrapped, and thus the statement 'worked', but it is not > promised by the Standard (but might be by a given implementation). > > >> >>> An actual sequence is: >>> >>> get rand() >>> convert to uint64_t and save for later >>> compute high - low as int >>> convert difference to unsigned >>> convert difference to uint64_t >>> multiply difference by saved rand (as a uint64_t) >>> divide by RAND_MAX >>> convert to int >>> add low >> >> That's what I actually do. The conversion of the difference from >> unsigned to uint64_t is done implicitly. >> >>> The code also assume (perhaps acceptably) that RAND_MAX fits in 32 bits. >> >> There should be no compiler with an int larger than 32 bit. > > Yes, I currently know of none, which is why that assumption may be > acceptable, but it is possible. I believe some Cray systems used 64-bit for short, int and long. (That is based entirely on reading on the web, not on any personal experience.) > By the straight reading of the language, > on 64 bit processors, int should have been 64 bits, and long 128 bits. > The fact that it would leave a hole in the type system, with no natural > name for both 16 and 32 bit types provided a push to make int 'too > small' for the machine at 32 bits. (It also helped that much code > mistakenly assumes int is 32 bits and that the processors handle 32 bit > ints well). > > My guess is that if/when we get to 128 bit processors, there may well be > a need for int to grow up to 64 (or even 128 bits) and we will add types > like short short (and maybe even long short). The language might also > evolve to assume the 8-bit byte and make the fixed sized types the > natural types. > I suspect that is unlikely. Sizes are ingrained in peoples' minds, regardless of what the standard says. And 8-bit char, 16-bit short and 32-bit int is very convenient, and will continue to be very convenient even if processors start handling 128 bit sizes more efficiently. The number of uses of integers that are bigger than 32-bit is quiet small, and the cache miss ratio costs of 64-bit int would be high. Most integer usage bigger than 32-bit is in sizes of data in memory or file, and 64-bit is going to cover that for a long time. How often do you have need of an integer type that is bigger than 64-bit, but where 128-bit is really helpful? If you are moving data around, or doing cryptography, hashes, etc., you really want a lot bigger than 128-bit. Of course, any prediction of "this should be big enough for anyone" is going to be wrong :-)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-11-10 14:30 -0800 |
| Message-ID | <lnk1872wki.fsf@kst-u.example.com> |
| In reply to | #147887 |
David Brown <david.brown@hesbynett.no> writes:
> On 09/11/2019 18:21, Richard Damon wrote:
[...]
> I believe some Cray systems used 64-bit for short, int and long. (That
> is based entirely on reading on the web, not on any personal experience.)
Yes, I mentioned it here yesterday.
>> By the straight reading of the language,
>> on 64 bit processors, int should have been 64 bits, and long 128 bits.
>> The fact that it would leave a hole in the type system, with no natural
>> name for both 16 and 32 bit types provided a push to make int 'too
>> small' for the machine at 32 bits. (It also helped that much code
>> mistakenly assumes int is 32 bits and that the processors handle 32 bit
>> ints well).
>>
>> My guess is that if/when we get to 128 bit processors, there may well be
>> a need for int to grow up to 64 (or even 128 bits) and we will add types
>> like short short (and maybe even long short). The language might also
>> evolve to assume the 8-bit byte and make the fixed sized types the
>> natural types.
>>
>
> I suspect that is unlikely. Sizes are ingrained in peoples' minds,
> regardless of what the standard says. And 8-bit char, 16-bit short and
> 32-bit int is very convenient, and will continue to be very convenient
> even if processors start handling 128 bit sizes more efficiently. The
> number of uses of integers that are bigger than 32-bit is quiet small,
> and the cache miss ratio costs of 64-bit int would be high. Most
> integer usage bigger than 32-bit is in sizes of data in memory or file,
> and 64-bit is going to cover that for a long time. How often do you
> have need of an integer type that is bigger than 64-bit, but where
> 128-bit is really helpful? If you are moving data around, or doing
> cryptography, hashes, etc., you really want a lot bigger than 128-bit.
>
> Of course, any prediction of "this should be big enough for anyone" is
> going to be wrong :-)
It occurs to me that there are (at least) two characteristics that
make int special relative to the other built-in integer types.
One is that it "has the natural size suggested by the architecture of
the execution environment". This is vague enough to leave room for
most implementations to have 32-bit int on most 64-bit systems, even
though it's easy to argue that 64-bit int would be more "natural".
Another is that it's the type to which narrower types are promoted.
The assumption is that there are no arithmethic operations on integer
types narrower than int or unsigned int. But most modern 64-bit
systems have hardware support for 32-bit and 64-bit arithmetic.
A C implementation with 64-bit int would have no explicit support
for 32-bit arithmetic operations. Given 32-bit short and 64-bit
int, this:
short s = 42;
s++;
would logically convert s from short to int, add 1 to it, and convert
back to short. Of course a compiler could optimize this by using
a 32-bit add or increment instruction -- but only if it can prove
that the results will be the same in all cases where the behavior
is defined.
This special property of int (and unsigned int) causes some problems
for the fixed-width types. The behaviors of int16_t, int32_t, and
int64_t can be quite different in some cases depending on the width
of int. It doesn't matter (I think) for cases where all operands and
results are within range, but it can make a significant difference
for some corner cases.
I'd be happier if int and unsigned int *didn't* have this special
property, and for narrower and wide integer types to behave more
uniformly, but I don't know if it would be possible to change it
without breaking existing code.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-11-09 12:43 -0800 |
| Message-ID | <ln1rug4w71.fsf@kst-u.example.com> |
| In reply to | #147829 |
Richard Damon <Richard@Damon-Family.org> writes:
[...]
> The code also assume (perhaps acceptably) that RAND_MAX fits in 32 bits.
> One weakness in C is that there is no simple way to get a type twice as
> big as another type to make sure that a multiply doesn't overflow.
Supporting that in general would of course require infinitely
wide types.
A way to get a type twice as wide as a given type *if such a type
exists* could be a nice feature. One reasonable approach that
doesn't *quite* do that is to try [u]intmax_t and check whether
it's wide enough.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-11-09 17:16 -0500 |
| Message-ID | <rVGxF.13376$lN7.11488@fx10.iad> |
| In reply to | #147850 |
On 11/9/19 3:43 PM, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: > [...] >> The code also assume (perhaps acceptably) that RAND_MAX fits in 32 bits. >> One weakness in C is that there is no simple way to get a type twice as >> big as another type to make sure that a multiply doesn't overflow. > > Supporting that in general would of course require infinitely > wide types. > > A way to get a type twice as wide as a given type *if such a type > exists* could be a nice feature. One reasonable approach that > doesn't *quite* do that is to try [u]intmax_t and check whether > it's wide enough. > Thinking abit about how to do this, if we assume that we have a somewhat normal system where the base types (like int) would be suitable for the exact size types with power of two size (like int32_t), then by testing the various xxx_MAX constants in stdint.h, and detecting the number of bits in each by the value, and then check if the corresponding double sized exact sized type exists, you could build up a set of definitions for a type that is twice the size of a given type. This works because based on the assumptions, there are a limited number of possible sizes to check against. You should then be able to build a _Generic typedef, that given an expression, gives you a type that is twice that size, if it exists, otherwise probably give an error, though you could default to a max type.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-11-09 19:27 +0000 |
| Message-ID | <87bltk4zpr.fsf@bsb.me.uk> |
| In reply to | #147808 |
Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> int randIt( int low, int high )
>>> {
>>> return low + (int)((uint64_t)rand() * (unsigned)(high - low) / RAND_MAX);
>>> }
>
>> This function has numerous problems. Two signed operations can
>> overflow, and you will get entirely unexpected results if RAND_MAX is
>> INT_MAX on a machine with 64-bit int.
>
> Which signed operands?
There are only two operators with signed operands so it's not hard to
know what I meant.
> rand() is converted to uint64_t and thereby
> the whole inner term also. On today's machines INT_MAX - INT_MIN
> can be converted to an unsigned and will fit it it. Both terms
> multiplied are unlikely to owerflow because an int treated as an
> unsigned and an unsigned multiplied will fit into an uint64_t on
> any today's compiler. And the division by RAND_MAX gets the margins
> back to high - low; so I can safely add low.
> So there's nothing which will overflow here.
Both high - low can overflow and low + (int)(...) can overflow. What
you mean is that you don't mind about that, which is entirely up to you.
You've ignored, for some reason, the more serious point I raised: your
function can return high. It only does this when rand() returns
RAND_MAX. If the intent was to return a int in [low, high) then this a
bug because high is outside that range. If the intent was to return a
uniform int in [low, high] then that is a bug because high will occur no
more frequently than 1 in 32,767 times.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 05:55 +0100 |
| Message-ID | <qq857g$5c7$1@news.albasani.net> |
| In reply to | #147840 |
>> rand() is converted to uint64_t and thereby >> the whole inner term also. On today's machines INT_MAX - INT_MIN >> can be converted to an unsigned and will fit it it. Both terms >> multiplied are unlikely to owerflow because an int treated as an >> unsigned and an unsigned multiplied will fit into an uint64_t on >> any today's compiler. And the division by RAND_MAX gets the margins >> back to high - low; so I can safely add low. >> So there's nothing which will overflow here. > Both high - low can overflow and low + (int)(...) can overflow. What > you mean is that you don't mind about that, which is entirely up to you. high - low converted to an unsigned will actually never overflow on today's machines since all these use a 2's complement. > You've ignored, for some reason, the more serious point I raised: your > function can return high. ... That's what it should do. I wanted do make it compatible to what DFS wanted to implement.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-11-10 16:45 +0000 |
| Message-ID | <87bltj3cjk.fsf@bsb.me.uk> |
| In reply to | #147868 |
Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> rand() is converted to uint64_t and thereby
>>> the whole inner term also. On today's machines INT_MAX - INT_MIN
>>> can be converted to an unsigned and will fit it it. Both terms
>>> multiplied are unlikely to owerflow because an int treated as an
>>> unsigned and an unsigned multiplied will fit into an uint64_t on
>>> any today's compiler. And the division by RAND_MAX gets the margins
>>> back to high - low; so I can safely add low.
>>> So there's nothing which will overflow here.
>
>> Both high - low can overflow and low + (int)(...) can overflow. What
>> you mean is that you don't mind about that, which is entirely up to you.
>
> high - low converted to an unsigned will actually never overflow on
> today's machines since all these use a 2's complement.
high - low can overflow, as can the low + (int)(...) operation. You can
keep saying other things about conversions, but the fact remains that
both of those operations can overflow.
Compile and run with gcc's -fsanitize=undefined if you want to see it
actually happen.
>> You've ignored, for some reason, the more serious point I raised: your
>> function can return high. ...
>
> That's what it should do.
> I wanted do make it compatible to what DFS wanted to implement.
Then you got it wrong. high is returned only when rand() returns
RAND_MAX:
int randIt( int low, int high )
{
return low + (int)((uint64_t)rand() * (unsigned)(high - low) / RAND_MAX);
}
a sequence of calls to, say, randIt(0, 1) might return even millions
upon millions of zeros before you see a single one. That's not what
DFS wanted to implement.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 17:53 +0100 |
| Message-ID | <qq9f9e$cph$1@news.albasani.net> |
| In reply to | #147913 |
>> high - low converted to an unsigned will actually never overflow on >> today's machines since all these use a 2's complement. > high - low can overflow, as can the low + (int)(...) operation. No, it won't because the maximum added is the distance between high and low. >> That's what it should do. >> I wanted do make it compatible to what DFS wanted to implement. > Then you got it wrong. high is returned only when rand() returns > RAND_MAX: That's exactly what DFS wanted.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-11-11 00:56 +0000 |
| Message-ID | <87h83b1b9o.fsf@bsb.me.uk> |
| In reply to | #147914 |
Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> high - low converted to an unsigned will actually never overflow on
>>> today's machines since all these use a 2's complement.
>
>> high - low can overflow, as can the low + (int)(...) operation.
>
> No, it won't because the maximum added is the distance between high
> and low.
You need to learn how to analyse code. But if you don't like doing
that, run the code with -fsanitize=undefined and you can see both
operations overflow.
>>> That's what it should do.
>>> I wanted do make it compatible to what DFS wanted to implement.
>
>> Then you got it wrong. high is returned only when rand() returns
>> RAND_MAX:
>
> That's exactly what DFS wanted.
Nonsense. It is neither what DFS wanted nor what DFS's function does.
Called repeatedly as randInt(0, 1) it returns 0 and 1 with equal
probability as it should. Your re-write does not:
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
int bm_randInt( int low, int high )
{
return low + (int)((uint64_t)rand() * (unsigned)(high - low) / RAND_MAX);
}
int dfs_randInt(int low, int high) {
return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
}
long sum_rand_in_0_1(unsigned n, int (*rf)(int, int))
{
long t = 0;
while (n-- > 0) t += rf(0, 1);
return t;
}
int main(void)
{
printf("BM: %6ld\n", sum_rand_in_0_1(1000000, bm_randInt));
printf("DFS: %6ld\n", sum_rand_in_0_1(1000000, dfs_randInt));
}
$ ./rr
BM: 0
DFS: 500128
--
Ben.
[toc] | [prev] | [standalone]
Page 11 of 11 — ← Prev page 1 … 9 10 [11]
Back to top | Article view | comp.lang.c
csiph-web