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 12 of 37 — ← Prev page 1 … 10 11 [12] 13 14 … 37 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-12 00:38 -0700 |
| Message-ID | <10tulec$1p7o0$2@kst.eternal-september.org> |
| In reply to | #398799 |
David Brown <david.brown@hesbynett.no> writes:
> On 11/05/2026 23:30, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> Perhaps the main "mistake" (where "mistake" means "I personally think
>>> C would be nicer for my own use if things were different") is that
>>> when mixing operations between signed int and unsigned int, the signed
>>> int is converted to unsigned. I suspect that in real-world code,
>>> unsigned int values that are within the range of signed int are common
>>> - and that negative signed int values are more common than unsigned
>>> int values that are out of range of signed int. Any common type here,
>>> unless it is larger than the two original types, is going to get some
>>> things wrong - but I think that converging on signed int as the common
>>> type would be wrong less often. And if that had been the rule, then
>>> unsigned-preserving promotion would be correct too in examples like
>>> yours.
>> [...]
>> If I were designing a new C-like language, I'd probably avoid the
>> issue of signed-preserving vs. value-preserving altogether. I might
>> say operations where one operand is signed and the other is unsigned
>> are not allowed; if you need that, you can cast one of the operands.
>
> I'd be with you on that.
>
> However, I think you'd quickly run into inconveniences and annoyances
> with integer constants - you'd want "x * 2" to work regardless of the
> signedness of x's type. I am no Ada expert, and it's OT anyway, but I
> believe in Ada the type of integer constants adapts to fit when used
> like this - you'd need something similar to make the hypothetical K&B
> C language work well. Integer constants would have to be
> "questionably signed", not signed or unsigned. (Maybe "adaptively
> typed" might be a better term, and include the size of the type as
> well as the signedness.)
Right, that could be a problem.
In Ada, the type of an integer literal (and of certain other
constructs, similar to C's integer constant expressions) is
<universal_integer>, an anonymous type that exists only at compile
time and can represent unbounded values. Any value of that type
is implicitly converted a type determined by the context.
*Maybe* something similar to that could be a sensible approach for
my hypothetical C-like language that will never actually exist.
Or maybe an integer literal could be treated as of type intmax_t
or uintmax_t, depending on the context (similar to how integer
literals are treated in the preprocessor).
(Aside: I'm using "integer literal" to match the term used in both
Ada and the draft of C2y, rather than "integer constant" as used
in C up to C23.)
[...]
>> Of course C can't be changed in this way without breaking tons of
>> existing code.
>
> The curse of popularity.
Indeed.
--
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 | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-12 14:05 +0000 |
| Message-ID | <10tvc31$mun$1@reader1.panix.com> |
| In reply to | #398799 |
In article <10tuhmt$1o3bp$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 11/05/2026 23:30, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >> [...] >>> Perhaps the main "mistake" (where "mistake" means "I personally think >>> C would be nicer for my own use if things were different") is that >>> when mixing operations between signed int and unsigned int, the signed >>> int is converted to unsigned. I suspect that in real-world code, >>> unsigned int values that are within the range of signed int are common >>> - and that negative signed int values are more common than unsigned >>> int values that are out of range of signed int. Any common type here, >>> unless it is larger than the two original types, is going to get some >>> things wrong - but I think that converging on signed int as the common >>> type would be wrong less often. And if that had been the rule, then >>> unsigned-preserving promotion would be correct too in examples like >>> yours. >> [...] >> >> If I were designing a new C-like language, I'd probably avoid the >> issue of signed-preserving vs. value-preserving altogether. I might >> say operations where one operand is signed and the other is unsigned >> are not allowed; if you need that, you can cast one of the operands. > >I'd be with you on that. > >However, I think you'd quickly run into inconveniences and annoyances >with integer constants - you'd want "x * 2" to work regardless of the >signedness of x's type. I am no Ada expert, and it's OT anyway, but I >believe in Ada the type of integer constants adapts to fit when used >like this - you'd need something similar to make the hypothetical K&B C >language work well. Integer constants would have to be "questionably >signed", not signed or unsigned. (Maybe "adaptively typed" might be a >better term, and include the size of the type as well as the signedness.) I think the term you are looking for is "strongly typed". :-) That is, types are verifably compatible. In a strongly- and statically-typed language (that is, one where the types of objects are known at compile time), it's possible to be both expressive and precise. There are plenty of examples of such langauges, but the common characteristic is that they (usually) _infer_ the type of an expression based on the types of the operands; there are well-known, formally sound, techniques for doing this With respect to literal constants, this would simply mean that the literal would be considered to be of the inferred type of the expression it was in: if no such inference could be made (for instance, the types are fundamentally incompatbile), then the compiler fail, flagging the type incompatibility as an error. So, if this were a fragment of a program in a hypothetical C dialect that was strongly typed and used type inference, unsigned int a = 5; unsigned int c = a * 2; both `5` and `2` would be inferred to have type `unsigned int`, since both are representable as unsigned ints. However, unsigned int c = a * -2; would be a compile time error, since the resulting type of the expression must be `unsigned int`, but `-2` is not an unsigned integer: it would have to be explicitly converted first. >> The C committee decided to impose a more or less reasonable rule on >> all such operations; I might require the programmer to decide what >> to do in each case. (There might be an exception for constants, >> so that u+1 doesn't require a cast; I haven't thought through the >> implications of that.) > >Certainly the rules work - even if I might have preferred something >different, you can learn the rules and right correct code using them. >Lots of people do! Yes, there are many examples of this, so it is obviously true. However, I don't think there are many large projects written in C where there isn't undefined behavior lurking somewhere, and the amount of effort required to learn _all_ the rules of the language is unnecessarily large. I think it is fair to say that there are people who wear their knowledge of the C standard as a badge of honor and look down at those who desire a simpler language or who do not know the rules as well. Some of that is fair (we see examples in this group of some who not only refuse to learn the rules of the language, but revel in their ignorance). But that doesn't mean that all of the criticism is wrong, and the frequency at which it happens that people run into UB is also an indictment of the language. Put it this way: it may be the programmer's fault that they relied on UB, but that it is so evidently hard to learn and internalize the rules is also the fault of the langauge. It is not wrong to wish it were better. >> I'd also define operations on narrow types, so the promotion rules >> become unnecesary. > ><aol> Me too! </aol> > >I might start using the _BitInt types, once the versions of gcc I need >for the targets I need have good support for them. > >> Of course C can't be changed in this way without breaking tons of >> existing code. > >The curse of popularity. The curse of history! - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-12 16:32 +0200 |
| Message-ID | <10tvdm8$1vmna$1@dont-email.me> |
| In reply to | #398810 |
On 12/05/2026 16:05, Dan Cross wrote: > In article <10tuhmt$1o3bp$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> On 11/05/2026 23:30, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>>> Perhaps the main "mistake" (where "mistake" means "I personally think >>>> C would be nicer for my own use if things were different") is that >>>> when mixing operations between signed int and unsigned int, the signed >>>> int is converted to unsigned. I suspect that in real-world code, >>>> unsigned int values that are within the range of signed int are common >>>> - and that negative signed int values are more common than unsigned >>>> int values that are out of range of signed int. Any common type here, >>>> unless it is larger than the two original types, is going to get some >>>> things wrong - but I think that converging on signed int as the common >>>> type would be wrong less often. And if that had been the rule, then >>>> unsigned-preserving promotion would be correct too in examples like >>>> yours. >>> [...] >>> >>> If I were designing a new C-like language, I'd probably avoid the >>> issue of signed-preserving vs. value-preserving altogether. I might >>> say operations where one operand is signed and the other is unsigned >>> are not allowed; if you need that, you can cast one of the operands. >> >> I'd be with you on that. >> >> However, I think you'd quickly run into inconveniences and annoyances >> with integer constants - you'd want "x * 2" to work regardless of the >> signedness of x's type. I am no Ada expert, and it's OT anyway, but I >> believe in Ada the type of integer constants adapts to fit when used >> like this - you'd need something similar to make the hypothetical K&B C >> language work well. Integer constants would have to be "questionably >> signed", not signed or unsigned. (Maybe "adaptively typed" might be a >> better term, and include the size of the type as well as the signedness.) > > I think the term you are looking for is "strongly typed". :-) Sure - I want this all to be strongly typed, but the question is what should the type of integer constants / integer literals be? Ada calls them "universal_integer" type, which might be a good name. (I don't think there's a need to do too much bikeshedding for a purely hypothetical language, however.) > That is, types are verifably compatible. In a strongly- and > statically-typed language (that is, one where the types of > objects are known at compile time), it's possible to be both > expressive and precise. There are plenty of examples of such > langauges, but the common characteristic is that they (usually) > _infer_ the type of an expression based on the types of the > operands; there are well-known, formally sound, techniques for > doing this Yes. I'd want the hypothetical language to be more strongly typed than C. > > With respect to literal constants, this would simply mean that > the literal would be considered to be of the inferred type of > the expression it was in: if no such inference could be made > (for instance, the types are fundamentally incompatbile), then > the compiler fail, flagging the type incompatibility as an > error. > Yes. > So, if this were a fragment of a program in a hypothetical C > dialect that was strongly typed and used type inference, > > unsigned int a = 5; > unsigned int c = a * 2; > > both `5` and `2` would be inferred to have type `unsigned int`, > since both are representable as unsigned ints. However, > > unsigned int c = a * -2; > > would be a compile time error, since the resulting type of the > expression must be `unsigned int`, but `-2` is not an unsigned > integer: it would have to be explicitly converted first. > That would be good. I think there'd be a fair bit of overlap in our personal perfected versions or dialects of C - but I'm sure there would be differences too. >>> The C committee decided to impose a more or less reasonable rule on >>> all such operations; I might require the programmer to decide what >>> to do in each case. (There might be an exception for constants, >>> so that u+1 doesn't require a cast; I haven't thought through the >>> implications of that.) >> >> Certainly the rules work - even if I might have preferred something >> different, you can learn the rules and right correct code using them. >> Lots of people do! > > Yes, there are many examples of this, so it is obviously true. > However, I don't think there are many large projects written in > C where there isn't undefined behavior lurking somewhere, and > the amount of effort required to learn _all_ the rules of the > language is unnecessarily large. > > I think it is fair to say that there are people who wear their > knowledge of the C standard as a badge of honor and look down at > those who desire a simpler language or who do not know the rules > as well. Some of that is fair (we see examples in this group of > some who not only refuse to learn the rules of the language, but > revel in their ignorance). > > But that doesn't mean that all of the criticism is wrong, and > the frequency at which it happens that people run into UB is > also an indictment of the language. Put it this way: it may be > the programmer's fault that they relied on UB, but that it is so > evidently hard to learn and internalize the rules is also the > fault of the langauge. It is not wrong to wish it were better. > It is not wrong to wish C were better - with hindsight, there are many ways in which a slightly different language would have kept the advantages of C while reducing at least some risks of errors (whether UB or not). But I think that a lot of the UB in you might find in large projects would be bugs in the code regardless of how that UB might have been defined. That is, even if signed integer arithmetic overflow had been fully defined, you'd still get the wrong answer and the program has a bug. The same with dereferencing a null pointer, or a buffer overflow, or using the value of an uninitialised local variable. That is, if you write your code so that it would have been bug-free in a language that did not have these UB's, the C code would be the same. The exceptions here would be cases where a programmer wrongly assumes something has defined behaviour, and writes code according to that assumption. Thus if they write code that assumes reading an uninitialised local variable returns 0, or has an unspecified (but not undefined) value, or that assumes signed integer overflow is defined as wrapping - /then/ the C language's UB can surprise them in a way other languages generally do not. I don't think there are other situations where you could hit UB while expecting defined behaviour. (But as we know, there are a few situations where the signed integer overflow can be hiding unexpectedly, like uint16_t * uint16_t.) >>> I'd also define operations on narrow types, so the promotion rules >>> become unnecesary. >> >> <aol> Me too! </aol> >> >> I might start using the _BitInt types, once the versions of gcc I need >> for the targets I need have good support for them. >> >>> Of course C can't be changed in this way without breaking tons of >>> existing code. >> >> The curse of popularity. > > The curse of history! > > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-12 17:27 +0000 |
| Message-ID | <10tvnu7$4bl$1@reader1.panix.com> |
| In reply to | #398814 |
In article <10tvdm8$1vmna$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 12/05/2026 16:05, Dan Cross wrote: >> [snip] >> I think the term you are looking for is "strongly typed". :-) > >Sure - I want this all to be strongly typed, but the question is what >should the type of integer constants / integer literals be? Ada calls >them "universal_integer" type, which might be a good name. (I don't >think there's a need to do too much bikeshedding for a purely >hypothetical language, however.) It is whatever it is inferred to be by the compiler, during type analysis. In this discussion, we are hypothesizing a syntax for numeric literals that is ambiguous, in that the same literal can be shared between different types: 2 is 2, in our notation for both signed and unsigned integers. One might say that such a literal could be an instance of any in a _set_ of potential types, of which the value of the literal is a member. The question is then, how do we select one? Assuming, say, the Hindley-Milner type inference algorithm, the process is pretty well-defined: the semantics of the language define what the types must be for a given "phrase" in the language, and the compiler tries to unify those with whatever constructs it finds match those phrases in the program sources. If that process succeeds, it knows the required type; if it fails, then the program is in error. Ie, the semantics might say, "the language provides a way to define functions. Part of a function's definition is defining the types of its arguments. If a function is defined to take two integer arguments, then its arguments must be integers." It sounds tautalogical, but consider that the semantics could _also_ include a bunch of implicit type conversion rules (this is what C does, more or less). But then it would be weakly typed: one could not look at the definition of the function and know that the arguments could not be, say, character data that is implicitly converted to an implementation-defined code point. Anyway, for literals, the set of types to which one may belong is a unification input. If unification succeeds but the result is an equivalence class, then the types are ambiguous and inference usually fails with the compiler complaining; often the programmer can fix that by adding an explicit type annotation somewhere. >> That is, types are verifably compatible. In a strongly- and >> statically-typed language (that is, one where the types of >> objects are known at compile time), it's possible to be both >> expressive and precise. There are plenty of examples of such >> langauges, but the common characteristic is that they (usually) >> _infer_ the type of an expression based on the types of the >> operands; there are well-known, formally sound, techniques for >> doing this > >Yes. I'd want the hypothetical language to be more strongly typed than C. Absolutely. >> With respect to literal constants, this would simply mean that >> the literal would be considered to be of the inferred type of >> the expression it was in: if no such inference could be made >> (for instance, the types are fundamentally incompatbile), then >> the compiler fail, flagging the type incompatibility as an >> error. > >Yes. > >> So, if this were a fragment of a program in a hypothetical C >> dialect that was strongly typed and used type inference, >> >> unsigned int a = 5; >> unsigned int c = a * 2; >> >> both `5` and `2` would be inferred to have type `unsigned int`, >> since both are representable as unsigned ints. However, >> >> unsigned int c = a * -2; >> >> would be a compile time error, since the resulting type of the >> expression must be `unsigned int`, but `-2` is not an unsigned >> integer: it would have to be explicitly converted first. > >That would be good. > >I think there'd be a fair bit of overlap in our personal perfected >versions or dialects of C - but I'm sure there would be differences too. Oh sure. >>>> The C committee decided to impose a more or less reasonable rule on >>>> all such operations; I might require the programmer to decide what >>>> to do in each case. (There might be an exception for constants, >>>> so that u+1 doesn't require a cast; I haven't thought through the >>>> implications of that.) >>> >>> Certainly the rules work - even if I might have preferred something >>> different, you can learn the rules and right correct code using them. >>> Lots of people do! >> >> Yes, there are many examples of this, so it is obviously true. >> However, I don't think there are many large projects written in >> C where there isn't undefined behavior lurking somewhere, and >> the amount of effort required to learn _all_ the rules of the >> language is unnecessarily large. >> >> I think it is fair to say that there are people who wear their >> knowledge of the C standard as a badge of honor and look down at >> those who desire a simpler language or who do not know the rules >> as well. Some of that is fair (we see examples in this group of >> some who not only refuse to learn the rules of the language, but >> revel in their ignorance). >> >> But that doesn't mean that all of the criticism is wrong, and >> the frequency at which it happens that people run into UB is >> also an indictment of the language. Put it this way: it may be >> the programmer's fault that they relied on UB, but that it is so >> evidently hard to learn and internalize the rules is also the >> fault of the langauge. It is not wrong to wish it were better. > >It is not wrong to wish C were better - with hindsight, there are many >ways in which a slightly different language would have kept the >advantages of C while reducing at least some risks of errors (whether UB >or not). > >But I think that a lot of the UB in you might find in large projects >would be bugs in the code regardless of how that UB might have been >defined. I think that most of it is emergent. One is consuming some library, and one uses a function-like macro that that library exposes through some header file, and one thinks that everything is well-defined; at least, it appears so given given the context the macro appears in, but this tickles UB in some way the programmer may not be aware of. That kind of thing happens pretty frequently, and UB frequently manifests as spooky action at a distance. For example, a few years ago at my previous job, someone discovered a version of Linux compiled with clang/LLVM behaving strangely; eventually, it was traced to a linked-list library that exhibited UB under some obscure condition (I'm afraid I no longer recall the details), and the compiler taking advantage of that to remove some crucial check for something. I vaguely remember the Linux people demanding a knob force the compiler's behavior. However, the salient issue to my mind was that no one saw the UB problem until the code that _used_ that library started exhibiting errors. It's too easy to make a mess. >That is, even if signed integer arithmetic overflow had been >fully defined, you'd still get the wrong answer and the program has a >bug. The same with dereferencing a null pointer, or a buffer overflow, >or using the value of an uninitialised local variable. That is, if you >write your code so that it would have been bug-free in a language that >did not have these UB's, the C code would be the same. Sure, though this ignores the issue with large probjects that integrate many parts I mentioned above. Sometimes it's due to something you did, but it's happening somewhere else because of the way they used your thing (if that makes any sense). I would argue those things things you mentioned should either be a) unrepresentable (e.g., provide non-nullable references in the language), or b) hard errors that are defined to trap unless wrapping behavior is explicitly requested. Of course, we all agree that language would not be C. :-) >The exceptions here would be cases where a programmer wrongly assumes >something has defined behaviour, and writes code according to that >assumption. Thus if they write code that assumes reading an >uninitialised local variable returns 0, or has an unspecified (but not >undefined) value, or that assumes signed integer overflow is defined as >wrapping - /then/ the C language's UB can surprise them in a way other >languages generally do not. I don't think there are other situations >where you could hit UB while expecting defined behaviour. (But as we >know, there are a few situations where the signed integer overflow can >be hiding unexpectedly, like uint16_t * uint16_t.) Yes. UB often manifests as spooky action at a distance, and the loose notion of "undefined behavior" that is interpreted as, "lol the compiler can do whateeeeever, bro...yolo!" is, I think, bad. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-12 15:33 +0100 |
| Message-ID | <10tvdne$20o1q$2@dont-email.me> |
| In reply to | #398810 |
On 12/05/2026 15:05, Dan Cross wrote:
> In article <10tuhmt$1o3bp$1@dont-email.me>,
> David Brown <david.brown@hesbynett.no> wrote:
>> On 11/05/2026 23:30, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>> Perhaps the main "mistake" (where "mistake" means "I personally think
>>>> C would be nicer for my own use if things were different") is that
>>>> when mixing operations between signed int and unsigned int, the signed
>>>> int is converted to unsigned. I suspect that in real-world code,
>>>> unsigned int values that are within the range of signed int are common
>>>> - and that negative signed int values are more common than unsigned
>>>> int values that are out of range of signed int. Any common type here,
>>>> unless it is larger than the two original types, is going to get some
>>>> things wrong - but I think that converging on signed int as the common
>>>> type would be wrong less often. And if that had been the rule, then
>>>> unsigned-preserving promotion would be correct too in examples like
>>>> yours.
>>> [...]
>>>
>>> If I were designing a new C-like language, I'd probably avoid the
>>> issue of signed-preserving vs. value-preserving altogether. I might
>>> say operations where one operand is signed and the other is unsigned
>>> are not allowed; if you need that, you can cast one of the operands.
>>
>> I'd be with you on that.
>>
>> However, I think you'd quickly run into inconveniences and annoyances
>> with integer constants - you'd want "x * 2" to work regardless of the
>> signedness of x's type. I am no Ada expert, and it's OT anyway, but I
>> believe in Ada the type of integer constants adapts to fit when used
>> like this - you'd need something similar to make the hypothetical K&B C
>> language work well. Integer constants would have to be "questionably
>> signed", not signed or unsigned. (Maybe "adaptively typed" might be a
>> better term, and include the size of the type as well as the signedness.)
>
> I think the term you are looking for is "strongly typed". :-)
> That is, types are verifably compatible. In a strongly- and
> statically-typed language (that is, one where the types of
> objects are known at compile time), it's possible to be both
> expressive and precise. There are plenty of examples of such
> langauges, but the common characteristic is that they (usually)
> _infer_ the type of an expression based on the types of the
> operands; there are well-known, formally sound, techniques for
> doing this
>
> With respect to literal constants, this would simply mean that
> the literal would be considered to be of the inferred type of
> the expression it was in: if no such inference could be made
> (for instance, the types are fundamentally incompatbile), then
> the compiler fail, flagging the type incompatibility as an
> error.
>
> So, if this were a fragment of a program in a hypothetical C
> dialect that was strongly typed and used type inference,
>
> unsigned int a = 5;
> unsigned int c = a * 2;
>
> both `5` and `2` would be inferred to have type `unsigned int`,
> since both are representable as unsigned ints. However,
>
> unsigned int c = a * -2;
>
> would be a compile time error, since the resulting type of the
> expression must be `unsigned int`, but `-2` is not an unsigned
> integer: it would have to be explicitly converted first.
>
>>> The C committee decided to impose a more or less reasonable rule on
>>> all such operations; I might require the programmer to decide what
>>> to do in each case. (There might be an exception for constants,
>>> so that u+1 doesn't require a cast; I haven't thought through the
>>> implications of that.)
>>
>> Certainly the rules work - even if I might have preferred something
>> different, you can learn the rules and right correct code using them.
>> Lots of people do!
>
> Yes, there are many examples of this, so it is obviously true.
> However, I don't think there are many large projects written in
> C where there isn't undefined behavior lurking somewhere, and
> the amount of effort required to learn _all_ the rules of the
> language is unnecessarily large.
>
> I think it is fair to say that there are people who wear their
> knowledge of the C standard as a badge of honor and look down at
> those who desire a simpler language or who do not know the rules
> as well. Some of that is fair (we see examples in this group of
> some who not only refuse to learn the rules of the language, but
> revel in their ignorance).
Take for example C's set of operator precedences.
The one for the ?: operator is particularly obscure, so in an expression
like one of these:
a + b ? c - d : e * f
a ? b ? c : d ? e : f : g
then parentheses would be used to make things clearer. (I haven't check
these are valid, but that is the point; it is hard to see!)
But would shouldn't people be expected to learn the rules? Why is it OK
to 'revel' in not knowing the basics here, but not when unnecessary UBs
are involved where rules are harder and which depend on runtime inputs?
(In my syntaxes, the ?: equivalent /requires/ parentheses. And some of
those UBs are not UBs. To get back to my car analogy, its like somebody
refusing to master double-declutching, but in modern car it is not
necessary.
As for mixing signed and unsigned, I have my own misgivings about that,
and am moving slowly into marginalising unsigned types, but it is
already causing some unintuitive errors in either language.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-12 16:00 -0700 |
| Message-ID | <10u0beb$2ag0d$1@kst.eternal-september.org> |
| In reply to | #398815 |
Bart <bc@freeuk.com> writes:
> On 12/05/2026 15:05, Dan Cross wrote:
[...]
>> I think it is fair to say that there are people who wear their
>> knowledge of the C standard as a badge of honor and look down at
>> those who desire a simpler language or who do not know the rules
>> as well. Some of that is fair (we see examples in this group of
>> some who not only refuse to learn the rules of the language, but
>> revel in their ignorance).
>
> Take for example C's set of operator precedences.
>
> The one for the ?: operator is particularly obscure, so in an
> expression like one of these:
>
> a + b ? c - d : e * f
> a ? b ? c : d ? e : f : g
>
> then parentheses would be used to make things clearer. (I haven't
> check these are valid, but that is the point; it is hard to see!)
Some C programmers make it a point to know all the operator
precedences by heart. I don't. I know most of them, but I
occasionally have to look them up. (My method is to look at the
subsection headers in 6.5 "Expressions", and look at the grammar
when I need more detail. Others prefer to use tables.)
> But would shouldn't people be expected to learn the rules? Why is it
> OK to 'revel' in not knowing the basics here, but not when unnecessary
> UBs are involved where rules are harder and which depend on runtime
> inputs?
There's nothing wrong with adding parentheses to make an expression
clearer. It doesn't imply an unwillingness to learn the rules,
just consideration for one's audience. Some readers mitgh understand
the unparenthesized version at a glance. Others might have to think
about it for an annoy few seconds, others might have to look it up
or feed it to some tool.
That's not at all comparable to your explicit refusal to even read
the standard's definition of "undefined behavior". (Or were you
being figurative?)
[...]
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-12 23:14 +0000 |
| Message-ID | <PvOMR.3046$_v1.2139@fx21.iad> |
| In reply to | #398831 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >Bart <bc@freeuk.com> writes: >> On 12/05/2026 15:05, Dan Cross wrote: >[...] >>> I think it is fair to say that there are people who wear their >>> knowledge of the C standard as a badge of honor and look down at >>> those who desire a simpler language or who do not know the rules >>> as well. Some of that is fair (we see examples in this group of >>> some who not only refuse to learn the rules of the language, but >>> revel in their ignorance). >> >> Take for example C's set of operator precedences. >> >> The one for the ?: operator is particularly obscure, so in an >> expression like one of these: >> >> a + b ? c - d : e * f >> a ? b ? c : d ? e : f : g >> >> then parentheses would be used to make things clearer. (I haven't >> check these are valid, but that is the point; it is hard to see!) > >Some C programmers make it a point to know all the operator >precedences by heart. I don't. I know most of them, but I >occasionally have to look them up. (My method is to look at the >subsection headers in 6.5 "Expressions", and look at the grammar >when I need more detail. Others prefer to use tables.) I generally use parenthesis, to make the intent clear. I also try to avoid code that looks like a submission to the obfuscated code contest. Something like Duff's device is clever, but if the next person to maintain the code has to learn esoterica to support it, a better solution should be found. > >> But would shouldn't people be expected to learn the rules? Why is it >> OK to 'revel' in not knowing the basics here, but not when unnecessary >> UBs are involved where rules are harder and which depend on runtime >> inputs? > >There's nothing wrong with adding parentheses to make an expression >clearer. It doesn't imply an unwillingness to learn the rules, >just consideration for one's audience. Indeed. Maintainability is a keystone of quality code.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-12 19:48 -0700 |
| Message-ID | <86tssckos7.fsf@linuxsc.com> |
| In reply to | #398815 |
Bart <bc@freeuk.com> writes: [.. I am cutting 100ish lines as they don't bear on my response ..] > Take for example C's set of operator precedences. > > The one for the ?: operator is particularly obscure, so in an > expression like one of these: > > a + b ? c - d : e * f > a ? b ? c : d ? e : f : g > > then parentheses would be used to make things clearer. (I haven't > check these are valid, but that is the point; it is hard to see!) > > But would shouldn't people be expected to learn the rules? Why is it > OK to 'revel' in not knowing the basics here, but not when unnecessary > UBs are involved where rules are harder and which depend on runtime > inputs? If you want people to take you seriously, you need to find more compelling examples. I am both familiar with and comfortable with the syntax of C expressions, and even I would never write such expressions as the two shown above. These lines look like they were written by someone in junior high school (or these days, probably elementary school). Whether you mean to or not, this example gives the impression of offering a strawman argument, and it's only natural for people to react to that by dismissing your comments, or even dismissing them altogether. Is that what you want? To be dismissed? Or do you hope to actually communicate with people? If so I recommend looking for a better framing of your views and ideas.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-13 12:48 +0100 |
| Message-ID | <10u1oem$2lcvh$2@dont-email.me> |
| In reply to | #398840 |
On 13/05/2026 03:48, Tim Rentsch wrote: > Bart <bc@freeuk.com> writes: > > [.. I am cutting 100ish lines as they don't bear on my response ..] > >> Take for example C's set of operator precedences. >> >> The one for the ?: operator is particularly obscure, so in an >> expression like one of these: >> >> a + b ? c - d : e * f >> a ? b ? c : d ? e : f : g >> >> then parentheses would be used to make things clearer. (I haven't >> check these are valid, but that is the point; it is hard to see!) >> >> But would shouldn't people be expected to learn the rules? Why is it >> OK to 'revel' in not knowing the basics here, but not when unnecessary >> UBs are involved where rules are harder and which depend on runtime >> inputs? > > If you want people to take you seriously, you need to find more > compelling examples. I am both familiar with and comfortable with > the syntax of C expressions, and even I would never write such > expressions as the two shown above. No? I actually had your posted examples in mind. I can't remember you using parentheses. I can remember you not being sympathetic to readers of your code and expected them to be as familiar with precedence as you are. > These lines look like they > were written by someone in junior high school (or these days, > probably elementary school). The lines are not meant to mean anything, just sequences of terms and operators. You can think of them as exercises where you add parentheses to make them unambiguous. A bit like adding punctuation here: "that that is is that that is not is not is that it it is" > Whether you mean to or not, this > example gives the impression of offering a strawman argument, and > it's only natural for people to react to that by dismissing your > comments, or even dismissing them altogether. Is that what you > want? To be dismissed? Or do you hope to actually communicate > with people? If so I recommend looking for a better framing of > your views and ideas. Now this is getting silly. Can no one here engage in a civil discussion without reducing to insults and casting aspersions?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-13 05:26 -0700 |
| Message-ID | <865x4rlclh.fsf@linuxsc.com> |
| In reply to | #398864 |
Bart <bc@freeuk.com> writes: > On 13/05/2026 03:48, Tim Rentsch wrote: > >> Bart <bc@freeuk.com> writes: >> >> [.. I am cutting 100ish lines as they don't bear on my response ..] >> >>> Take for example C's set of operator precedences. >>> >>> The one for the ?: operator is particularly obscure, so in an >>> expression like one of these: >>> >>> a + b ? c - d : e * f >>> a ? b ? c : d ? e : f : g >>> >>> then parentheses would be used to make things clearer. (I haven't >>> check these are valid, but that is the point; it is hard to see!) >>> >>> But would shouldn't people be expected to learn the rules? Why is it >>> OK to 'revel' in not knowing the basics here, but not when unnecessary >>> UBs are involved where rules are harder and which depend on runtime >>> inputs? >> >> If you want people to take you seriously, you need to find more >> compelling examples. I am both familiar with and comfortable with >> the syntax of C expressions, and even I would never write such >> expressions as the two shown above. > > No? I actually had your posted examples in mind. I can't remember you > using parentheses. I can remember you not being sympathetic to readers > of your code and expected them to be as familiar with precedence as > you are. > > >> These lines look like they >> were written by someone in junior high school (or these days, >> probably elementary school). > > The lines are not meant to mean anything, just sequences of terms and > operators. You can think of them as exercises where you add > parentheses to make them unambiguous. > > A bit like adding punctuation here: > > "that that is is that that is not is not is that it it is" > >> Whether you mean to or not, this >> example gives the impression of offering a strawman argument, and >> it's only natural for people to react to that by dismissing your >> comments, or even dismissing them altogether. Is that what you >> want? To be dismissed? Or do you hope to actually communicate >> with people? If so I recommend looking for a better framing of >> your views and ideas. > > Now this is getting silly. Can no one here engage in a civil > discussion without reducing to insults and casting aspersions? I'm sorry my comments weren't of more help to you.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-13 15:07 +0200 |
| Message-ID | <10u1t2n$1l93k$17@dont-email.me> |
| In reply to | #398864 |
On 2026-05-13 13:48, Bart wrote: >> Bart <bc@freeuk.com> writes: >>> >>> The one for the ?: operator is particularly obscure, so in an >>> expression like one of these: >>> >>> a + b ? c - d : e * f >>> a ? b ? c : d ? e : f : g >>> >>> [...] > > The lines are not meant to mean anything, just sequences of terms and > operators. You can think of them as exercises where you add parentheses > to make them unambiguous. You have a misconception. - Above expressions *are* unambiguous! You may have a fuzzy relation to an ambiguous 'if' statements in mind, where you can have a "dangling else" situation in cases where there's fewer 'else' branches (than 'if'/"then" branches) in some code. - But notice that this is not the case with ternary conditional expressions where you will generally have "saturated" '?' ':' pairs, and thus no ambiguities, inherently. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-17 20:43 -0400 |
| Message-ID | <10udnc7$1u27b$1@dont-email.me> |
| In reply to | #398864 |
On 2026-05-13 13:48, Bart wrote: >> Bart <bc@freeuk.com> writes: >>> >>> The one for the ?: operator is particularly obscure, so in an >>> expression like one of these: >>> >>> a + b ? c - d : e * f >>> a ? b ? c : d ? e : f : g >>> >>> [...] > > The lines are not meant to mean anything, just sequences of terms and > operators. You can think of them as exercises where you add parentheses > to make them unambiguous. What I think you mean is that the parenthesis help those who are unfamiliar with the relevant rules understand what those rules already unambiguously require.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-13 12:16 +0200 |
| Message-ID | <10u1j2h$1l93l$31@dont-email.me> |
| In reply to | #398815 |
On 2026-05-12 16:33, Bart wrote:
>> [...]
>
> Take for example C's set of operator precedences.
>
> The one for the ?: operator is particularly obscure, so in an expression
> like one of these:
>
> a + b ? c - d : e * f
> a ? b ? c : d ? e : f : g
>
> then parentheses would be used to make things clearer. (I haven't check
> these are valid, but that is the point; it is hard to see!)
What has that example to do with ["obscure"] _operator precedence_?
Ternary conditionals are actually expressions that are sensibly
defined in "C" (i.e. concerning their precedence ranking).
a + b ? c - d
: e * f
a ?
b ? c
: d ? e
: f
: g
For complex expressions you can, as a *responsible* programmer, use
various means to not (not deliberately) write obfuscated expressions;
you can indent code, use parentheses[*], or you can decompose it to
(semantic or technical) identified sub-units.
[*] Parentheses would IMO make your layout in your example above not
in any way better, just yet more overloaded. (So forcing parenthesis
[in "your language"] is certainly addressing the wrong problem here.)
Your complaint, as so often, fails to work on so many levels. It
tells, yet again, more about you than about the "C" language.
>
> But would shouldn't people be expected to learn the rules?
Programmers should certainly learn, know, apply, and obey the rules.
(If you don't understand that you may try to transform that truism
to your "car example".)
Janis
PS: There *is* a specific issue in C's operator precedence ranking
but it's not the ternary conditional.
> [...]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-13 13:20 +0100 |
| Message-ID | <10u1qan$2lcvh$3@dont-email.me> |
| In reply to | #398855 |
On 13/05/2026 11:16, Janis Papanagnou wrote: > On 2026-05-12 16:33, Bart wrote: >>> [...] >> >> Take for example C's set of operator precedences. >> >> The one for the ?: operator is particularly obscure, so in an >> expression like one of these: >> >> a + b ? c - d : e * f >> a ? b ? c : d ? e : f : g >> >> then parentheses would be used to make things clearer. (I haven't >> check these are valid, but that is the point; it is hard to see!) > > What has that example to do with ["obscure"] _operator precedence_? > > Ternary conditionals are actually expressions that are sensibly > defined in "C" (i.e. concerning their precedence ranking). > > a + b ? c - d > : e * f > > a ? > b ? c > : d ? e > : f > : g > > For complex expressions you can, as a *responsible* programmer, use > various means to not (not deliberately) write obfuscated expressions; > you can indent code, use parentheses[*], or you can decompose it to > (semantic or technical) identified sub-units. /I/ might do that; how about everyone else? A random quote from Hacker News: 'I once asked my college professor about operator precedence in C. He had been writing C code in industry for decades. "I have no idea" he told me." From a reply further downthread: "As a young egotist I would often omit parens in complicated C expressions. I did this intentionally and in a very self-satisfied way - writing multi-line conditionals and lining them up neatly without parens with a metaphorical flourish of my pen. Then one day, chasing a hard-to-find bug, I realised it had happened because I'd mixed up the precedence of && and || in a long conditional. I was an idiot. Since then I've made a point of reminding myself that I know nothing and that there's nothing to be gained from pretending I do, and putting parens in everywhere." (https://news.ycombinator.com/item?id=22482223) > [*] Parentheses would IMO make your layout in your example above not > in any way better, Yet they are needed in Algol68, apparently your favourite language. > just yet more overloaded. (So forcing parenthesis > [in "your language"] is certainly addressing the wrong problem here.) > > Your complaint, as so often, fails to work on so many levels. It > tells, yet again, more about you than about the "C" language. Yeah, like I'm the only person to have ever complained about this! Could C operator precedence levels have been done better: Yes or No? By replying No, you suggest they are absolutely perfect. By repying Yes, you admit they might have some issues, but it's OK, you can work around them (you and 100M other people across half a century). But instead, you decide to insult me. >> >> But would shouldn't people be expected to learn the rules? > > Programmers should certainly learn, know, apply, and obey the rules. > > (If you don't understand that you may try to transform that truism > to your "car example".) > > Janis > > PS: There *is* a specific issue in C's operator precedence ranking > but it's not the ternary conditional. There are lots of issues: * There are too many * == != have a different precedence from < <= >= >. Why? Which one is higher? How would you make use of this? * | & ^ have different levels for reasons that are unclear. Again, why? What possible advantage does this have? * Ones like << and >>, which scale values in the same was as * and /, have a completely different level. * In particular, << and >> have a lower precedence than +, so that a << 3 + b is actually parsed as a << (3 + b) rather than (a << 3) + b. I don't a list in front of me so can tell you off-hand what else there is. In the case of ?: I find it bizarre that a 3-way operator it classed amongst the binary operators anyway/.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-13 14:31 +0000 |
| Message-ID | <10u21v6$ev2$1@reader1.panix.com> |
| In reply to | #398855 |
In article <10u1j2h$1l93l$31@dont-email.me>, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >On 2026-05-12 16:33, Bart wrote: >> [snip] >> But would shouldn't people be expected to learn the rules? > >Programmers should certainly learn, know, apply, and obey the rules. > >(If you don't understand that you may try to transform that truism >to your "car example".) Programmers _should_ absolutely learn the rules. But in C, there are many of them, and some of them are deceptively subtle. _A_ rule that programmers can remember quite easily, however, is that parenthesis generally carry very high precedence, and so when it doubt, wrapping something in paren's can aid understanding (for the programmer and the maintainer). The key is to find balance between extreme terseness and extreme verbosity, both of which can feel obfuscating. There was a time when I knew and had memorized the precedence of all operators in C. I remember most, but have forgotten some that I use less frequently; I suspect many programmers are in the same (or a similar) situation. If I am writing code and can not immediately remember the precedence of some operator in some expression, I apply parentheses. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-13 17:16 +0200 |
| Message-ID | <10u24l5$2oaav$1@dont-email.me> |
| In reply to | #398878 |
On 13/05/2026 16:31, Dan Cross wrote: > In article <10u1j2h$1l93l$31@dont-email.me>, > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >> On 2026-05-12 16:33, Bart wrote: >>> [snip] >>> But would shouldn't people be expected to learn the rules? >> >> Programmers should certainly learn, know, apply, and obey the rules. >> >> (If you don't understand that you may try to transform that truism >> to your "car example".) > > Programmers _should_ absolutely learn the rules. But in C, > there are many of them, and some of them are deceptively subtle. > > _A_ rule that programmers can remember quite easily, however, > is that parenthesis generally carry very high precedence, and > so when it doubt, wrapping something in paren's can aid > understanding (for the programmer and the maintainer). The key > is to find balance between extreme terseness and extreme > verbosity, both of which can feel obfuscating. > > There was a time when I knew and had memorized the precedence of > all operators in C. I remember most, but have forgotten some > that I use less frequently; I suspect many programmers are in > the same (or a similar) situation. If I am writing code and can > not immediately remember the precedence of some operator in some > expression, I apply parentheses. > I don't think it is necessary to /learn/ all the rules of a language - but it is necessary to be aware of them, and to know how well you know them. It's fine not to be sure of all the precedence rules in a language (and some languages have many more operators than C, or stranger precedence rules). You only need to know the ones you rely on regularly, and the ones you have to read regularly. If you occasionally come across something different, then you can look it up. There's no point in filling your head with knowledge that you almost never need. So there is usually no need to know the precedence rules for mixing relational operators, shift operators and bitwise and/or operators, or whatever, if you put parentheses in your own code or split the complex expression into multiple variables. (With the caveat that you mentioned earlier that both too few and too many parentheses make code harder to understand.) But you might have to understand code written which relies on more of the details - you need to be aware of what you know, and what you have to look up, in order to understand the code. The risk comes not from ignorance of the precedence rules, but from thinking you know them when you have misremembered them. Self-awareness of your own knowledge, along with convenient and reliable references, is vital.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-13 15:52 +0000 |
| Message-ID | <10u26oi$t9e$2@reader1.panix.com> |
| In reply to | #398885 |
In article <10u24l5$2oaav$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 13/05/2026 16:31, Dan Cross wrote: >> In article <10u1j2h$1l93l$31@dont-email.me>, >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>> On 2026-05-12 16:33, Bart wrote: >>>> [snip] >>>> But would shouldn't people be expected to learn the rules? >>> >>> Programmers should certainly learn, know, apply, and obey the rules. >>> >>> (If you don't understand that you may try to transform that truism >>> to your "car example".) >> >> Programmers _should_ absolutely learn the rules. But in C, >> there are many of them, and some of them are deceptively subtle. >> >> _A_ rule that programmers can remember quite easily, however, >> is that parenthesis generally carry very high precedence, and >> so when it doubt, wrapping something in paren's can aid >> understanding (for the programmer and the maintainer). The key >> is to find balance between extreme terseness and extreme >> verbosity, both of which can feel obfuscating. >> >> There was a time when I knew and had memorized the precedence of >> all operators in C. I remember most, but have forgotten some >> that I use less frequently; I suspect many programmers are in >> the same (or a similar) situation. If I am writing code and can >> not immediately remember the precedence of some operator in some >> expression, I apply parentheses. > >I don't think it is necessary to /learn/ all the rules of a language - >but it is necessary to be aware of them, and to know how well you know >them. It's fine not to be sure of all the precedence rules in a >language (and some languages have many more operators than C, or >stranger precedence rules). You only need to know the ones you rely on >regularly, and the ones you have to read regularly. If you occasionally >come across something different, then you can look it up. There's no >point in filling your head with knowledge that you almost never need. > >So there is usually no need to know the precedence rules for mixing >relational operators, shift operators and bitwise and/or operators, or >whatever, if you put parentheses in your own code or split the complex >expression into multiple variables. (With the caveat that you mentioned >earlier that both too few and too many parentheses make code harder to >understand.) > >But you might have to understand code written which relies on more of >the details - you need to be aware of what you know, and what you have >to look up, in order to understand the code. The risk comes not from >ignorance of the precedence rules, but from thinking you know them when >you have misremembered them. Self-awareness of your own knowledge, >along with convenient and reliable references, is vital. Yes, I agree. The key is knowing when it's time to go to look at a reference. I like the way you put it. I might go a bit further and say that it's fine not to know every rule, but there's a qualitative difference between acknowledging that and know that easy access to a reliable reference is useful, and steadfasty, refusing to learn the rules because one considers them poor to begin with. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-14 11:43 +0200 |
| Message-ID | <10u45go$28j9$2@dont-email.me> |
| In reply to | #398889 |
On 13/05/2026 17:52, Dan Cross wrote: > In article <10u24l5$2oaav$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> On 13/05/2026 16:31, Dan Cross wrote: >>> In article <10u1j2h$1l93l$31@dont-email.me>, >>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>>> On 2026-05-12 16:33, Bart wrote: >>>>> [snip] >>>>> But would shouldn't people be expected to learn the rules? >>>> >>>> Programmers should certainly learn, know, apply, and obey the rules. >>>> >>>> (If you don't understand that you may try to transform that truism >>>> to your "car example".) >>> >>> Programmers _should_ absolutely learn the rules. But in C, >>> there are many of them, and some of them are deceptively subtle. >>> >>> _A_ rule that programmers can remember quite easily, however, >>> is that parenthesis generally carry very high precedence, and >>> so when it doubt, wrapping something in paren's can aid >>> understanding (for the programmer and the maintainer). The key >>> is to find balance between extreme terseness and extreme >>> verbosity, both of which can feel obfuscating. >>> >>> There was a time when I knew and had memorized the precedence of >>> all operators in C. I remember most, but have forgotten some >>> that I use less frequently; I suspect many programmers are in >>> the same (or a similar) situation. If I am writing code and can >>> not immediately remember the precedence of some operator in some >>> expression, I apply parentheses. >> >> I don't think it is necessary to /learn/ all the rules of a language - >> but it is necessary to be aware of them, and to know how well you know >> them. It's fine not to be sure of all the precedence rules in a >> language (and some languages have many more operators than C, or >> stranger precedence rules). You only need to know the ones you rely on >> regularly, and the ones you have to read regularly. If you occasionally >> come across something different, then you can look it up. There's no >> point in filling your head with knowledge that you almost never need. >> >> So there is usually no need to know the precedence rules for mixing >> relational operators, shift operators and bitwise and/or operators, or >> whatever, if you put parentheses in your own code or split the complex >> expression into multiple variables. (With the caveat that you mentioned >> earlier that both too few and too many parentheses make code harder to >> understand.) >> >> But you might have to understand code written which relies on more of >> the details - you need to be aware of what you know, and what you have >> to look up, in order to understand the code. The risk comes not from >> ignorance of the precedence rules, but from thinking you know them when >> you have misremembered them. Self-awareness of your own knowledge, >> along with convenient and reliable references, is vital. > > Yes, I agree. The key is knowing when it's time to go to look > at a reference. > > I like the way you put it. > > I might go a bit further and say that it's fine not to know > every rule, but there's a qualitative difference between > acknowledging that and know that easy access to a reliable > reference is useful, and steadfasty, refusing to learn the rules > because one considers them poor to begin with. > Of course. There is also often a dangerous point in learning anything (not just a programming language), where you have learned enough to think you have "grokked" the subject but don't yet realise how little you actually know. You have to pass that hump in the learning curve as fast as you can - some people get stuck there, and that's when they start believing things like "C is portable assembly".
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-14 02:59 +0200 |
| Message-ID | <10u36pv$1l93k$18@dont-email.me> |
| In reply to | #398878 |
On 2026-05-13 16:31, Dan Cross wrote: > In article <10u1j2h$1l93l$31@dont-email.me>, > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >> On 2026-05-12 16:33, Bart wrote: >>> [snip] >>> But would shouldn't people be expected to learn the rules? >> >> Programmers should certainly learn, know, apply, and obey the rules. >> >> (If you don't understand that you may try to transform that truism >> to your "car example".) > > Programmers _should_ absolutely learn the rules. But in C, > there are many of them, and some of them are deceptively subtle. We agreed. > > _A_ rule that programmers can remember quite easily, however, > is that parenthesis generally carry very high precedence, and > so when it doubt, wrapping something in paren's can aid > understanding (for the programmer and the maintainer). I agree. > The key > is to find balance between extreme terseness and extreme > verbosity, both of which can feel obfuscating. First, don't forget that there was no problem with precedence existing in Bart's post; it was just an overloaded and badly formatted composition in an example of ternary conditionals. Now back to your statement. The point is that precedence rules vary between programming languages. Folks can usually rely on the precedence of * and / compared to + and - . But being a computer scientist there's also other characteristics one can assume with respect to typical types; but weighed against the design decisions of the language. For example I can live with the difference of Pascal's and C's operator precedence, even that they differ. But it's harder to live with a discrepancy, a mis-ranking of a class of operators in "C". (I noticed that already when I read K&R some time around 1985, but I first saw that "officially" acknowledged not too long ago when someone posted a link to a paper from, IIRC, some time in the 1990's written by one of the authors of "C".) - And that discrepancy detail in C's precedence ranking was actually the only reason for me looking "regularly" into the precedence table of my K&R. (The point is that - with the exception of & ^ | - the ranking makes perfectly sense and should be easily usable without doubt by a concept-knowing programmer. But note that, historically, a sort of "rationale" can be formulated for the discrepancy to justify the given choice in context of specifically "C". But still remember the "official" acknowledgement of an issue here.) > > There was a time when I knew and had memorized the precedence of > all operators in C. I remember most, but have forgotten some > that I use less frequently; I suspect many programmers are in > the same (or a similar) situation. If I am writing code and can > not immediately remember the precedence of some operator in some > expression, I apply parentheses. Depending on the complexity of expressions that is a sensible approach. (I do that as well were I think that it aids clarity.) Janis
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-14 01:39 +0000 |
| Message-ID | <10u3941$qtp$1@reader1.panix.com> |
| In reply to | #398916 |
In article <10u36pv$1l93k$18@dont-email.me>, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >On 2026-05-13 16:31, Dan Cross wrote: >> In article <10u1j2h$1l93l$31@dont-email.me>, >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>> On 2026-05-12 16:33, Bart wrote: >>>> [snip] >>>> But would shouldn't people be expected to learn the rules? >>> >>> Programmers should certainly learn, know, apply, and obey the rules. >>> >>> (If you don't understand that you may try to transform that truism >>> to your "car example".) >> >> Programmers _should_ absolutely learn the rules. But in C, >> there are many of them, and some of them are deceptively subtle. > >We agreed. > >> _A_ rule that programmers can remember quite easily, however, >> is that parenthesis generally carry very high precedence, and >> so when it doubt, wrapping something in paren's can aid >> understanding (for the programmer and the maintainer). > >I agree. > >> The key >> is to find balance between extreme terseness and extreme >> verbosity, both of which can feel obfuscating. > >First, don't forget that there was no problem with precedence >existing in Bart's post; it was just an overloaded and badly >formatted composition in an example of ternary conditionals. I didn't say that there was. In fact and intent, my post had no basis in Bart's snippet at all, but in looking at it now, I think that code is an example of being _too_ terse. >Now back to your statement. The point is that precedence rules >vary between programming languages. Folks can usually rely on >the precedence of * and / compared to + and - . I can think of at least two languages where you could not, but yeah, that is usually true. >But being a >computer scientist there's also other characteristics one can >assume with respect to typical types; but weighed against the >design decisions of the language. For example I can live with >the difference of Pascal's and C's operator precedence, even >that they differ. But it's harder to live with a discrepancy, >a mis-ranking of a class of operators in "C". (I noticed that >already when I read K&R some time around 1985, but I first saw >that "officially" acknowledged not too long ago when someone >posted a link to a paper from, IIRC, some time in the 1990's >written by one of the authors of "C".) - And that discrepancy >detail in C's precedence ranking was actually the only reason >for me looking "regularly" into the precedence table of my K&R. >(The point is that - with the exception of & ^ | - the ranking >makes perfectly sense and should be easily usable without doubt >by a concept-knowing programmer. But note that, historically, >a sort of "rationale" can be formulated for the discrepancy to >justify the given choice in context of specifically "C". But >still remember the "official" acknowledgement of an issue here.) I'm not sure what issue you are referring to, but I infer it has to do with shifts and the bit-wise binary operators. I agree; those are a mess. >> There was a time when I knew and had memorized the precedence of >> all operators in C. I remember most, but have forgotten some >> that I use less frequently; I suspect many programmers are in >> the same (or a similar) situation. If I am writing code and can >> not immediately remember the precedence of some operator in some >> expression, I apply parentheses. > >Depending on the complexity of expressions that is a sensible >approach. (I do that as well were I think that it aids clarity.) Yes. Also, sometimes projects have code standards that must be obeyed that mandate use (or absence) of parenthesis; sometimes a consensus among more than one programmer is required. - Dan C.
[toc] | [prev] | [next] | [standalone]
Page 12 of 37 — ← Prev page 1 … 10 11 [12] 13 14 … 37 Next page →
Back to top | Article view | comp.lang.c
csiph-web