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 13 of 37 — ← Prev page 1 … 11 12 [13] 14 15 … 37 Next page →
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-14 03:57 +0200 |
| Message-ID | <10u3a6a$34b89$3@dont-email.me> |
| In reply to | #398918 |
On 2026-05-14 03:39, Dan Cross wrote: > In article <10u36pv$1l93k$18@dont-email.me>, > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > >> 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. Are you thinking about languages like Algol 68 where you can explicitly define and re-define operator precedence, or do you mean languages where they made just bad design decisions? Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-14 11:49 +0200 |
| Message-ID | <10u45rj$28j9$3@dont-email.me> |
| In reply to | #398922 |
On 14/05/2026 03:57, Janis Papanagnou wrote: > On 2026-05-14 03:39, Dan Cross wrote: >> In article <10u36pv$1l93k$18@dont-email.me>, >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >> >>> 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. > > Are you thinking about languages like Algol 68 where you > can explicitly define and re-define operator precedence, > or do you mean languages where they made just bad design > decisions? > > Janis > <OT> I believe APL does not have operator precedences, though I have never written more than a one-line program in the language. And in Forth, operators are all post-fix, so there are no precedences there either. But I'm curious which two languages Dan was referring to. (My guess is that APL was one of them, but I don't know the other.)
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-14 10:57 +0000 |
| Message-ID | <10u49qj$mco$1@reader1.panix.com> |
| In reply to | #398936 |
In article <10u45rj$28j9$3@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 14/05/2026 03:57, Janis Papanagnou wrote: >> On 2026-05-14 03:39, Dan Cross wrote: >>> In article <10u36pv$1l93k$18@dont-email.me>, >>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >>> >>>> 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. >> >> Are you thinking about languages like Algol 68 where you >> can explicitly define and re-define operator precedence, >> or do you mean languages where they made just bad design >> decisions? >> >> Janis >> > ><OT> > >I believe APL does not have operator precedences, though I have never >written more than a one-line program in the language. > >And in Forth, operators are all post-fix, so there are no precedences >there either. > >But I'm curious which two languages Dan was referring to. (My guess is >that APL was one of them, but I don't know the other.) APL is an example, yes. It does have some notion of precedence, but arithmetic expressions do not follow the usual rules of mathematics. Precedence is really only a concern for infix notations; langauges like Forth, PostScript, or members of the Lisp family are not infix languages, so it doesn't matter; in Lisp, for instance, one may think of a program as S-expressions as a textual representation of an abstract syntax tree; thus, programmers work directly in terms of the AST. Smalltalk is another language that does not have operator that exhibit precedence in the manner one is likely accustomed to in the usual sense. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-14 10:22 +0000 |
| Message-ID | <10u47o8$jkv$1@reader1.panix.com> |
| In reply to | #398922 |
In article <10u3a6a$34b89$3@dont-email.me>, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >On 2026-05-14 03:39, Dan Cross wrote: >> In article <10u36pv$1l93k$18@dont-email.me>, >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >> >>> 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. > >Are you thinking about languages like Algol 68 where you >can explicitly define and re-define operator precedence, >or do you mean languages where they made just bad design >decisions? No. troff and the 7th Edition Unix assembler (the latter has infix expression syntax for the calculation of immediate values and so on, but that is parsed left to right, and does not follow the usual rules of arithmetic). - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-14 12:32 +0100 |
| Message-ID | <10u4bs5$9ifk$2@dont-email.me> |
| In reply to | #398916 |
On 14/05/2026 01:59, Janis Papanagnou 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. > (The point is that - with the exception of & ^ | - the ranking > makes perfectly sense It doesn't make sense even then; here are the remaining groups for binary ops from high to low: (* / %) (+ -) (<< >>) (< <= >= >) (== !==) (&&) (||) (=) Why are the shift operators at that spot? This causes chaos in expressions like 'a << 3 + b' which are parsed as 'a << (3 + b)'. Why are == and != lower precedence than the other compare operators? In which circumstances would that be an advantage? This is just a pointless extra level, as such usage would be so unusual that you'd use parentheses anyway. TBF, while other languages may not have as many levels, they also have questionable choices, because there are no standards. At best it is generally agreed that there are 3 groups (4 including assignment) again arranged from high to low: 1 School arithmetic which everyone knows 2 Comparisons 3 Logical (and, or) 4 (Assignment) These should be intuitive, all that's left is the ordering within group 1 and group 3, and also where these extra ops need to go: << >> & | ^ In the case if C, it also decided that ?: belongs in this chart of /binary/ operators. (I supposed you can consider each of ? and : as a binary operator...)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-14 16:11 -0700 |
| Message-ID | <10u5krf$uo0d$2@kst.eternal-september.org> |
| In reply to | #398942 |
Bart <bc@freeuk.com> writes:
> On 14/05/2026 01:59, Janis Papanagnou wrote:
[...]
>> (The point is that - with the exception of & ^ | - the ranking
>> makes perfectly sense
>
> It doesn't make sense even then; here are the remaining groups for
> binary ops from high to low:
>
> (* / %) (+ -) (<< >>) (< <= >= >) (== !==) (&&) (||) (=)
>
> Why are the shift operators at that spot? This causes chaos in
> expressions like 'a << 3 + b' which are parsed as 'a << (3 + b)'.
I've never heard anyone claim that C's operator precedence rules are
ideal. They aren't. But they can't be changed without breaking
existing code, so there's little point in complaining about it.
Someone could probably make an argument that the existing precedences
are more sensible than any alternatives, but that doesn't really
matter.
> Why are == and != lower precedence than the other compare operators?
> In which circumstances would that be an advantage? This is just a
> pointless extra level, as such usage would be so unusual that you'd
> use parentheses anyway.
I suggest that it doesn't matter why. It is what it is. And yes,
I'd add parentheses in the unlikely event that I needed to write
an expression that uses both equality and comparison operators
(unless I were writing deliberately obfuscated code, which I've
been known to do).
> TBF, while other languages may not have as many levels, they also have
> questionable choices, because there are no standards.
Plenty of other languages have standards. I'm not aware of any
correlation between whether a language has a written standard and
how reasonable its operator precedence rules are.
> At best it is generally agreed that there are 3 groups (4 including
> assignment) again arranged from high to low:
Agreed by whom?
> 1 School arithmetic which everyone knows
>
> 2 Comparisons
>
> 3 Logical (and, or)
>
> 4 (Assignment)
>
> These should be intuitive, all that's left is the ordering within
> group 1 and group 3, and also where these extra ops need to go:
>
> << >> & | ^
>
> In the case if C, it also decided that ?: belongs in this chart of
> /binary/ operators. (I supposed you can consider each of ? and : as a
> binary operator...)
I don't know what chart you're referring to. There is no such chart
in the C standard; the precedence is defined implicitly by the
grammar rules. K&R2 Table 2.1 is a chart showing the precedence
and associativity of C's operators. It includes unary, binary,
and ternary operators.
?: is a ternary operator. It is not in any sense a binary operator.
If you've seen a table that implies it's a binary operator, that
table is wrong (or you've misinterpreted it).
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-15 01:12 +0100 |
| Message-ID | <10u5ocr$1618i$1@dont-email.me> |
| In reply to | #398972 |
On 15/05/2026 00:11, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 14/05/2026 01:59, Janis Papanagnou wrote:
> [...]
>>> (The point is that - with the exception of & ^ | - the ranking
>>> makes perfectly sense
>>
>> It doesn't make sense even then; here are the remaining groups for
>> binary ops from high to low:
>>
>> (* / %) (+ -) (<< >>) (< <= >= >) (== !==) (&&) (||) (=)
>>
>> Why are the shift operators at that spot? This causes chaos in
>> expressions like 'a << 3 + b' which are parsed as 'a << (3 + b)'.
>
> I've never heard anyone claim that C's operator precedence rules are
> ideal. They aren't. But they can't be changed without breaking
> existing code, so there's little point in complaining about it.
I was replying to the claim that they made 'perfect sense' aside from '&
^ |'
>> TBF, while other languages may not have as many levels, they also have
>> questionable choices, because there are no standards.
>
> Plenty of other languages have standards.
I mean cross-language or real-world standards for operator precedences.
There are de-facto ones for operators that everyone used like '* / + -',
and also for '**' (exponentiation) even if that is an implied op in
mathematical notation.
In the computing world, logical 'add' before logical 'or' seems to be
common.
Those form groups 1 and 3 of my list below. Then common sense demands
that comparisons must be group 2, otherwise:
a + b == 0 might parsed as a + (b == 2)
a == b && c == d might be parsed as a == (b && c) == d
The fourth group is assignment. If that was any else other than the
lowest level, then:
a = b + c might be parsed as (a = b) + c
a = b && c might be parsed as (a = b) && c
a = b == c might be parsed as (a = b) == c
depending on exactly where. None is desirable. In this case, C does the
right thing anyway so no need to disagree!
>> At best it is generally agreed that there are 3 groups (4 including
>> assignment) again arranged from high to low:
>
> Agreed by whom?
>
>> 1 School arithmetic which everyone knows
>>
>> 2 Comparisons
>>
>> 3 Logical (and, or)
>>
>> 4 (Assignment)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-15 02:30 +0200 |
| Message-ID | <10u5pf9$34b89$8@dont-email.me> |
| In reply to | #398972 |
On 2026-05-15 01:11, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>
>> Why are == and != lower precedence than the other compare operators?
To prevent forcing parenthesis (which would make C-programs,
which are already inherently overloaded with a plethora of (),
{} and [], yet more unreadable).
>> In which circumstances would that be an advantage? This is just a
>> pointless extra level, as such usage would be so unusual that you'd
>> use parentheses anyway.
Equal and unequal are basically more universal operators than
the other four types of value comparisons.[*] You can observe
a hierarchy of types (reflected also in conditionals) where
at the upper end you want a boolean predicate.
bool x bool -> bool && and || arranged per logic convention
type x type -> bool ==, !=, and then (see [*]) <, <=, >, >=
type x type -> type various types including math convention
And some specific cases in "C", like ++x and x++, which need
some attention.
Unaries are mostly not (or at least rarely) a problem. But...
exponentiation needs attention, especially where unaries are
involved in expressions. (Sadly there's differences here.)
[*] I'm not considering that languages my impose an ordering in
'boolean' values. As universal fundamental abstract type 'true'
and 'false' are unordered and need no ordering. It makes sense
to have classes more differentiated than thrown together and
thereby requiring lots of parentheses to fix things again. It's
a convenience based on common conventions and logical models.
>
> I suggest that it doesn't matter why. It is what it is. And yes,
> I'd add parentheses in the unlikely event that I needed to write
> an expression that uses both equality and comparison operators
> (unless I were writing deliberately obfuscated code, which I've
> been known to do).
It's not "obfuscated", IMHO, if you have the conceptual model I
presented in mind. But of course you could also use parenthesis
to emphasize things, or use different spacing; I use all means
depending on context and complexity of the expressions.
>> [...]
>>
>> These should be intuitive, all that's left is the ordering within
>> group 1 and group 3, and also where these extra ops need to go:
>>
>> << >> & | ^
These are basically in the "value-operators" type x type -> type
class, though the former two operators are asymmetric; they work
like
type1 x type2 -> type1
so they are justified an own class.[**] It makes sense where "C"
has them defined.
[**] Yes, the arguments make technically both use of the same
'int' type but they are semantically in different classes.
The problem is with the latter three, & | ^ ; they are (typically)
used with arithmetic value types, but they are sorted in after the
comparison types.[***] - I cannot do anything about that and want
to use parenthesis here, not (not primarily) for clarity, but to
prevent computational errors in the first place.
[***] Obviously the problem arose historically from using boolean
operations through bit-sets occasionally as substitute for 'bool'.
A misfortune of a coincidence of the language "flexibility" with
its fuzziness of not separating 'bool' from 'int', and habits to
use clever "optimized" coding. (I haven't seen such coding more
recently, though, i.e. not during the past about four decades.
I could imagine that it might play some role still in areas like
controllers-programming, but don't know, to be frank.)
Janis
>> [...]
> [...]
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-15 02:38 +0200 |
| Message-ID | <10u5puh$34b88$3@dont-email.me> |
| In reply to | #398942 |
On 2026-05-14 13:32, Bart wrote: > On 14/05/2026 01:59, Janis Papanagnou wrote: >> [...] > >> (The point is that - with the exception of & ^ | - the ranking >> makes perfectly sense > > It doesn't make sense even then; [...] I acknowledge that it doesn't make sense for you. (Some explanations can be found in a recent posting.) > [...] > > TBF, while other languages may not have as many levels, they also have > questionable choices, because there are no standards. There are common public conventions and conceptual models from the computer science that influence the definitions. Design constraints and goals of specific programming languages may influence details. Beyond that the languages generally define their precedence rules (and these are reflected in the respective language standards). > [...] > > In the case if C, it also decided that ?: belongs in this chart of / > binary/ operators. (I supposed you can consider each of ? and : as a > binary operator...) (Here I'm sure you're imaging things or deliberately making them up.) Janis
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-18 19:48 -0400 |
| Message-ID | <10ug8fn$2skgp$1@dont-email.me> |
| In reply to | #398942 |
On 2026-05-14 13:32, Bart wrote: ... > In the case if C, it also decided that ?: belongs in this chart of / > binary/ operators. (I supposed you can consider each of ? and : as a > binary operator...) When and where was that decided? There's a big difference between putting ?: in a chart along with binary and unary operators (which happened in section 2.12 of the 1st edition of K&R) and putting it in a chart of binary operators. To the best of my knowledge, the latter never happened. Could you please identify where it did?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-19 01:12 +0100 |
| Message-ID | <10ug9sm$2sp0q$1@dont-email.me> |
| In reply to | #399142 |
On 19/05/2026 00:48, James Kuyper wrote: > On 2026-05-14 13:32, Bart wrote: > ... >> In the case if C, it also decided that ?: belongs in this chart of / >> binary/ operators. (I supposed you can consider each of ? and : as a >> binary operator...) > > When and where was that decided? There's a big difference between > putting ?: in a chart along with binary and unary operators (which > happened in section 2.12 of the 1st edition of K&R) and putting it in a > chart of binary operators. To the best of my knowledge, the latter never > happened. Could you please identify where it did? If you read my post again, you'll find that 'this chart' most likely refers to my suggested chart containing those 4 groups I mentioned. That chart contains a set of binary (and infix) operators that also appear in K&R2. I'm saying that whoever put that together in K&R2 decided that ?: belonged in this set. (Personally I don't, as I don't consider a ?:-like feature to be an operator, but even it it was, a 3-way operator is a poor fit when all the others are 2-way.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-18 19:22 -0700 |
| Message-ID | <10ughgg$2v279$1@kst.eternal-september.org> |
| In reply to | #399143 |
Bart <bc@freeuk.com> writes:
[...]
> If you read my post again, you'll find that 'this chart' most likely
> refers to my suggested chart containing those 4 groups I mentioned.
>
> That chart contains a set of binary (and infix) operators that also
> appear in K&R2. I'm saying that whoever put that together in K&R2
> decided that ?: belonged in this set.
The ?: operator, which is a ternary operator, belongs in the set
of operators.
You somehow concluded that ?: was being treated as a binary operator.
It very very clearly is not a binary operator. The chart in K&R2
very very clearly does not imply that it is.
> (Personally I don't, as I don't consider a ?:-like feature to be an
> operator,
It is an operator in C.
> but even it it was, a 3-way operator is a poor fit when all
> the others are 2-way.)
No, not all the others are 2-way.
Are you now saying that you think ?: *should* be a binary (2-way)
operator? (I'm not going to ask how that would work.)
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-19 11:31 +0100 |
| Message-ID | <10uhe6m$36a89$1@dont-email.me> |
| In reply to | #399144 |
On 19/05/2026 03:22, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> If you read my post again, you'll find that 'this chart' most likely
>> refers to my suggested chart containing those 4 groups I mentioned.
>>
>> That chart contains a set of binary (and infix) operators that also
>> appear in K&R2. I'm saying that whoever put that together in K&R2
>> decided that ?: belonged in this set.
>
> The ?: operator, which is a ternary operator, belongs in the set
> of operators.
Do we really want to get this pedantic and discuss the intent of every
single choice of word I've made?
Say I'm talking about this set: "+ - * /", binary/infix operators
(ignore that 3 of them also unary/prefix).
This same set is part of the table of 1/2/3-way 'operators' used in K&R2.
I'd remarked that K&R put the ?: 3-way operator amongst the section of
the table which is full of 2-way ops (with the 1-way ops sharing the top
two tiers) and idly speculated whether the '?' and ':' parts of '?:'
were being treated as though each was a 2-way operator.
> You somehow concluded that ?: was being treated as a binary operator.
> It very very clearly is not a binary operator. The chart in K&R2
> very very clearly does not imply that it is.
>
>> (Personally I don't, as I don't consider a ?:-like feature to be an
>> operator,
>
> It is an operator in C.
>
>> but even it it was, a 3-way operator is a poor fit when all
>> the others are 2-way.)
>
> No, not all the others are 2-way.
>
> Are you now saying that you think ?: *should* be a binary (2-way)
> operator? (I'm not going to ask how that would work.
This is the question *I'm* asking! How does a 3-way operator work in
that set-up? Is it still called 'infix'?
But is seems like nobody is obliged to answer that because the C
standard defines it all as syntax anyway, and just happens to use the
word 'operator' to refer to all the bit of syntax that occur between the
terminals of any expression.
Even though this is a poor fit for those like "[]", "()", "?:" and "(T)".
(FWIW, here is a simplified subset of an informal grammar that applies
to my languages; 'unit' is a statement or expression, but only
expression-like terms are listed:
unit = term {op / ':=' / '..' term}*
term = name
= intconst
= realconst
= charconst
= stringconst
= op term # prefix unary op
= term op # postfix unary op
= term '.' name # member selection
= '(' unit ')'
= term '^' # deref
= '&' term
= term '(' unit|',' ')' # function call
= typespec '(' unit ')' # cast
= term '[' unit|',' ']' # indexing
= term '.' property
= Etc
( {...}* repeats zero or more times; '/' separates choices, as does '=';
a|b means zero or more 'a' separated by b.)
Notice that [], (), pointer deref, casts, and various other bits have
their own productions.
'op' is one of a common pool of operator names. Not all are allowed in
any one context, but that is not specified here; the parser will detect
those that are not appropriate. This is not a formal grammar that can be
used to drive an automatic tool. It is for a human.
BTW here are two more lines:
= '(' unit '|' unit '|' unit ')' # 3-way select
= '(' unit '|' unit|, '|' unit ')' # N-way select
The first is equivalent to C's ?: feature.)
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-05-19 12:21 +0000 |
| Message-ID | <10uhkjm$10o6i$1@paganini.bofh.team> |
| In reply to | #399154 |
Bart <bc@freeuk.com> wrote:
> On 19/05/2026 03:22, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
<snip>
> Say I'm talking about this set: "+ - * /", binary/infix operators
> (ignore that 3 of them also unary/prefix).
>
> This same set is part of the table of 1/2/3-way 'operators' used in K&R2.
>
> I'd remarked that K&R put the ?: 3-way operator amongst the section of
> the table which is full of 2-way ops (with the 1-way ops sharing the top
> two tiers) and idly speculated whether the '?' and ':' parts of '?:'
> were being treated as though each was a 2-way operator.
>
>
>> You somehow concluded that ?: was being treated as a binary operator.
>> It very very clearly is not a binary operator. The chart in K&R2
>> very very clearly does not imply that it is.
>>
>>> (Personally I don't, as I don't consider a ?:-like feature to be an
>>> operator,
>>
>> It is an operator in C.
>>
>>> but even it it was, a 3-way operator is a poor fit when all
>>> the others are 2-way.)
>>
>> No, not all the others are 2-way.
>>
>> Are you now saying that you think ?: *should* be a binary (2-way)
>> operator? (I'm not going to ask how that would work.
>
> This is the question *I'm* asking! How does a 3-way operator work in
> that set-up? Is it still called 'infix'?
<snip>
> Even though this is a poor fit for those like "[]", "()", "?:" and "(T)".
In late sixties there were concept of "operator precedence grammar"
and related parsing technology. Basicaly, I you wanted systematic
way of parsing there was operator precedence or recursive descent,
otherwise it was more or less ad hoc. In operator precedence
grammar most "interesting" things were operators of varying arity.
If you ask "how does it work?", the answer is that parsers using
that where shift-reduce parsers and priorities are used to choose
between shift and reduce actions. People also realised to
operator precedence can be used together with recursive descent,
leading to small and efficient parsers handling rich language.
Operator precedence alone puts restrictions on the language
(but there were languages specially designed to be parsed using
operator precedence), recursive descent alows more general
languages, but gets messy on constructs well handled by operator
precedence. AFAIK first C compiler used combination of operator
precedence and recursive descent, and for some time there was a
belief that correct and full BNF for C was impossible to give or
too messy. Current gramamr only appeared during ANSI process.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-19 14:15 +0100 |
| Message-ID | <10uhnos$38l18$2@dont-email.me> |
| In reply to | #399159 |
On 19/05/2026 13:21, Waldek Hebisch wrote: > Bart <bc@freeuk.com> wrote: >> On 19/05/2026 03:22, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: > <snip> >> Say I'm talking about this set: "+ - * /", binary/infix operators >> (ignore that 3 of them also unary/prefix). >> >> This same set is part of the table of 1/2/3-way 'operators' used in K&R2. >> >> I'd remarked that K&R put the ?: 3-way operator amongst the section of >> the table which is full of 2-way ops (with the 1-way ops sharing the top >> two tiers) and idly speculated whether the '?' and ':' parts of '?:' >> were being treated as though each was a 2-way operator. >> >> >>> You somehow concluded that ?: was being treated as a binary operator. >>> It very very clearly is not a binary operator. The chart in K&R2 >>> very very clearly does not imply that it is. >>> >>>> (Personally I don't, as I don't consider a ?:-like feature to be an >>>> operator, >>> >>> It is an operator in C. >>> >>>> but even it it was, a 3-way operator is a poor fit when all >>>> the others are 2-way.) >>> >>> No, not all the others are 2-way. >>> >>> Are you now saying that you think ?: *should* be a binary (2-way) >>> operator? (I'm not going to ask how that would work. >> >> This is the question *I'm* asking! How does a 3-way operator work in >> that set-up? Is it still called 'infix'? > <snip> >> Even though this is a poor fit for those like "[]", "()", "?:" and "(T)". > > In late sixties there were concept of "operator precedence grammar" > and related parsing technology. Basicaly, I you wanted systematic > way of parsing there was operator precedence or recursive descent, > otherwise it was more or less ad hoc. In operator precedence > grammar most "interesting" things were operators of varying arity. > > If you ask "how does it work?", the answer is that parsers using > that where shift-reduce parsers and priorities are used to choose > between shift and reduce actions. People also realised to > operator precedence can be used together with recursive descent, > leading to small and efficient parsers handling rich language. > Operator precedence alone puts restrictions on the language > (but there were languages specially designed to be parsed using > operator precedence), recursive descent alows more general > languages, but gets messy on constructs well handled by operator > precedence. AFAIK first C compiler used combination of operator > precedence and recursive descent, and for some time there was a > belief that correct and full BNF for C was impossible to give or > too messy. Current gramamr only appeared during ANSI process. I think it's still a little messy! Compare with the example of mine that I gave. Although that off-loads some things to the parser, like precedence, which is notionally table-driven. However I understand the importance of clear presentation. Half of the C grammar reminds me of the 'twisty little passages, all alike' section of Colossal Adventure. Why would they choose such long terms that are so confusedly alike? Note that in C, expression structure has to be handled twice: in the proprocessor, and in the main language.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-19 14:14 -0700 |
| Message-ID | <10uijr6$3hjk0$2@kst.eternal-september.org> |
| In reply to | #399162 |
Bart <bc@freeuk.com> writes:
[...]
> I think it's still a little messy!
Yes, C's expression grammar is a little messy. We're in complete
agreement on that point.
[...]
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-22 21:58 -0700 |
| Message-ID | <86h5nyhgct.fsf@linuxsc.com> |
| In reply to | #399159 |
antispam@fricas.org (Waldek Hebisch) writes: > [...] for some time there was a belief that correct and full BNF > for C was impossible to give or too messy. I find this statement hard to believe. There is nothing especially difficult about a syntax for the C language. There is of course the well-known problem with typedef names, but that has long been understood to be unresolvable in any context-free way (and so cannot be dealt with in BNF). Earlier versions of C (pre-K&R) had other syntax for some constructs, and maybe that was the issue. I'm at a loss to understand how people could have thought a BNF for C, for the post K&R version of the language, would be challenging or difficult.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-22 23:23 -0700 |
| Message-ID | <10urh4l$228p5$2@kst.eternal-september.org> |
| In reply to | #399337 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> antispam@fricas.org (Waldek Hebisch) writes:
>> [...] for some time there was a belief that correct and full BNF
>> for C was impossible to give or too messy.
>
> I find this statement hard to believe. There is nothing especially
> difficult about a syntax for the C language. There is of course the
> well-known problem with typedef names, but that has long been
> understood to be unresolvable in any context-free way (and so cannot
> be dealt with in BNF). Earlier versions of C (pre-K&R) had other
> syntax for some constructs, and maybe that was the issue. I'm at a
> loss to understand how people could have thought a BNF for C, for
> the post K&R version of the language, would be challenging or
> difficult.
I'm having trouble figuring out what you mean here. You acknowledge
that typedefs make a full BNF grammar for C impossible, and then
you say that it's not challenging or difficult.
I'm aware that there are workarounds, basically treating typedef
names a context-dependent keywords.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-23 00:09 -0700 |
| Message-ID | <864ijyha9n.fsf@linuxsc.com> |
| In reply to | #399342 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> antispam@fricas.org (Waldek Hebisch) writes: >> >>> [...] for some time there was a belief that correct and full BNF >>> for C was impossible to give or too messy. >> >> I find this statement hard to believe. There is nothing especially >> difficult about a syntax for the C language. There is of course the >> well-known problem with typedef names, but that has long been >> understood to be unresolvable in any context-free way (and so cannot >> be dealt with in BNF). Earlier versions of C (pre-K&R) had other >> syntax for some constructs, and maybe that was the issue. I'm at a >> loss to understand how people could have thought a BNF for C, for >> the post K&R version of the language, would be challenging or >> difficult. > > I'm having trouble figuring out what you mean here. You acknowledge > that typedefs make a full BNF grammar for C impossible, and then > you say that it's not challenging or difficult. Because I think the problem with typedef names is orthogonal to what Waldek was saying. The problem with typedef names is not solvable in a context-free grammar, and that is just as true today as it was 50 years ago. The syntax I am talking about is C syntax without regard to the problem with typedef names.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-23 04:13 -0700 |
| Message-ID | <10us23t$27egk$2@kst.eternal-september.org> |
| In reply to | #399345 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> antispam@fricas.org (Waldek Hebisch) writes:
>>>> [...] for some time there was a belief that correct and full BNF
>>>> for C was impossible to give or too messy.
>>>
>>> I find this statement hard to believe. There is nothing especially
>>> difficult about a syntax for the C language. There is of course the
>>> well-known problem with typedef names, but that has long been
>>> understood to be unresolvable in any context-free way (and so cannot
>>> be dealt with in BNF). Earlier versions of C (pre-K&R) had other
>>> syntax for some constructs, and maybe that was the issue. I'm at a
>>> loss to understand how people could have thought a BNF for C, for
>>> the post K&R version of the language, would be challenging or
>>> difficult.
>>
>> I'm having trouble figuring out what you mean here. You acknowledge
>> that typedefs make a full BNF grammar for C impossible, and then
>> you say that it's not challenging or difficult.
>
> Because I think the problem with typedef names is orthogonal to
> what Waldek was saying. The problem with typedef names is not
> solvable in a context-free grammar, and that is just as true today
> as it was 50 years ago. The syntax I am talking about is C syntax
> without regard to the problem with typedef names.
I still don't understand your point. A "C syntax without regard
to the problem with typedef names" would not be a correct C syntax
(unless it's for a pre-typedef version of the language).
Typedef names aren't a huge problem, but they're something that has
to be dealt with in a non-trivial way if you want to use something
close to a BNF grammar.
When I read Waldek's statement that "and for some time there was a
belief that correct and full BNF for C was impossible to give or
too messy", I assumed that the typedef issue was exactly what he
was talking about. Perhaps I was mistaken, but I don't know of
any other reason to think that a full BNF for C would be thought
to be impossible, and I think you're saying you don't know of any
such reason either.
Whatever Waldek meant, I think you and I are in agreement that (a)
a full BNF grammar for C is impossible because of the typedef issue,
but (b) the typedef issue can be worked around without too much
difficulty, using something reasonably close to a full BNF grammar.
--
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]
Page 13 of 37 — ← Prev page 1 … 11 12 [13] 14 15 … 37 Next page →
Back to top | Article view | comp.lang.c
csiph-web