Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #398106 > unrolled thread
| Started by | kalevi@kolttonen.fi (Kalevi Kolttonen) |
|---|---|
| First post | 2026-04-30 00:39 +0000 |
| Last post | 2026-05-11 18:23 +0200 |
| Articles | 20 on this page of 735 — 20 participants |
Back to article view | Back to comp.lang.c
Safety of casting from 'long' to 'int' kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-04-30 00:39 +0000
Re: Safety of casting from 'long' to 'int' wij <wyniijj5@gmail.com> - 2026-04-30 09:11 +0800
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-04-29 21:12 -0400
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-29 19:56 -0700
Re: Safety of casting from 'long' to 'int' wij <wyniijj5@gmail.com> - 2026-04-30 11:30 +0800
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-30 00:56 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-04-30 10:47 +0200
Re: Safety of casting from 'long' to 'int' wij <wyniijj5@gmail.com> - 2026-04-30 19:35 +0800
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-04-30 14:04 +0200
Re: Safety of casting from 'long' to 'int' wij <wyniijj5@gmail.com> - 2026-05-02 12:32 +0800
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-02 08:57 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-02 11:58 +0200
Re: Safety of casting from 'long' to 'int' wij <wyniijj5@gmail.com> - 2026-05-02 19:59 +0800
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-02 15:13 +0200
Re: Safety of casting from 'long' to 'int' wij <wyniijj5@gmail.com> - 2026-05-02 22:32 +0800
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-02 17:17 +0200
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-02 16:56 -0400
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-03 20:11 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-02 14:35 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-02 22:45 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-02 15:02 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-02 17:24 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-02 10:54 -0700
Re: Safety of casting from 'long' to 'int' wij <wyniijj5@gmail.com> - 2026-05-03 05:19 +0800
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-02 16:50 -0700
Re: Safety of casting from 'long' to 'int' wij <wyniijj5@gmail.com> - 2026-05-03 07:56 +0800
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-02 14:18 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-02 15:52 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-02 16:39 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-02 21:16 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-03 01:38 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-02 17:52 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-03 12:39 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-03 14:19 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-04 08:41 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-04 11:22 +0200
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-04 13:47 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-05 02:12 +0200
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-05 15:02 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-06 04:06 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 08:47 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-05 00:11 -0700
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-05 00:15 -0700
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-02 16:52 -0700
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-03 08:26 +0300
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-03 14:24 +0000
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-03 18:53 +0300
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-03 19:46 +0000
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-03 23:07 +0300
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-03 21:19 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-03 16:02 -0700
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-06 19:43 -0700
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-08 18:47 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-08 15:10 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-09 12:40 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 20:30 +0000
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-08 21:39 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-09 01:09 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-09 06:25 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-10 09:14 -0700
Re: Safety of casting from 'long' to 'int' kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-10 16:44 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 17:27 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-07 18:02 -0700
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-03 00:18 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-03 11:18 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-02 17:39 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-04 00:55 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-03 16:50 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-02 18:53 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-02 21:20 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-02 14:46 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-03 01:14 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-02 17:02 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-03 12:46 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-02 23:51 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-03 01:20 +0200
Re: Safety of casting from 'long' to 'int' wij <wyniijj5@gmail.com> - 2026-05-03 07:43 +0800
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-03 12:50 +0200
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-03 14:27 -0400
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-03 20:27 -0700
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-03 00:30 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-03 01:55 +0100
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-03 02:21 +0000
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-03 08:53 +0300
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-03 11:59 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-03 13:27 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-03 13:46 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-03 15:06 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-03 17:39 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-03 20:54 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-03 21:29 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-03 23:11 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-03 15:47 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-03 23:59 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-04 09:28 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-04 13:22 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-03 15:17 -0700
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-04 14:14 -0700
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-04 14:21 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-04 16:05 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-04 22:24 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-04 16:16 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-05 00:40 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-04 17:24 -0700
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-05 16:58 -0400
Re: Safety of casting from 'long' to 'int' kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-05 00:04 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-04 17:34 -0700
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-05 01:59 -0700
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-05 14:37 -0700
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-05 15:00 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-05 01:04 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-04 19:38 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 09:34 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-05 13:40 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 09:04 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-05 00:19 -0700
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-05 17:06 -0400
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-05 01:57 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-05 00:48 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-05 02:27 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-05 13:02 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-05 14:56 +0100
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-05 15:07 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-05 16:34 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-05 20:17 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-05 21:08 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-05 23:30 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-05 23:06 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-06 02:23 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-06 12:37 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-06 16:09 +0100
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-06 15:21 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-06 18:02 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-06 19:35 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-06 23:38 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-07 03:02 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-07 12:10 +0100
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-07 08:32 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-07 15:36 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-07 18:20 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-07 20:55 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-07 23:20 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 14:55 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-08 17:39 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-08 17:10 +0100
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-08 18:31 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 17:51 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-09 08:48 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-09 18:18 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-01 15:20 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:50 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-08 08:32 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-08 11:15 +0100
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-08 16:50 +0200
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-08 14:00 +0300
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-08 13:25 +0200
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-08 15:51 +0300
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-08 17:13 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 14:57 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-09 06:35 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-09 20:13 +0000
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-09 23:18 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-10 22:31 -0700
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-10 21:49 -0700
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-07 23:05 +0300
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-07 23:11 +0300
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 15:33 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-08 18:04 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-07 13:19 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 15:37 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-08 15:12 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-07 03:42 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-07 12:48 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-07 06:00 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-07 15:54 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-07 15:02 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-07 16:48 -0700
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-07 20:30 -0400
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-07 19:17 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-07 20:56 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-07 15:48 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-07 15:17 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-07 17:04 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-07 17:07 +0100
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-07 19:30 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-08 09:22 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-08 18:24 +0200
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-08 17:08 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-08 10:25 -0700
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-08 17:49 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-08 11:51 -0700
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-08 21:31 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-08 20:02 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-07 08:41 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-07 20:39 +0100
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-07 13:14 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-07 16:11 -0700
Re: Safety of casting from 'long' to 'int' Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-08 08:18 +0100
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-08 11:33 +0100
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-08 12:48 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-08 09:58 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-08 21:04 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-08 13:15 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-09 03:02 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-09 12:54 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-08 15:51 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-07 19:02 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-07 20:56 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-07 22:08 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-08 09:54 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-08 02:07 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-08 12:43 +0200
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-10 20:31 -0400
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-11 08:55 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 17:07 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 11:32 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 18:56 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-11 22:37 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 14:30 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-12 08:35 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-12 00:38 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-12 14:05 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-12 16:32 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-12 17:27 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-12 15:33 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-12 16:00 -0700
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-12 23:14 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-12 19:48 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-13 12:48 +0100
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-13 05:26 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 15:07 +0200
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-17 20:43 -0400
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 12:16 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-13 13:20 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 14:31 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-13 17:16 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 15:52 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-14 11:43 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-14 02:59 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-14 01:39 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-14 03:57 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-14 11:49 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-14 10:57 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-14 10:22 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-14 12:32 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-14 16:11 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-15 01:12 +0100
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-15 02:30 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-15 02:38 +0200
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-18 19:48 -0400
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-19 01:12 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-18 19:22 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-19 11:31 +0100
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-19 12:21 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-19 14:15 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-19 14:14 -0700
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-22 21:58 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-22 23:23 -0700
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-23 00:09 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-23 04:13 -0700
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-24 04:37 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-27 17:57 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-19 14:12 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-20 04:20 +0200
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-19 19:00 -0400
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-19 16:56 -0700
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-19 11:31 -0400
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-14 08:37 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-14 17:00 +0100
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-14 09:44 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-14 18:57 +0100
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 18:25 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-14 18:51 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-14 19:19 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-14 20:50 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-15 02:52 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-15 02:07 +0100
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-15 03:39 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-14 19:04 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-15 10:27 +0200
Re: Safety of casting from 'long' to 'int' tTh <tth@none.invalid> - 2026-05-15 12:25 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-14 16:40 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-15 01:31 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-14 17:52 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-15 10:32 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-15 02:35 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-15 11:38 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-15 11:35 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-15 13:05 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-15 13:58 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-15 14:54 +0100
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-15 15:00 +0100
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-15 16:01 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-15 12:23 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-15 12:54 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-15 21:39 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-15 14:14 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-16 00:44 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-16 00:36 +0100
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-15 02:46 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 12:34 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-12 13:36 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-12 13:10 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-12 16:46 +0200
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-12 15:19 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-12 19:02 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 14:33 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-13 11:44 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 21:22 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-12 15:57 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-12 19:07 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-12 18:09 +0000
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-12 18:45 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-12 21:24 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 13:14 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 13:12 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 14:40 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-14 08:13 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 12:41 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-12 18:36 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 14:47 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-08 18:54 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 22:43 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-08 16:15 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-09 02:32 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-09 01:36 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-10 07:23 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 12:37 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-11 08:06 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 10:56 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-13 11:32 -0700
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-08 20:04 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-09 20:14 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-09 15:19 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 16:20 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-08 09:23 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-08 19:58 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-13 10:38 -0700
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-07 07:46 -0400
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-08 21:02 +0000
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-08 21:47 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-08 22:58 +0100
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-08 16:56 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-09 07:37 +0200
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-09 17:39 +0000
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-09 00:05 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-09 00:37 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-09 01:57 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-09 11:56 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-09 15:18 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-09 17:16 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-09 18:38 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-09 19:20 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 04:15 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-10 11:29 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-10 03:25 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-10 12:29 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 12:39 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-10 14:51 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 16:28 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-13 04:27 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 15:14 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 15:55 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-10 15:03 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-10 14:38 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 16:37 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-10 18:00 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-10 18:53 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-10 16:38 -0700
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-10 14:58 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-10 16:47 +0100
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-10 16:22 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-10 17:57 +0100
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-10 22:46 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 17:03 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 11:53 +0100
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-11 18:11 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 11:05 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 19:24 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 19:04 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 20:52 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 20:04 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-11 22:45 +0200
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-11 13:46 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-10 18:55 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-10 12:53 -0700
Re: Safety of casting from 'long' to 'int' kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-10 20:15 +0000
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-10 18:52 -0400
Re: Safety of casting from 'long' to 'int' kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-10 23:19 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-10 18:37 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-11 09:29 +0200
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-11 00:26 +0000
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-10 20:36 -0400
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-10 18:19 -0700
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-11 14:45 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-11 08:10 -0700
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-11 15:58 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 18:21 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 11:46 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 19:34 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 14:23 -0700
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-11 23:57 +0300
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-12 20:47 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 11:02 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 15:20 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-14 03:14 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-14 03:50 +0200
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-13 13:11 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 11:25 -0700
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-13 04:07 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 13:35 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-13 13:54 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-13 11:00 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-13 11:39 -0700
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-13 15:42 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-14 03:46 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-14 06:07 -0700
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-14 00:38 -0700
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-14 00:39 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-14 03:39 +0200
Re: Safety of casting from 'long' to 'int' tTh <tth@none.invalid> - 2026-05-14 07:47 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-14 09:54 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-14 06:25 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-14 17:49 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-14 16:33 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-15 03:31 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-15 01:56 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-14 19:12 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-15 02:20 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-15 13:44 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 14:43 -0700
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-14 15:26 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 11:22 -0700
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-11 19:20 +0000
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-11 13:51 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-09 15:32 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 01:35 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-10 06:19 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 12:52 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-10 11:49 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 12:59 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-10 17:10 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 01:21 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-10 17:42 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 02:33 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-10 18:43 -0700
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-10 20:30 -0400
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-11 15:17 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-11 18:12 +0200
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-11 23:48 +0300
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-12 10:42 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-12 07:12 -0700
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-12 22:21 +0300
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-12 19:19 -0700
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-13 11:17 -0400
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-09 05:50 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-09 08:39 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-09 13:10 +0100
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-09 18:04 +0000
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-10 14:49 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-10 00:25 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-10 00:16 +0100
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-10 06:39 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-10 13:22 +0100
Alternatives to C (was Re: Safety of casting from 'long' to 'int') cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 13:05 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Bart <bc@freeuk.com> - 2026-05-12 02:28 +0100
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 18:37 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Bart <bc@freeuk.com> - 2026-05-12 22:32 +0100
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') John Ames <commodorejohn@gmail.com> - 2026-05-12 15:28 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 02:49 +0200
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-12 15:35 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 03:26 +0200
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Bart <bc@freeuk.com> - 2026-05-13 12:32 +0100
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 14:42 +0200
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-13 12:28 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-14 04:30 +0200
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-13 19:58 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-14 09:40 +0200
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Bart <bc@freeuk.com> - 2026-05-14 12:03 +0100
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-14 16:51 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 14:57 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-13 12:35 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 20:18 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') scott@slp53.sl.home (Scott Lurndal) - 2026-05-13 21:46 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-13 15:45 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-14 10:53 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-14 16:59 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') scott@slp53.sl.home (Scott Lurndal) - 2026-05-15 15:45 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-15 20:17 +0200
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-15 12:47 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-15 13:15 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') scott@slp53.sl.home (Scott Lurndal) - 2026-05-15 22:16 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Bart <bc@freeuk.com> - 2026-05-15 21:52 +0100
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-14 04:48 +0200
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') David Brown <david.brown@hesbynett.no> - 2026-05-14 12:08 +0200
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-14 05:15 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-15 03:51 +0200
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') scott@slp53.sl.home (Scott Lurndal) - 2026-05-13 15:12 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-14 04:56 +0200
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') scott@slp53.sl.home (Scott Lurndal) - 2026-05-14 15:19 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-14 09:55 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') scott@slp53.sl.home (Scott Lurndal) - 2026-05-14 17:32 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-13 16:33 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Adam Sampson <ats@offog.org> - 2026-05-15 11:55 +0100
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-15 11:27 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Bart <bc@freeuk.com> - 2026-05-15 12:43 +0100
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') scott@slp53.sl.home (Scott Lurndal) - 2026-05-12 23:21 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-13 02:53 +0200
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') scott@slp53.sl.home (Scott Lurndal) - 2026-05-13 14:15 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-13 12:30 -0700
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 20:20 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-12 02:40 +0000
Re: Alternatives to C (was Re: Safety of casting from 'long' to 'int') Bart <bc@freeuk.com> - 2026-05-12 15:11 +0100
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-10 15:18 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 01:17 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-09 15:47 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-09 23:33 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-10 00:45 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-09 17:33 -0700
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-10 03:46 +0300
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-09 17:54 -0700
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-10 15:46 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-10 13:21 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-10 02:26 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-09 19:01 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-10 12:06 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-10 16:11 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 00:58 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-10 17:31 -0700
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-11 01:44 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 03:09 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 12:15 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 15:19 +0000
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-11 19:06 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 21:29 +0100
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-19 10:12 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-19 10:40 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-11 18:32 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-12 03:44 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-11 20:53 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-12 14:27 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-13 11:37 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 20:28 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 02:18 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-10 19:48 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 12:39 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 11:12 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 19:30 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 11:34 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 19:42 +0000
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-10 21:21 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-11 07:43 +0200
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-11 13:57 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-11 09:46 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-10 07:09 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-10 07:00 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-10 12:44 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-10 16:45 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-11 07:58 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 13:55 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-10 14:34 +0000
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-10 15:42 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-10 13:23 -0700
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-10 21:28 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 12:53 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 13:54 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 16:48 +0100
Re: Safety of casting from 'long' to 'int' tTh <tth@none.invalid> - 2026-05-11 18:26 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 11:20 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 19:38 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 18:50 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 11:58 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 18:44 +0000
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-11 19:28 +0000
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 19:41 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 14:16 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 23:05 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-11 16:13 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 21:03 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-11 20:08 +0000
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-11 15:25 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-11 17:03 +0100
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-09 21:25 -0400
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-09 07:31 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-06 21:45 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-07 09:30 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-07 03:44 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-07 18:03 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-07 14:45 +0000
Re: Safety of casting from 'long' to 'int' tTh <tth@none.invalid> - 2026-05-05 22:27 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-05 16:09 -0700
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-05 16:52 -0400
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-03 19:26 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-03 20:33 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-03 15:05 -0700
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-04 15:09 -0400
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-03 14:58 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-04 00:34 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-03 17:07 -0700
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-04 01:23 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-04 14:38 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-04 17:41 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-05 02:59 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-04 19:35 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-05 14:54 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 16:03 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-06 05:18 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-05 09:53 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-06 05:22 +0200
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-08 07:40 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 09:41 +0200
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-05 00:44 +0000
Re: Safety of casting from 'long' to 'int' tTh <tth@none.invalid> - 2026-05-04 05:47 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-04 08:59 +0200
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-04 14:31 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-04 14:40 -0700
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-04 14:42 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 10:00 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-04 10:07 +0200
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-04 15:05 -0400
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-04 21:04 +0100
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-04 20:52 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-04 21:56 +0100
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-05 01:12 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 10:16 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-05 11:11 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 11:25 +0200
Re: Safety of casting from 'long' to 'int' Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-05 11:12 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 14:12 +0200
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-05 16:43 -0400
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-05 11:41 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 14:31 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-05 14:26 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 16:36 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-05 17:21 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 19:19 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-05 15:25 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-06 09:03 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-05 16:00 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-06 09:20 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-05 15:21 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-06 12:20 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-06 03:36 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-06 12:49 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-06 12:00 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-06 14:34 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-06 12:23 -0700
[meta] Optimizing posting and communication (was: something about UB) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-06 22:15 +0200
Re: [meta] Optimizing posting and communication (was: something about UB) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-06 22:42 +0000
Re: [meta] Optimizing posting and communication Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-06 17:01 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-06 12:32 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-06 14:52 +0200
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-05 13:27 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 16:45 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-05 16:22 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-07 01:39 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-06 21:41 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 18:26 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-08 15:41 -0700
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-06 23:22 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 19:06 +0000
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-08 13:22 -0700
Re: Safety of casting from 'long' to 'int' "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-08 13:27 -0700
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-12 22:31 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 15:47 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-13 11:59 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 20:45 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-13 15:28 -0700
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-13 15:33 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-13 23:56 +0000
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-07 10:33 +0200
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-07 18:08 -0400
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 16:13 +0000
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-08 16:42 +0000
Re: Safety of casting from 'long' to 'int' Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-05-08 16:57 +0000
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-08 17:51 -0400
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 23:03 +0000
Re: Safety of casting from 'long' to 'int' scott@slp53.sl.home (Scott Lurndal) - 2026-05-08 17:01 +0000
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-09 08:37 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-09 22:15 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-09 16:24 -0700
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-05 06:41 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-05 18:06 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-05 16:26 -0700
Re: Safety of casting from 'long' to 'int' Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-08 15:33 -0700
Re: Safety of casting from 'long' to 'int' cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-08 23:34 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-04 15:05 -0700
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-04 18:54 -0400
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-04 16:21 -0700
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-05 16:48 -0400
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-05 00:39 +0000
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-05 03:23 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-03 18:03 +0100
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-03 20:24 +0300
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-03 19:15 +0100
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-03 20:59 +0200
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-03 20:38 +0100
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-04 09:07 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-04 10:23 +0200
Re: Safety of casting from 'long' to 'int' Michael S <already5chosen@yahoo.com> - 2026-05-04 10:45 +0300
Re: Safety of casting from 'long' to 'int' antispam@fricas.org (Waldek Hebisch) - 2026-05-03 20:54 +0000
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-03 23:27 +0100
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-04 09:18 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-04 09:03 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-04 01:07 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-04 10:37 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-04 02:37 -0700
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-04 13:44 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-04 10:58 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-04 11:34 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-04 12:12 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-04 13:46 +0200
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-04 02:42 -0700
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-04 12:17 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-04 13:52 +0200
Re: Safety of casting from 'long' to 'int' James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-04 14:32 -0400
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-04 09:48 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-04 11:12 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-04 11:39 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-04 12:08 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-04 14:00 +0200
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-04 23:54 +0200
Re: Safety of casting from 'long' to 'int' David Brown <david.brown@hesbynett.no> - 2026-05-05 10:22 +0200
Re: Safety of casting from 'long' to 'int' dave_thompson_2@comcast.net - 2026-06-06 17:49 -0400
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-02 14:57 -0700
Re: Safety of casting from 'long' to 'int' Bart <bc@freeuk.com> - 2026-05-03 00:14 +0100
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-02 16:55 -0700
Re: Safety of casting from 'long' to 'int' wij <wyniijj5@gmail.com> - 2026-05-03 08:04 +0800
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-02 17:16 -0700
Re: Safety of casting from 'long' to 'int' wij <wyniijj5@gmail.com> - 2026-05-03 08:29 +0800
Re: Safety of casting from 'long' to 'int' Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-02 16:51 +0200
Re: Safety of casting from 'long' to 'int' Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-10 18:27 +0200
Re: Safety of casting from 'long' to 'int' kalevi@kolttonen.fi (Kalevi Kolttonen) - 2026-05-10 16:58 +0000
Re: Safety of casting from 'long' to 'int' Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-10 17:04 -0700
Re: Safety of casting from 'long' to 'int' Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-11 18:23 +0200
Page 17 of 37 — ← Prev page 1 … 15 16 [17] 18 19 … 37 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-13 14:47 +0000 |
| Message-ID | <10u22ur$ev2$4@reader1.panix.com> |
| In reply to | #398837 |
In article <867bp8m6ok.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >James Kuyper <jameskuyper@alumni.caltech.edu> writes: > >> On 2026-05-08 06:43, David Brown wrote: >> ... >> >>> Yes, I have heard that argument before. I am unconvinced that the >>> "value preserving" choice actually has any real advantages. I also >>> think it is a misnomer - it implies that "unsigned preserving" would >>> not preserve values, which is wrong. >> >> Unsigned-preserving rules would convert a signed value which might be >> negative to unsigned type more frequently than the value preserving >> rules do. > >This statement is wrong. The truth of Kuyper's statement depends on how one interprets its meaning. >An "unsigned preserving" promotion rule >converts a signed value to a signed value and an unsigned value to >an unsigned value. The value being converted stays the same in both >cases. Both an "unsigned preserving" promotion and a so-called >"value preserving" promotion preserve the value of the operand being >promoted (and converted). Unsigned-preserving rules mean that unsigned types are prompted to unsigned types. But that also means that signed types in expressions involving those promoted values are converted to unsigned types (including negative values of the signed type). I took Kuyper's statement to refer this promotion. For example, given: unsigned char a = 8; signed short b = -5; Now consider the type of `b` after promotion in the expression, `a * b`. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-08 18:54 +0200 |
| Message-ID | <10tl4fi$1l93l$12@dont-email.me> |
| In reply to | #398480 |
On 2026-05-08 09:54, David Brown wrote: > On 08/05/2026 00:08, Dan Cross wrote: >> [...] > > I like the way you put that. Sometimes people have a tendency to put > too much reverence on particular texts - such as imagining that K&R says > all that needs to be said about C, and treating any modern tool, text, > standard or program that diverges from it as some kind of heresy, or > "not following the spirit of C". Hmm.. - I don't recall to have seen anyone admire to that version. (Myself I fairly quickly, on first occasion, switched to non-K&R function signatures, localized declarations, use of '//' comments, the 'void' type, etc.) > Languages evolve - tools evolve, > programs evolve, standards evolve, requirements evolve. K&R was a > milestone in the history of programming languages, and a model for > technical writing in its field, but C today is not C of fifty years ago. Well, yes. They evolve. And how they evolve lets you draw conclusions not only of what new things they support but also what was amiss with design of earlier releases or the language per se. I've not followed the "C" standard evolution; since I was engaged with C++ that was more of a concern. But also there, its later evolution went stray (IMO). >> [...] > > It is unfortunate that this situation may be UB. I personally think > "unsigned short" should promote to "unsigned int", not "int" - > promotions should be signedness preserving. I don't like the "promote > to int" at all. [...] That's also my opinion and expectation. (But I've to admit I wasn't involved in disputes about the pros/cons so take that just as IMHO.) > > But I am not sure I agree that such cases are "easy to stumble into". > [...] > Certainly, however, the fact that this expression could contain UB would > surprise many C programmers. Yes. > [ K&R ] >> >> I just picked my copy up off the shelf. The pages are yellowed >> and the corners heavily dogeared; but flipping through it is >> like seeing an old friend. Then I put it back on the shelf: you >> can never go home again. > > You make that sound so sad! > (My copy is in a box in the loft somewhere. I guess it is really one of > these books that should always be on the bookshelf, even if I never look > at it again.) During the past decades I've used it _only_ to look up the operator precedence table. (One of those badly-designed constituents.) (Only recently when discussing CLC stuff I looked up older details.) Janis
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-08 22:43 +0000 |
| Message-ID | <10tloub$32n$1@reader1.panix.com> |
| In reply to | #398480 |
In article <10tk4sg$2l19a$2@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 08/05/2026 00:08, Dan Cross wrote:
>> K&R is a wonderful book for its exposition: well-written,
>> concise, and the prose is beautiful. Kernighan is an amazing
>> writer, and Ritchie was well-known for his patience and clear
>> explainations.
>>
>> However, it is a product of its time. It dates from a simpler
>> era, when programmers were expected to use books like it is a
>> starting point, and subsequently gain mastery either through
>> careful study of the standard, or extensive practice. (I'm
>> referring specifically to K&R2, of course, since the first
>> edition predated the first version of the standard by a decade.)
>> Machines were smaller and simpler, then, and so were compilers.
>>
>> I am sad to say that I don't think it has aged particularly well.
>
>I like the way you put that. Sometimes people have a tendency to put
>too much reverence on particular texts - such as imagining that K&R says
>all that needs to be said about C, and treating any modern tool, text,
>standard or program that diverges from it as some kind of heresy, or
>"not following the spirit of C". Languages evolve - tools evolve,
>programs evolve, standards evolve, requirements evolve. K&R was a
>milestone in the history of programming languages, and a model for
>technical writing in its field, but C today is not C of fifty years ago.
Thank you. Yes, I pretty much agree.
>It is unfortunate that this situation may be UB. I personally think
>"unsigned short" should promote to "unsigned int", not "int" -
>promotions should be signedness preserving. I don't like the "promote
>to int" at all. But opinions don't change the standards, and I suppose
>there are historical reasons for the rules that were made here.
>
>But I am not sure I agree that such cases are "easy to stumble into".
>How often would code like that be written, where overflowing the
>uint16_t would be correct behaviour in the code on a 16-bit int system?
>It is certainly possible, but it is perhaps more likely that cases of
>overflow in the 16-bit system were also bugs in the code - moving the
>code to 32-bit systems could give different undesirable effects from the
>bug. It could also happen to remove the effects of the bug by holding
>results in 32-bit registers and leading to correct results in later
>calculations - UB can work either way.
Sure. This was a bit of a contrived example, but you ask a good
question: how often might one want write code like that?
In short, I don't know, but I can think of any number of hash
functions, checksums, etc, that may be implemented using 16-bit
arithmetic, and I can well see programmers wanting to take
advantage of the modular semantics afforded by using unsigned
types to do so. Every day? Probably not. But often enough.
One of the things I had to really internalize as an OS person is
that the universe of useful existing software is large. It
doesn't matter if I create the most beautiful abstractions for
them that are infinitely superior to whatever swill their code
is using now. If they don't get to run their program (or worse,
they have to make a bunch of invasive changes for no discernable
benefit from their perspective) because I know better about how
things ought to be done, they're not going to use whatever
system I'm working on unless they're forced. But even then they
will resent it and move to something else the first chance they
get (lookin' at you, DEC, Microsoft, IBM, and any number of
commercial Unix vendors).
Whatever _I_ think of how the interfaces they chose to use is
immaterial, making it difficult for them wins me no friends.
This is one of the smart things Torvalds did with Linux: "don't
break userspace" (unless there's a really, really good reason)
probably did a lot to help make Linux popular.
Anyway, I think this is similar. It doesn't matter what anyone
thinks of whether one ought to prevent all overflow; the fact
is that the language supports it for unsigned integers (though
with some surprising semantics for types of lower rank than
`int`) simply is what it is. And if someone has a program that
avails of those semantics, and that program is important to them
for whatever reason, then there's little choice but to hold
one's nose. I know you know this, of course, but I think it's
worth repeating every now and then.
>Certainly, however, the fact that this expression could contain UB would
>surprise many C programmers.
Yes. Btw, the fix is almost trivial:
```
uint16_t
mul(uint16_t a, uint16_t b)
{
unsigned int aa = a, bb = b;
return aa * bb;
}
```
But if a programmer is not already very familiar with the
language, it may look very odd.
>> I don't think that this what the authors originally intended
>> (in fact, I'm quite certain it is not, based on conversations
>> I've had with them in the past; they very much wanted the
>> original semantics for integer promotion and did not like those
>> chosen by the ANSI committee).
>>
>> K&R has not been updated in almost 40 years, and 40 years ago,
>> it reflected a very different language, and moreover, reflected
>> the spirit intended by the original authors.. But, regardless of
>> the original intent, that is not the language we have _today_.
>>
>> I just picked my copy up off the shelf. The pages are yellowed
>> and the corners heavily dogeared; but flipping through it is
>> like seeing an old friend. Then I put it back on the shelf: you
>> can never go home again.
>
>You make that sound so sad!
It is bittersweet. I have fond memories of times spent with
that copy of that book. I learned a lot from it, and it had an
outsized role in shaping my career and my development as an
engineer.
I met Dennis Ritchie several times. I think he would be pleased
and satisfied to know how many people look at K&R with fondness
and appreciation, but perhaps moreso how many have outgrown it,
as well. I worked in the same office as Kernighan for a while,
and occasionally ate breakfast with him. I managed to overcome
my embarassment enough one morning and asked him to sign my copy
of K&R1, and I could tell he very much appreciated it; I'm
certain he feels much the way I just described. (Sadly, I never
asked Dennis to sign my copy before he passed away.)
>(My copy is in a box in the loft somewhere. I guess it is really one of
>these books that should always be on the bookshelf, even if I never look
>at it again.)
Absolutely.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-08 16:15 -0700 |
| Message-ID | <10tlqqi$390gg$1@kst.eternal-september.org> |
| In reply to | #398547 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <10tk4sg$2l19a$2@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
[...]
>>Certainly, however, the fact that this expression could contain UB would
>>surprise many C programmers.
>
> Yes. Btw, the fix is almost trivial:
>
> ```
> uint16_t
> mul(uint16_t a, uint16_t b)
> {
> unsigned int aa = a, bb = b;
> return aa * bb;
> }
> ```
Or, more tersely:
```
uint16_t
mul(uint16_t a, uint16_t b)
{
return (unsigned)aa * (unsigned)bb;
}
```
This is a relatively easy case since we know that uint16_t is no
wider than int. But uint32_t could be either wider or narrower than
int, or the same width. Casting to unsigned could lose information;
not casting could result in UB on overflow. I think casting to
unsigned long (a predefined type wider than int and guaranteed to
be at least as wide as uint32_t) would do the trick, perhaps with
some unnecessary processing if unsigned long is 64 bits.
[...]
I do tend to think that "unsigned preserving" rules would have
been better than the "value preserving" rules the Committee chose,
but then we'd have 37 years of experience to tell us why value
preserving would have been better.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-09 02:32 +0200 |
| Message-ID | <10tlvaa$1l93l$16@dont-email.me> |
| In reply to | #398547 |
On 2026-05-09 00:43, Dan Cross wrote: >> [...] > > Sure. This was a bit of a contrived example, but you ask a good > question: how often might one want write code like that? > > In short, I don't know, but I can think of any number of hash > functions, checksums, etc, that may be implemented using 16-bit > arithmetic, and I can well see programmers wanting to take > advantage of the modular semantics afforded by using unsigned > types to do so. Every day? Probably not. But often enough. I mentioned it before but it may have got lost in the lots text typically exchanged here; for hash functions a modulus based on powers of two has *bad* _distribution properties_, so it's not a sensible example or plausible rationale to vindicate modular arithmetic for the few special cases (m=8, 16, 32, 64, etc.). Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-09 01:36 +0000 |
| Message-ID | <10tm330$8d2$1@reader1.panix.com> |
| In reply to | #398561 |
In article <10tlvaa$1l93l$16@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>On 2026-05-09 00:43, Dan Cross wrote:
>>> [...]
>>
>> Sure. This was a bit of a contrived example, but you ask a good
>> question: how often might one want write code like that?
>>
>> In short, I don't know, but I can think of any number of hash
>> functions, checksums, etc, that may be implemented using 16-bit
>> arithmetic, and I can well see programmers wanting to take
>> advantage of the modular semantics afforded by using unsigned
>> types to do so. Every day? Probably not. But often enough.
>
>I mentioned it before but it may have got lost in the lots text
>typically exchanged here; for hash functions a modulus based on
>powers of two has *bad* _distribution properties_, so it's not
>a sensible example or plausible rationale to vindicate modular
>arithmetic for the few special cases (m=8, 16, 32, 64, etc.).
Maybe, maybe not, depending on the exact hashing function and
the values it uses. Since K&R2 came up elsewhere, consider the
hash function the presented on pp 128-129:
/* hash: form hash value for string s */
unsigned hash(char *s)
{
unsigned hashval;
for (hashval = 0; *s != '\0'; s++)
hashval = *s + 31 * hashval;
return hashval % HASHSIZE;
}
I wrote about collisions in this function a long time ago:
https://pub.gajendra.net/2012/09/notes_on_collisions_in_a_common_string_hashing_function
In this case, the important characteristic with respect to
distribution is that the multiplier is relatively prime to the
modulous. Their choice of multipler is 31, which is a prime
number, and thus by definition co-prime to all positive moduli
They happen to chose 101 (also prime) for `HASHSIZE` but
assuming reasonably random input, the pathological behavior you
are referring to would be avoided even if the modulus were (say)
128.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-10 07:23 +0200 |
| Message-ID | <10tp4o8$1l93k$7@dont-email.me> |
| In reply to | #398565 |
On 2026-05-09 03:36, Dan Cross wrote:
> In article <10tlvaa$1l93l$16@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> On 2026-05-09 00:43, Dan Cross wrote:
>>>> [...]
>>>
>>> Sure. This was a bit of a contrived example, but you ask a good
>>> question: how often might one want write code like that?
>>>
>>> In short, I don't know, but I can think of any number of hash
>>> functions, checksums, etc, that may be implemented using 16-bit
>>> arithmetic, and I can well see programmers wanting to take
>>> advantage of the modular semantics afforded by using unsigned
>>> types to do so. Every day? Probably not. But often enough.
>>
>> I mentioned it before but it may have got lost in the lots text
>> typically exchanged here; for hash functions a modulus based on
>> powers of two has *bad* _distribution properties_, so it's not
>> a sensible example or plausible rationale to vindicate modular
>> arithmetic for the few special cases (m=8, 16, 32, 64, etc.).
>
> Maybe, maybe not, depending on the exact hashing function and
> the values it uses. Since K&R2 came up elsewhere, consider the
> hash function the presented on pp 128-129:
(I don't have that version available so the reference doesn't
help me much.)
>
> /* hash: form hash value for string s */
> unsigned hash(char *s)
> {
> unsigned hashval;
>
> for (hashval = 0; *s != '\0'; s++)
> hashval = *s + 31 * hashval;
>
> return hashval % HASHSIZE;
> }
The item in question would be 'HASHSIZE'. I cannot infer from
that code whether a prime, a CPU-wordsize, or something else
has been defined for that entity.
Seeking in my older K&R translation I found a similar (but not
the same, a more primitive) function that has a HASHSIZE of 100
defined. (Clearly not a good choice.)
>
> I wrote about collisions in this function a long time ago:
> https://pub.gajendra.net/2012/09/notes_on_collisions_in_a_common_string_hashing_function
>
> In this case, the important characteristic with respect to
> distribution is that the multiplier is relatively prime to the
> modulous. Their choice of multipler is 31, which is a prime
> number, and thus by definition co-prime to all positive moduli
>
> They happen to chose 101 (also prime) for `HASHSIZE` but
> assuming reasonably random input, the pathological behavior you
> are referring to would be avoided even if the modulus were (say)
> 128.
Since you know what you're doing in your context all is fine. :-)
Janis
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-10 12:37 +0000 |
| Message-ID | <10tpu6s$cd$1@reader1.panix.com> |
| In reply to | #398627 |
In article <10tp4o8$1l93k$7@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>On 2026-05-09 03:36, Dan Cross wrote:
>> In article <10tlvaa$1l93l$16@dont-email.me>,
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>> On 2026-05-09 00:43, Dan Cross wrote:
>>>>> [...]
>>>>
>>>> Sure. This was a bit of a contrived example, but you ask a good
>>>> question: how often might one want write code like that?
>>>>
>>>> In short, I don't know, but I can think of any number of hash
>>>> functions, checksums, etc, that may be implemented using 16-bit
>>>> arithmetic, and I can well see programmers wanting to take
>>>> advantage of the modular semantics afforded by using unsigned
>>>> types to do so. Every day? Probably not. But often enough.
>>>
>>> I mentioned it before but it may have got lost in the lots text
>>> typically exchanged here; for hash functions a modulus based on
>>> powers of two has *bad* _distribution properties_, so it's not
>>> a sensible example or plausible rationale to vindicate modular
>>> arithmetic for the few special cases (m=8, 16, 32, 64, etc.).
>>
>> Maybe, maybe not, depending on the exact hashing function and
>> the values it uses. Since K&R2 came up elsewhere, consider the
>> hash function the presented on pp 128-129:
>
>(I don't have that version available so the reference doesn't
>help me much.)
I mean, I gave you the function; you quoted it. :-)
>> /* hash: form hash value for string s */
>> unsigned hash(char *s)
>> {
>> unsigned hashval;
>>
>> for (hashval = 0; *s != '\0'; s++)
>> hashval = *s + 31 * hashval;
>>
>> return hashval % HASHSIZE;
>> }
>
>The item in question would be 'HASHSIZE'. I cannot infer from
>that code whether a prime, a CPU-wordsize, or something else
>has been defined for that entity.
I told you what it was (101). It was in the text you quoted..
>Seeking in my older K&R translation I found a similar (but not
>the same, a more primitive) function that has a HASHSIZE of 100
>defined. (Clearly not a good choice.)
Actually, it's fine; that's the point: as long as the multiplier
is coprime to the modulus, distribution is ok for sufficiently
random data.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-11 08:06 +0200 |
| Message-ID | <10trrkq$1l93k$9@dont-email.me> |
| In reply to | #398638 |
On 2026-05-10 14:37, Dan Cross wrote: > In article <10tp4o8$1l93k$7@dont-email.me>, > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >> On 2026-05-09 03:36, Dan Cross wrote: >>> >>> Maybe, maybe not, depending on the exact hashing function and >>> the values it uses. Since K&R2 came up elsewhere, consider the >>> hash function the presented on pp 128-129: >> >> (I don't have that version available so the reference doesn't >> help me much.) > > I mean, I gave you the function; you quoted it. :-) Erm, no. I referred to something from an earlier K&R release. The algorithm was different from the one you posted, and the modulus was also different; using 100 (2*2*5*5) vs. 101 (this is a prime) makes a difference. - It seems the newer K&R that you were referring to used a better modulus than the old book. Never mind. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-11 10:56 +0000 |
| Message-ID | <10tsckr$46h$1@reader1.panix.com> |
| In reply to | #398708 |
In article <10trrkq$1l93k$9@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>On 2026-05-10 14:37, Dan Cross wrote:
>> In article <10tp4o8$1l93k$7@dont-email.me>,
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>> On 2026-05-09 03:36, Dan Cross wrote:
>>>>
>>>> Maybe, maybe not, depending on the exact hashing function and
>>>> the values it uses. Since K&R2 came up elsewhere, consider the
>>>> hash function the presented on pp 128-129:
>>>
>>> (I don't have that version available so the reference doesn't
>>> help me much.)
>>
>> I mean, I gave you the function; you quoted it. :-)
>
>Erm, no. I referred to something from an earlier K&R release.
Ah, ok.
>The algorithm was different from the one you posted,
The version I posted was from K&R2; the version from K&R 1st
Edition is as follows:
```
#define HASHSIZE 100
hash(s)
char *s;
{
int hashval;
for (hashval = 0; *s != '\0'; )
hashval += *s++;
return (hashval % HASHSIZE);
}
```
(Note that this is historical C. I have reproduced it verbatim,
modulo mistakes in transcription)
>and the
>modulus was also different; using 100 (2*2*5*5) vs. 101 (this
>is a prime) makes a difference. - It seems the newer K&R that
>you were referring to used a better modulus than the old book.
>Never mind.
No, the newer version uses a _multiplier_. For reference, the
newer algorithm is:
```
#define HASHSIZE 101
unsigned hash(char *c)
{
unsigned hashval = 0
for (hashval = 0; *s != '\0'; s++)
hashval = *s + 31 * hashval;
return hashval % HASHSIZE;
}
```
Note the `31 * hashval` term in the loop. 31 is a prime number,
and thus coprime to the hash size (which also happens to be
prime, but that's not _as_ important; see the analysis I linked
to earlier to understand the math).
That is the essential difference between the two.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-13 11:32 -0700 |
| Message-ID | <86qznfjh2i.fsf@linuxsc.com> |
| In reply to | #398561 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 2026-05-09 00:43, Dan Cross wrote: > >>> [...] >> >> Sure. This was a bit of a contrived example, but you ask a good >> question: how often might one want write code like that? >> >> In short, I don't know, but I can think of any number of hash >> functions, checksums, etc, that may be implemented using 16-bit >> arithmetic, and I can well see programmers wanting to take >> advantage of the modular semantics afforded by using unsigned >> types to do so. Every day? Probably not. But often enough. > > I mentioned it before but it may have got lost in the lots text > typically exchanged here; for hash functions a modulus based on > powers of two has *bad* _distribution properties_, so it's not > a sensible example or plausible rationale to vindicate modular > arithmetic for the few special cases (m=8, 16, 32, 64, etc.). To me this sounds like folklore. A well-designed hash function (and it isn't hard to write one or find one) will have good distribution properties with any modulus. In many cases there are good reasons to prefer a power-of-two modulus. So I think the right takeaway here is make sure you have a good hash function, and don't settle for some ad hoc thing just thrown together.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-08 20:04 -0700 |
| Message-ID | <86qznls2p8.fsf@linuxsc.com> |
| In reply to | #398547 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
[concerning UB when multiplying 16-bit unsigneds]
> Yes. Btw, the fix is almost trivial:
>
> ```
> uint16_t
> mul(uint16_t a, uint16_t b)
> {
> unsigned int aa = a, bb = b;
> return aa * bb;
> }
> ```
Easier:
uint16_t
mul( unsigned a, unsigned b ){
return a*b;
}
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-09 20:14 +0000 |
| Message-ID | <10to4im$e9f$2@reader1.panix.com> |
| In reply to | #398568 |
In article <86qznls2p8.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>[concerning UB when multiplying 16-bit unsigneds]
>
>> Yes. Btw, the fix is almost trivial:
>>
>> ```
>> uint16_t
>> mul(uint16_t a, uint16_t b)
>> {
>> unsigned int aa = a, bb = b;
>> return aa * bb;
>> }
>> ```
>
>Easier:
>
> uint16_t
> mul( unsigned a, unsigned b ){
> return a*b;
> }
Presuming one can tolerate a change in function signature. That
is fine for this contrived example, but I would hesitate to say
that more generally.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-09 15:19 +0200 |
| Message-ID | <10tnc9s$3lm5l$1@dont-email.me> |
| In reply to | #398547 |
On 09/05/2026 00:43, Dan Cross wrote:
> In article <10tk4sg$2l19a$2@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>> On 08/05/2026 00:08, Dan Cross wrote:
>>> K&R is a wonderful book for its exposition: well-written,
>>> concise, and the prose is beautiful. Kernighan is an amazing
>>> writer, and Ritchie was well-known for his patience and clear
>>> explainations.
>>>
>>> However, it is a product of its time. It dates from a simpler
>>> era, when programmers were expected to use books like it is a
>>> starting point, and subsequently gain mastery either through
>>> careful study of the standard, or extensive practice. (I'm
>>> referring specifically to K&R2, of course, since the first
>>> edition predated the first version of the standard by a decade.)
>>> Machines were smaller and simpler, then, and so were compilers.
>>>
>>> I am sad to say that I don't think it has aged particularly well.
>>
>> I like the way you put that. Sometimes people have a tendency to put
>> too much reverence on particular texts - such as imagining that K&R says
>> all that needs to be said about C, and treating any modern tool, text,
>> standard or program that diverges from it as some kind of heresy, or
>> "not following the spirit of C". Languages evolve - tools evolve,
>> programs evolve, standards evolve, requirements evolve. K&R was a
>> milestone in the history of programming languages, and a model for
>> technical writing in its field, but C today is not C of fifty years ago.
>
> Thank you. Yes, I pretty much agree.
>
>> It is unfortunate that this situation may be UB. I personally think
>> "unsigned short" should promote to "unsigned int", not "int" -
>> promotions should be signedness preserving. I don't like the "promote
>> to int" at all. But opinions don't change the standards, and I suppose
>> there are historical reasons for the rules that were made here.
>>
>> But I am not sure I agree that such cases are "easy to stumble into".
>> How often would code like that be written, where overflowing the
>> uint16_t would be correct behaviour in the code on a 16-bit int system?
>> It is certainly possible, but it is perhaps more likely that cases of
>> overflow in the 16-bit system were also bugs in the code - moving the
>> code to 32-bit systems could give different undesirable effects from the
>> bug. It could also happen to remove the effects of the bug by holding
>> results in 32-bit registers and leading to correct results in later
>> calculations - UB can work either way.
>
> Sure. This was a bit of a contrived example, but you ask a good
> question: how often might one want write code like that?
I think the particularly interesting thing about asking how often code
like this occurs, is that the potential impact of an oddity may be
higher for things that aren't often used. Most C programmers will
fairly quickly learn that overflowing signed arithmetic is UB and try to
avoid it - but the rarity of this example means that people are less
likely to realise it is UB.
>
> In short, I don't know, but I can think of any number of hash
> functions, checksums, etc, that may be implemented using 16-bit
> arithmetic, and I can well see programmers wanting to take
> advantage of the modular semantics afforded by using unsigned
> types to do so. Every day? Probably not. But often enough.
I can imagine situations in the microcontroller world (as usual, many of
my examples come from there!) where code that was originally written for
8-bit or 16-bit devices was moved to 32-bit devices. Microcontroller
programmers are big users of fixed-size integer types - sometimes a good
thing, sometimes not.
>
> One of the things I had to really internalize as an OS person is
> that the universe of useful existing software is large. It
> doesn't matter if I create the most beautiful abstractions for
> them that are infinitely superior to whatever swill their code
> is using now. If they don't get to run their program (or worse,
> they have to make a bunch of invasive changes for no discernable
> benefit from their perspective) because I know better about how
> things ought to be done, they're not going to use whatever
> system I'm working on unless they're forced. But even then they
> will resent it and move to something else the first chance they
> get (lookin' at you, DEC, Microsoft, IBM, and any number of
> commercial Unix vendors).
>
> Whatever _I_ think of how the interfaces they chose to use is
> immaterial, making it difficult for them wins me no friends.
> This is one of the smart things Torvalds did with Linux: "don't
> break userspace" (unless there's a really, really good reason)
> probably did a lot to help make Linux popular.
>
> Anyway, I think this is similar. It doesn't matter what anyone
> thinks of whether one ought to prevent all overflow; the fact
> is that the language supports it for unsigned integers (though
> with some surprising semantics for types of lower rank than
> `int`) simply is what it is. And if someone has a program that
> avails of those semantics, and that program is important to them
> for whatever reason, then there's little choice but to hold
> one's nose. I know you know this, of course, but I think it's
> worth repeating every now and then.
>
Agreed. Knowing the semantics (and knowing when no semantics are
defined) is more important than exactly what the semantics are. For any
real language, there are always going to be things you disagree with or
think could be done differently, but you live with it anyway. Just look
at the C or C++ standards committee voting records - very few changes
get voted through unanimously.
(I guess that's why Bart is so deliriously impressed with his own
language - as the language's only designer, implementer, and user, it
presumably fits his preferences quite well. Real-world languages are
more of a compromise.)
>> Certainly, however, the fact that this expression could contain UB would
>> surprise many C programmers.
>
> Yes. Btw, the fix is almost trivial:
>
> ```
> uint16_t
> mul(uint16_t a, uint16_t b)
> {
> unsigned int aa = a, bb = b;
> return aa * bb;
> }
> ```
>
But we must be careful - copying the same pattern to uint32_t would then
be incorrect if unsigned int is smaller than 32 bits. (Still no UB,
though.) A general pattern could be :
T mul(T a, T b) {
return (a + 0u) * b;
}
Then "a" would be promoted to unsigned int if it was smaller than that,
but not "demoted" if the unsigned type T is smaller than unsigned int.
It should also, I think, be safe for signed types T up to "int" - but
not bigger than "int".
> But if a programmer is not already very familiar with the
> language, it may look very odd.
>
Yes.
>>> I don't think that this what the authors originally intended
>>> (in fact, I'm quite certain it is not, based on conversations
>>> I've had with them in the past; they very much wanted the
>>> original semantics for integer promotion and did not like those
>>> chosen by the ANSI committee).
>>>
>>> K&R has not been updated in almost 40 years, and 40 years ago,
>>> it reflected a very different language, and moreover, reflected
>>> the spirit intended by the original authors.. But, regardless of
>>> the original intent, that is not the language we have _today_.
>>>
>>> I just picked my copy up off the shelf. The pages are yellowed
>>> and the corners heavily dogeared; but flipping through it is
>>> like seeing an old friend. Then I put it back on the shelf: you
>>> can never go home again.
>>
>> You make that sound so sad!
>
> It is bittersweet. I have fond memories of times spent with
> that copy of that book. I learned a lot from it, and it had an
> outsized role in shaping my career and my development as an
> engineer.
>
> I met Dennis Ritchie several times. I think he would be pleased
> and satisfied to know how many people look at K&R with fondness
> and appreciation, but perhaps moreso how many have outgrown it,
> as well. I worked in the same office as Kernighan for a while,
> and occasionally ate breakfast with him. I managed to overcome
> my embarassment enough one morning and asked him to sign my copy
> of K&R1, and I could tell he very much appreciated it; I'm
> certain he feels much the way I just described. (Sadly, I never
> asked Dennis to sign my copy before he passed away.)
>
Nice anecdote. It's nice to be reminded that such famous names are (or
were) just ordinary real people.
>> (My copy is in a box in the loft somewhere. I guess it is really one of
>> these books that should always be on the bookshelf, even if I never look
>> at it again.)
>
> Absolutely.
>
I do have Knuth's Art of Computing Programming on my shelf - but while
it too was a milestone, it is not nearly as readable. (The TeXBook, on
the other hand, was quite enjoyable, as was the MetaFont book.)
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-10 16:20 +0000 |
| Message-ID | <10tqb7u$6hn$1@reader1.panix.com> |
| In reply to | #398582 |
In article <10tnc9s$3lm5l$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 09/05/2026 00:43, Dan Cross wrote:
>> In article <10tk4sg$2l19a$2@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 08/05/2026 00:08, Dan Cross wrote:
>>>> K&R is a wonderful book for its exposition: well-written,
>>>> concise, and the prose is beautiful. Kernighan is an amazing
>>>> writer, and Ritchie was well-known for his patience and clear
>>>> explainations.
>>>>
>>>> However, it is a product of its time. It dates from a simpler
>>>> era, when programmers were expected to use books like it is a
>>>> starting point, and subsequently gain mastery either through
>>>> careful study of the standard, or extensive practice. (I'm
>>>> referring specifically to K&R2, of course, since the first
>>>> edition predated the first version of the standard by a decade.)
>>>> Machines were smaller and simpler, then, and so were compilers.
>>>>
>>>> I am sad to say that I don't think it has aged particularly well.
>>>
>>> I like the way you put that. Sometimes people have a tendency to put
>>> too much reverence on particular texts - such as imagining that K&R says
>>> all that needs to be said about C, and treating any modern tool, text,
>>> standard or program that diverges from it as some kind of heresy, or
>>> "not following the spirit of C". Languages evolve - tools evolve,
>>> programs evolve, standards evolve, requirements evolve. K&R was a
>>> milestone in the history of programming languages, and a model for
>>> technical writing in its field, but C today is not C of fifty years ago.
>>
>> Thank you. Yes, I pretty much agree.
>>
>>> It is unfortunate that this situation may be UB. I personally think
>>> "unsigned short" should promote to "unsigned int", not "int" -
>>> promotions should be signedness preserving. I don't like the "promote
>>> to int" at all. But opinions don't change the standards, and I suppose
>>> there are historical reasons for the rules that were made here.
>>>
>>> But I am not sure I agree that such cases are "easy to stumble into".
>>> How often would code like that be written, where overflowing the
>>> uint16_t would be correct behaviour in the code on a 16-bit int system?
>>> It is certainly possible, but it is perhaps more likely that cases of
>>> overflow in the 16-bit system were also bugs in the code - moving the
>>> code to 32-bit systems could give different undesirable effects from the
>>> bug. It could also happen to remove the effects of the bug by holding
>>> results in 32-bit registers and leading to correct results in later
>>> calculations - UB can work either way.
>>
>> Sure. This was a bit of a contrived example, but you ask a good
>> question: how often might one want write code like that?
>
>I think the particularly interesting thing about asking how often code
>like this occurs, is that the potential impact of an oddity may be
>higher for things that aren't often used. Most C programmers will
>fairly quickly learn that overflowing signed arithmetic is UB and try to
>avoid it - but the rarity of this example means that people are less
>likely to realise it is UB.
That's a very interesting point: aspects of languages have costs
and language design should take into account the cost of
features vis their utility.
A contemporary example I can think of here was the presence of
XML literals in Scala. Neat idea; and as I gathered at the time
I looked, it was implemented in terms of macros, but wow: talk
about something you would find in the dictionary as an example
of, "seemed like a good idea at the time."
>> In short, I don't know, but I can think of any number of hash
>> functions, checksums, etc, that may be implemented using 16-bit
>> arithmetic, and I can well see programmers wanting to take
>> advantage of the modular semantics afforded by using unsigned
>> types to do so. Every day? Probably not. But often enough.
>
>I can imagine situations in the microcontroller world (as usual, many of
>my examples come from there!) where code that was originally written for
>8-bit or 16-bit devices was moved to 32-bit devices. Microcontroller
>programmers are big users of fixed-size integer types - sometimes a good
>thing, sometimes not.
>
>> One of the things I had to really internalize as an OS person is
>> that the universe of useful existing software is large. It
>> doesn't matter if I create the most beautiful abstractions for
>> them that are infinitely superior to whatever swill their code
>> is using now. If they don't get to run their program (or worse,
>> they have to make a bunch of invasive changes for no discernable
>> benefit from their perspective) because I know better about how
>> things ought to be done, they're not going to use whatever
>> system I'm working on unless they're forced. But even then they
>> will resent it and move to something else the first chance they
>> get (lookin' at you, DEC, Microsoft, IBM, and any number of
>> commercial Unix vendors).
>>
>> Whatever _I_ think of how the interfaces they chose to use is
>> immaterial, making it difficult for them wins me no friends.
>> This is one of the smart things Torvalds did with Linux: "don't
>> break userspace" (unless there's a really, really good reason)
>> probably did a lot to help make Linux popular.
>>
>> Anyway, I think this is similar. It doesn't matter what anyone
>> thinks of whether one ought to prevent all overflow; the fact
>> is that the language supports it for unsigned integers (though
>> with some surprising semantics for types of lower rank than
>> `int`) simply is what it is. And if someone has a program that
>> avails of those semantics, and that program is important to them
>> for whatever reason, then there's little choice but to hold
>> one's nose. I know you know this, of course, but I think it's
>> worth repeating every now and then.
>
>Agreed. Knowing the semantics (and knowing when no semantics are
>defined) is more important than exactly what the semantics are. For any
>real language, there are always going to be things you disagree with or
>think could be done differently, but you live with it anyway. Just look
>at the C or C++ standards committee voting records - very few changes
>get voted through unanimously.
>
>(I guess that's why Bart is so deliriously impressed with his own
>language - as the language's only designer, implementer, and user, it
>presumably fits his preferences quite well. Real-world languages are
>more of a compromise.)
Yes. "My language is great according to my criteria" doesn't
mean it maps to anything else more generally.
>>> Certainly, however, the fact that this expression could contain UB would
>>> surprise many C programmers.
>>
>> Yes. Btw, the fix is almost trivial:
>>
>> ```
>> uint16_t
>> mul(uint16_t a, uint16_t b)
>> {
>> unsigned int aa = a, bb = b;
>> return aa * bb;
>> }
>> ```
>
>But we must be careful - copying the same pattern to uint32_t would then
>be incorrect if unsigned int is smaller than 32 bits. (Still no UB,
>though.)
>
>A general pattern could be :
>
>T mul(T a, T b) {
> return (a + 0u) * b;
>}
Yes. The example is carefully constructed to highlight a
particular case, but a more general problem would require a more
general solution solution.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-08 09:23 -0700 |
| Message-ID | <86lddtuaz7.fsf@linuxsc.com> |
| In reply to | #398457 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > NB: As opposed to other people I've never considered the K&R bible > a good book; K&R is meant to be an introduction to C, written in an informal and sometimes tutorial style. It does have an appendix posing as a reference manual, but even there it glosses over some fine points (saying so explicitly IIRC). I consider K&R an outstanding book, for what it means to accomplish, and would hold it up as a model for other programming language authors for their languages. By contrast, for another language *****, I haven't seen anything even close to the level of K&R, and have been frustrated every time I have tried to learn about it (which is more than a few times). I agree that K&R is nothing like a complete reference, and skimps in some areas that are important for serious developers. But it offers a quick way into the language (as it was when K&R was written), and is just the sort of first book I hope to see for other languages. > for every other statement it gave it created one more question > that just wasn't answered, so I remember. And the caveats like > those described in the recently posted Wang-paper just aren't > addressed. They didn't exist when K&R was written. > This is actually very unlike other languages I learned, were > simple coding situations either work as documented or lead to an > error. C was typical for its era; that's just how languages were in those days. In any case this complaint is about the language, not about the book. > I said in the past, that good textbooks should always suffice to > program in a language, and that standard documents are necessary > primarily for compiler writers. I take issue with this comment on several fronts. For any modern language, there should always be at least two books, an introduction and a reference; it's a mistake to try to combine them. I flat out disagree with the idea that standard documents are mainly for compiler writers -- a well-written standard (and the ISO C standard serves as an example) serves both communities, and indeed it is important that it do so, to ensure that both camps have the same picture. The ISO C standard isn't easy reading, but it describes the language exactly, and is still accessible enough to be read by an experienced developer. The language standard document should be able to serve as the language reference document, and vice versa. When they are not it means someone hasn't been doing their job. > For "C" I meanwhile think that this doesn't hold. To not run into > pitfalls you need to know things that are described in (the later > [to K&R] appearing) standard documents. Two comments. First, the pitfalls you are talking about came about only after the C standard was first written; they are a consequence of the language description, not part of it. Second, as a corollary to that, they need to be described separately. There is a lore of language usage (and I think this is true for most languages, not just C) that is important to know but is not really part of either an introductory text or the language reference. As such the lore deserves separate treatment.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-08 19:58 +0200 |
| Message-ID | <10tl87v$1l93l$13@dont-email.me> |
| In reply to | #398503 |
On 2026-05-08 18:23, Tim Rentsch wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>> NB: As opposed to other people I've never considered the K&R bible
>> a good book;
>
> K&R is meant to be an introduction to C, written in an informal and
> sometimes tutorial style. [...]
Acknowledged.
> [...]
>
>> for every other statement it gave it created one more question
>> that just wasn't answered, so I remember. [...]
>
>> This is actually very unlike other languages I learned, were
>> simple coding situations either work as documented or lead to an
>> error.
>
> C was typical for its era; that's just how languages were in those
> days. In any case this complaint is about the language, not about
> the book.
We have disagreement here.
Different languages, paradigms, and their design process varied.
It was a comment about the books available to learn a language.
(Of course K&R was sufficient to sit down and hack up programs.
But to repeat the main point: "for every other statement it gave
it created one more question that just wasn't answered". YMMV.)
Disclaimer: As probably most folks, from the many existing languages,
I've just learned to program in about a dozen (or only slightly more).
Back then usually from books. They usually answered the questions the
programmers need and were a solid base. K&R was why I said "usually".
For the subsequent opinions quoted below I think it makes no sense to
go into the details of wording, so I just add three points and leave
it otherwise quoted as it is at the end of the post.
I see three sensible separations; tutorial, reference, standard.[*]
Other languages (even at that time) made a better job. YMMV. From the
languages I learned I'll pick up a complex one, Simula. (It's not, as
"C", a complicated language, just complex.) - There's good tutorials
(like "SIMULA BEGIN"), there's a reference ("Common Base Language",
base for the standard), and there's the official "SIMULA Standard".
The reference and the standard documents had each ~150 pages. Not to
compare to the "C" standard where 700 pages - is that correct? - were
needed to describe it. The Simula documents had what the respective
groups, programmers or compiler constructors, need. It has a complex
memory model, supports OO, concurrency concepts, and whatnot. Despite
this complexity (and C's primitivity) the text that programmers need
to use it sophisticatedly appears not disproportional. - The books for
other languages were more like the Simula case than like the K&R case.
That was the whole point. YMMV.
"C" is in many respects (books, design, standard) different from many
other languages I've seen.
Janis
[*] A strict separation isn't necessary; it may be all in one, or
two published together. The Algol 68 Genie creator decided to have
all together, tutorial and standard. Although the standard (the
"Revised Report") is still also a stand-alone document he decided to
include the official text from the standards group in his document.
But this is just a specific example. - The main point being was that
different groups of people need different types of texts, in form and
in content.
>
>> I said in the past, that good textbooks should always suffice to
>> program in a language, and that standard documents are necessary
>> primarily for compiler writers.
>
> I take issue with this comment on several fronts. For any modern
> language, there should always be at least two books, an introduction
> and a reference; it's a mistake to try to combine them. I flat out
> disagree with the idea that standard documents are mainly for
> compiler writers -- a well-written standard (and the ISO C standard
> serves as an example) serves both communities, and indeed it is
> important that it do so, to ensure that both camps have the same
> picture. The ISO C standard isn't easy reading, but it describes
> the language exactly, and is still accessible enough to be read by
> an experienced developer. The language standard document should be
> able to serve as the language reference document, and vice versa.
> When they are not it means someone hasn't been doing their job.
>
>> For "C" I meanwhile think that this doesn't hold. To not run into
>> pitfalls you need to know things that are described in (the later
>> [to K&R] appearing) standard documents.
>
> Two comments. First, the pitfalls you are talking about came about
> only after the C standard was first written; they are a consequence
> of the language description, not part of it. Second, as a corollary
> to that, they need to be described separately. There is a lore of
> language usage (and I think this is true for most languages, not
> just C) that is important to know but is not really part of either
> an introductory text or the language reference. As such the lore
> deserves separate treatment.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-13 10:38 -0700 |
| Message-ID | <86zf23jjle.fsf@linuxsc.com> |
| In reply to | #398515 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 2026-05-08 18:23, Tim Rentsch wrote: > >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> >>> NB: As opposed to other people I've never considered the K&R bible >>> a good book; >> >> K&R is meant to be an introduction to C, written in an informal and >> sometimes tutorial style. [...] > > Acknowledged. > >> [...] >> >>> for every other statement it gave it created one more question >>> that just wasn't answered, so I remember. [...] >>> >>> This is actually very unlike other languages I learned, were >>> simple coding situations either work as documented or lead to an >>> error. >> >> C was typical for its era; that's just how languages were in those >> days. In any case this complaint is about the language, not about >> the book. [.. I am focusing on just the book comparison ..] > It was a comment about the books available to learn a language. > (Of course K&R was sufficient to sit down and hack up programs. > But to repeat the main point: "for every other statement it gave > it created one more question that just wasn't answered". YMMV.) > > [.. the language chosen for comparison is Simula 67] There's good > tutorials (like "SIMULA BEGIN"), [...]. [Other Simula documents > were mentioned but they aren't relevant to my comments which were > only about The C Programming Language, by Kernighan and Ritchie] To partly repeat myself, my comments were only about K&R and the writing in it; it wasn't an assessment of the language. I think the implied parallel with Simula BEGIN is an apples and oranges comparison. I wouldn't call Simula BEGIN a tutorial. It's almost twice as long as K&R. Simula 67 is built around Algol 60 as a base language; it's safe to assume many or most readers would already be familiar with it, and so it doesn't need to be explained as much. Simula is a safe language (or at least it can be - it's possible there were unsafe implementations), and C is not, and that means it's easier to define the semantics of Simula than to define the semantics of C. C has bare pointers, and address arithmetic; Simula has neither. C is able to deal with bare hardware, including numeric hardware addresses; Simula doesn't consider such things. I don't mean to shortchange Simula, which is an amazing and powerful language. But the semantics of Simula are easier to define than the semantics of C, with all its of vagaries, and yet K&R does a fair job of that in roughly half as many pages as Simula BEGIN -- and it's worth noting that K&R includes both a tutorial and a short reference. Disclaimer: even though I have done a fair amount of programming in Simula, it's been a long time since I did so, and a longer time since I read Simula BEGIN. I am working purely from memory and haven't had a chance to check against the actual text. I did cut out a lot of your comments about other Simula documents. I did that because it looked like an effort to shift the topic of conversation from talking about the quality of the text to talking about the language. I understand that you have complaints about C, and I might even agree with some of them. But my earlier comments were only about the writing in K&R, not about whether C is a good language, and I don't want to stray from that into other uncharted waters.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-07 07:46 -0400 |
| Message-ID | <10thu3b$20gfp$1@dont-email.me> |
| In reply to | #398425 |
Bart <bc@freeuk.com> writes: [...] > However nobody here, all the experts, have ever offered a link to any > of the work they do, not even privately. I've never seen examples of Before I retired, in response in this group to a question about the MODIS project I was working on for NASA, I posted links to the code. That code was required by our contract to be publicly available. I identified which of the programs were my responsibility. > So, again, why am I expected to provide credentials? You aren't. What made you think that you were?
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-05-08 21:02 +0000 |
| Message-ID | <10tlj1h$129ms$1@paganini.bofh.team> |
| In reply to | #398425 |
Bart <bc@freeuk.com> wrote:
> On 06/05/2026 20:35, Dan Cross wrote:
>> In article <10tflij$19d6u$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>
> Therefore I have an advantage in producing a tidier language with some
> modern conveniences.
If you mean tidier language than C, then I mostly agree. "Mostly"
because I find case insensitivity definitely untidy.
> You might want to admit that rather than just
> trashing everything because you don't care for my attitude.
>
> Huh. This is C:
>
> uint64_t F(uint64_t s, uint64_t t, uint64_t u, uint64_t v) ...
>
> This is my language:
>
> func F(u64 s, t, u, v)u64 ...
>
> All the parameters are the same type. If you change that first u64, they
> all change. The parameter names are 's t u v'.
Yes, in this case having single type for parameters is simpler.
> They are the same types in the C too, but you have to work harder to
> double-check they are in fact identical. If you change that type, then
> you have to change it at multiple sites; if you forget one, the compiler
> will not tell you.
Well, if there is mismatch, them compiler will tell you. If types
make sense, but are different than intended, then you have trouble.
But this trouble is not different from situation where you need to
change one type, but keep other unchanged. For example, if you
need
uint64_t F(uint64_t s, uint64_t t, uint32_t u, uint64_t v)
In such case C version is easier to modify correctly.
> You will also have a harder type discerning the parameter names, as
> there are dominated by all those ugly types.
>
> This is one tiny example of better ergonomics. Now you're going to tell
> me the C version is better!
Well, you can not have it all. Allowing single type for multiple
parameters probably is better overall, but there are also costs,
for example C version allows giving only types in prototype, while
single type for multiple parameters very much forces repeating
parameter names (which may be a good thing, but goes against
your desire to save typing).
Anyway, in last 35 years programmable editors were widely available.
If need to type extra characters bothers you, then it is possible
to program your editor so that it inserts more complicated construct
on single keystroke or on small number of of keystrokes.
In somewhat different spirit, in my coding cases with multiple
arguments having the same type are relatively rare: if multiple
pieces of data should go together, then I pass them as a struct
or array.
>>> While my 2026 language is old-fashioned compared with modern languages,
>>> it runs rings around C. Here are some highlights:
>>>
>>> [snip]
>>
>> Everything on the list you presented is one or more of,
>> a. subjective,
>> b. arguably a bad choice,
>> c. hardly novel.
>>
>> None of it is evidence that your language "runs rings around C".
>
> I could provide a 100-long list that goes into more micro-features but
> I'd be wasting my time. There's no point in providing links either. You
> have already made up your mind.
>
> Note that:
Let me put numbers to identify the claims:
> * There are no C-style header files
1.
> * There are no separate declarations needed, neither in shared headers,
> nor as prototypes
2.
> * If a module is imported by 50 others, it is processed exactly once
3.
> * Project info (modules etc) is present in only one module of a project.
> (Most module schemes require import directives in every module)
4.
> * That means no external build system is needed.
5.
> Just that is HUGE.
Well, UCSD/Turbo Pascal, Ada, Modula 2, Oberon all have module system
satisfying 3 and 5. UCSD/Turbo Pascal and Oberon do not have
separate interface files, so satisfy 1 (Ada and Modula 2 have
separate interface files, but they have different nature than
C header files). Oberon satisfies 2. So only possibly novel part
is 4.
Looking at implementation decisions, there were strong voices for
separate interface files. So 1 is at least "subjective". I
would say that 2 is probably "arguably bad idea". Concerning 4,
I routinely use a module system where import directive are
sometimes unnecessary: basicaly 'import' means that names from
given module may be used without qualification. If somebody
decided to use only qualified names, then 'import' is not
necessary. Arguably, information saying from which module to
take given name (and given module may simultaneously use the
same name from multiple modules) is part of source code of
given module. You apparently think differently, but I want
to keep related things together, so want this information
included in module source. So for me your 4 is "arguably
bad idea".
Note that all languages that I mention are at roughly similar
level as C, all are more (Oberon) or less (Ada) niche now.
But I think that each of them has more users than your
language (original UCSD Pascal and Turbo Pascal are dead, but
there are Turbo Pascal compatible products in current developement).
Also, users and developers of those languages probably think
that they "run rings around C", but do not come here to complain
how bad C is.
Anyway, when you come here and propose your language as alternative
to C, then you implicitly claim that your language is better than
Ada, Modula 2, Pascal and a lot of other languages which competed
with C. Even more, since C programmers did not switch to other
languages earlier, your language must be _much_ better than
other ones. Do you realize how grandiose claim it is? Maybe
you do not mean this, but that is impression that you give.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
Page 17 of 37 — ← Prev page 1 … 15 16 [17] 18 19 … 37 Next page →
Back to top | Article view | comp.lang.c
csiph-web