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 4 of 37 — ← Prev page 1 2 3 [4] 5 6 … 37 Next page →
| From | kalevi@kolttonen.fi (Kalevi Kolttonen) |
|---|---|
| Date | 2026-05-10 16:44 +0000 |
| Message-ID | <10tqcli$h1ia$1@dont-email.me> |
| In reply to | #398653 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > I wouldn't call it a tragedy, in fact just the opposite. If C had > stayed in its original environment it never would have become as > ubiquitous and widespread as it is today. The original ecosystem > doesn't scale. By letting C, and also Unix, enter the public > sphere, a great benefit accrued to the world at large. The portability of C in the POSIX/SUS systems has proved to be quite good provided that the programmers have not made too many unwarranted assumptions when writing their code. So programs like Sendmail ran, and still runs, on incredibly many commercial and non-commercial UNIX platforms. At home, I run FreeBSD just for fun as a little server: Apache, PostgreSQL, OpenLDAP, Sendmail, pf firewall. On my laptop I always have the latest Fedora Xfce spin. Every day I do appreciate the fact that I can run approximately the same software set on both operating systems even though the kernels and libc are very different in their internals. Standardization is really helpful and a great benefit. I guess FreeBSD is getting left behind in certain areas like not being able to run docker. To be honest, Capsicum security model is also quite stupid and not applicable to most of modern application but with Linux you have LSMs like SELinux that is amazingly versatile and is actually useful in the real world for confining many applications. Concerning C portability, Linux and NetBSD also run on lots of different architectures so carefully written kernel C code can also be very portable. It has been decades since the machine dependent and machine independent parts of UNIX were identified and isolated. So when RISC-V was released a while ago, it did not take too long before both FreeBSD and Linux supported it. This is so cool and even amazing. I know quite well that C is not a perfect language, but I still love it and respect it. I am so old now that I prefer to spend my time studying the C sources of real projects like SELinux kernel and userspace instead of learning new languages such as modern C++ or Rust. I gladly leave that to the younger generations. br, KK
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-10 17:27 +0000 |
| Message-ID | <10tqf5l$aup$1@reader1.panix.com> |
| In reply to | #398653 |
In article <86a4u7s0lo.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>[..I am summarizing parts in an effort to get to key aspects..]
>
>> In article <86o6isuegr.fsf@linuxsc.com>,
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> [snip]
>>> It's important to understand the perspectives of different groups
>>> of participants in the C ecosystem. There are three main groups:
>>>
>>> If you're a programmer, you hate undefined behavior, and avoid it
>>> like the plague.
>>>
>>> If you're a compiler writer, you love undefined behavior, because
>>> it lets you do whatever you want.
>>>
>>> If you're a member of the ISO C standards committee (and I admit
>>> that to a degree I am speculating here), you think of undefined
>>> behavior as a balancing test, of needing to weigh the tensions
>>> inherent in what the first two groups would prefer.
>>
>> This, I think, is the tragedy of C ("tragedy" in the dramatic,
>> Shakespearean sense).
>> [long exposition on the history of C]
>>
>> My point here is that the users and developers of the language
>> were the same group, [elaboration]
>>
>> But, as you pointed out, this is no longer the case. The two are
>> now distinct, with very different goals. [a consequence of which
>> is C usage is less uniform (my paraphrase)]
Here, I was referring to the _groups you defined_.
>> I think this is fair: pretty much no production OS is written in
>> pure ISO C, if they're written in C at all: they all use compiler
>> flags or custom toolchains to enable various extensions and pin
>> down aspects of UB they depend on in one form or another.
>>
>> And this is the tragedy. This isn't how it started, and I don't
>> think the folks who created the language wanted it to go down this
>> way, but here we are. [rest omitted]
>
>I wouldn't call it a tragedy, in fact just the opposite.
The tragedy I alluded to is that precisely the difference
between two groups you yourself suggested: programmers hate UB,
compiler writers love it. The compiler writers and programmers
often appear to have an antagonistic relationship.
>If C had
>stayed in its original environment it never would have become as
>ubiquitous and widespread as it is today. The original ecosystem
>doesn't scale. By letting C, and also Unix, enter the public
>sphere, a great benefit accrued to the world at large.
I said as much.
>[snip] Moreover such non-standard
>language usages are not limited to C -- the Rust language is also
>used in the linux kernel, and there too some non-standard language
>features are used in kernel code.
Rust has no language standard, so saying that "non-standard
language features are used in kernel code" is incorrect.
>I don't mean to compare C and Rust. My position here is only that,
>in my view, the complaints raised about C are misplaced. Others
>are welcome to their own views on the subject.
I don't think you read my note carefully, and your response is
to something I did not say.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-07 18:02 -0700 |
| Message-ID | <86ecihalp6.fsf@linuxsc.com> |
| In reply to | #398666 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <86a4u7s0lo.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>
>> [..I am summarizing parts in an effort to get to key aspects..]
>>
>>> In article <86o6isuegr.fsf@linuxsc.com>,
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> [snip]
>>>> It's important to understand the perspectives of different groups
>>>> of participants in the C ecosystem. There are three main groups:
>>>>
>>>> If you're a programmer, you hate undefined behavior, and avoid it
>>>> like the plague.
>>>>
>>>> If you're a compiler writer, you love undefined behavior, because
>>>> it lets you do whatever you want.
>>>>
>>>> If you're a member of the ISO C standards committee (and I admit
>>>> that to a degree I am speculating here), you think of undefined
>>>> behavior as a balancing test, of needing to weigh the tensions
>>>> inherent in what the first two groups would prefer.
>>>
>>> This, I think, is the tragedy of C ("tragedy" in the dramatic,
>>> Shakespearean sense).
>>> [long exposition on the history of C]
>>>
>>> My point here is that the users and developers of the language
>>> were the same group, [elaboration]
>>>
>>> But, as you pointed out, this is no longer the case. The two are
>>> now distinct, with very different goals. [a consequence of which
>>> is C usage is less uniform (my paraphrase)]
>
> Here, I was referring to the _groups you defined_.
>
>>> I think this is fair: pretty much no production OS is written in
>>> pure ISO C, if they're written in C at all: they all use compiler
>>> flags or custom toolchains to enable various extensions and pin
>>> down aspects of UB they depend on in one form or another.
>>>
>>> And this is the tragedy. This isn't how it started, and I don't
>>> think the folks who created the language wanted it to go down this
>>> way, but here we are. [rest omitted]
>>
>> I wouldn't call it a tragedy, in fact just the opposite.
>
> The tragedy I alluded to is that precisely the difference
> between two groups you yourself suggested: programmers hate UB,
> compiler writers love it. The compiler writers and programmers
> often appear to have an antagonistic relationship.
>
>> If C had
>> stayed in its original environment it never would have become as
>> ubiquitous and widespread as it is today. The original ecosystem
>> doesn't scale. By letting C, and also Unix, enter the public
>> sphere, a great benefit accrued to the world at large.
>
> I said as much.
>
>> [snip] Moreover such non-standard
>> language usages are not limited to C -- the Rust language is also
>> used in the linux kernel, and there too some non-standard language
>> features are used in kernel code.
>
> Rust has no language standard, so saying that "non-standard
> language features are used in kernel code" is incorrect.
>
>> I don't mean to compare C and Rust. My position here is only that,
>> in my view, the complaints raised about C are misplaced. Others
>> are welcome to their own views on the subject.
>
> I don't think you read my note carefully, and your response is
> to something I did not say.
It may be that I didn't understand what you were trying to get
at. But I did read your postings carefully, both the earlier
one I responded to before and the one I am replying to now.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-05-03 00:18 +0000 |
| Message-ID | <10t647p$36agp$1@paganini.bofh.team> |
| In reply to | #398181 |
Bart <bc@freeuk.com> wrote:
> In C, signed overflow can occur /at any time/, and it is apparently UB,
> but it is only UB detected at compile-time that would cause a compiler
> to do weird stuff.
>
> It can't do that weird stuff it it doesn't know for sure that overflow
> will occur. In that case, the result, presumably, is just the natural
> one that the hardware will give you, and that you probably want.
>
> Or does the compiler, intent on causing mischief, inject code to detect
> such overflow, even though it will not happen 99.999999% of the time, so
> that in that 0.000001%, where it might have been intentional, it can go
> and format your hard drive.
Look at the following code:
#include <stdio.h>
int
foo(int j) {
int i;
long res = 0;
for(i = 0; i != j; i++) {
res += i;
res >>= 1;
}
if (i < 0 ) {
printf("Wrapped\n");
}
return res;
}
For me 'gcc -O2' skips the printout. Presumably gcc realised that
absent of undefined behaviour 'i' is always nonnegative. But
if you pass negative 'j' as an argument, then 'j' will never
be equal to a positive number, so loop will eventually lead to
overflow, hence UB. Compiler does not know what arguments user
will pass, it simply assumes that there is no UB. If user
violates this assumption, then program may behave in weird
way. Let me repeat: in this case compiler just generates
"good" code. Any weirdness happens at runtime and only when
_at runtime_ user violates assumptions.
Let me note that for function above gcc uses 64-bit arithmetic.
If you define wraparound semantics, then compiler would be forced
to use 32-bit arithmetic for 'i' and consequently add extra
instruction to extend 'i' to 64 bits before adding it to 'res'.
On modern PC-s such extra instruction in tight loop probably
have nonmeasurable effect. In other cases extra instructions
potentially could slow down program, so it is good that
compiler is doing this optimization.
In this case behaviour is essentually harmless, that is after
_very_ long time (on 64-bit machine you need to wait for overflow
of 64-bit register) there will be no printout. Some people would
like assurance that UB always have trivial effects like in this
specific case. AFAICS rationale for C standard (and other like
Ada, Pascal, Fortran, etc) is that:
- any such assurance would limit possible optimizations and we
do not know which optimizations will be desirable in the future,
- formulating any such assurance is quite tricky, why spend time
defining things which do not matter for most of programs.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-03 11:18 +0100 |
| Message-ID | <10t77ec$2qbod$1@dont-email.me> |
| In reply to | #398206 |
On 03/05/2026 01:18, Waldek Hebisch wrote:
> Bart <bc@freeuk.com> wrote:
>> In C, signed overflow can occur /at any time/, and it is apparently UB,
>> but it is only UB detected at compile-time that would cause a compiler
>> to do weird stuff.
>>
>> It can't do that weird stuff it it doesn't know for sure that overflow
>> will occur. In that case, the result, presumably, is just the natural
>> one that the hardware will give you, and that you probably want.
>>
>> Or does the compiler, intent on causing mischief, inject code to detect
>> such overflow, even though it will not happen 99.999999% of the time, so
>> that in that 0.000001%, where it might have been intentional, it can go
>> and format your hard drive.
>
> Look at the following code:
>
> #include <stdio.h>
>
> int
> foo(int j) {
> int i;
> long res = 0;
> for(i = 0; i != j; i++) {
> res += i;
> res >>= 1;
> }
> if (i < 0 ) {
> printf("Wrapped\n");
> }
> return res;
> }
>
> For me 'gcc -O2' skips the printout. Presumably gcc realised that
> absent of undefined behaviour 'i' is always nonnegative. But
> if you pass negative 'j' as an argument, then 'j' will never
> be equal to a positive number, so loop will eventually lead to
> overflow, hence UB. Compiler does not know what arguments user
> will pass, it simply assumes that there is no UB. If user
> violates this assumption, then program may behave in weird
> way. Let me repeat: in this case compiler just generates
> "good" code. Any weirdness happens at runtime and only when
> _at runtime_ user violates assumptions.
Out of interest I ran your function as foo(2000000000). Results on x64 were:
gcc -O3 1.196 seconds (best of several runs)
bcc 1.196
lccwin32 -O 1.199
DMC -o 1.216
tcc 9.5
So in this case it doesn't profer much advantage. I then ran it with
foo(-1). Timings now were 2.5 seconds and up, except for gcc -O3, which
didn't terminate and had to be aborted.
So its 'weird' code in this case means very different behaviour from
other compilers, and even itself: gcc -O0/-O1 complete the task.
> Let me note that for function above gcc uses 64-bit arithmetic.
> If you define wraparound semantics, then compiler would be forced
> to use 32-bit arithmetic for 'i' and consequently add extra
> instruction to extend 'i' to 64 bits before adding it to 'res'.
> On modern PC-s such extra instruction in tight loop probably
> have nonmeasurable effect. In other cases extra instructions
> potentially could slow down program, so it is good that
> compiler is doing this optimization.
>
> In this case behaviour is essentually harmless, that is after
> _very_ long time (on 64-bit machine you need to wait for overflow
> of 64-bit register) there will be no printout. Some people would
> like assurance that UB always have trivial effects like in this
> specific case. AFAICS rationale for C standard (and other like
> Ada, Pascal, Fortran, etc) is that:
> - any such assurance would limit possible optimizations and we
> do not know which optimizations will be desirable in the future,
> - formulating any such assurance is quite tricky, why spend time
> defining things which do not matter for most of programs.
>
Sure, why not do the same thing in native code! Assume overflow can't
occur and omit all the circuitry that sets that flags. (I think some
hardware does exactly that; let me guess, influenced by C?)
Or, even worse, generate some garbage results when overflow does occur,
or it can detect early on that it will do so and abort early, in the
interests of performance.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-02 17:39 -0700 |
| Message-ID | <10t65fp$2h360$4@kst.eternal-september.org> |
| In reply to | #398181 |
Bart <bc@freeuk.com> writes:
[...]
> In C, signed overflow can occur /at any time/, and it is apparently
> UB, but it is only UB detected at compile-time that would cause a
> compiler to do weird stuff.
I'm not sure what you mean by "at any time". Obviously it can only
occur during a signed arithmetic operation.
Signed overflow has undefined behavior. I don't know what
information you think the word "apparently" adds.
A compiler can certainly do "weird stuff" due to UB that it does
not detect. A compiler may *assume* that a program's behavior
is defined; arbitrarily bad things can result if that assumption
is violated. "If you lie to the compiler, it will get its revenge"
is not meant to be taken literally (unless you're using a DS9000).
One example was a piece of C code that dereferenced a pointer
and then checked whether it's null. The compiler assumed that
the dereference had defined behavior and omitted the following
check. It did not detect that undefined behavior was inevitable;
it assumed that undefined behavior would not occur. (The code was
later corrected so the check would be executed.)
> It can't do that weird stuff it it doesn't know for sure that overflow
> will occur. In that case, the result, presumably, is just the natural
> one that the hardware will give you, and that you probably want.
The word "presumably" is doing a lot of work there.
If you compute INT_MAX+1, do you really *want* a result of INT_MIN?
Maybe you do, but more likely it's a mistake, and you should have
done some other computation.
> Or does the compiler, intent on causing mischief, inject code to
> detect such overflow, even though it will not happen 99.999999% of the
> time, so that in that 0.000001%, where it might have been intentional,
> it can go and format your hard drive.
No, real-world compilers do not intentionally cause mischief.
(The only counterexample I can think of is a very old version of
gcc that would invoke a dungeon game in response to an unrecognized
"#pragma".) But in fact undefined behavior *can* potentially format
your hard drive. A corrupted function pointer might accidentally
point to the format_hard_drive() function. (Many operating systems
avoid this by not permitting ordinary users to format hard drives
without authentication, but plenty of code runs with root or
administrator privileges.)
The C standard does not say that UB is behavior on which the
standard imposes no requirements except that it can't reformat
your hard drive. Such a requirement would be nearly impossible to
state consistently and to enforce.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-04 00:55 +0200 |
| Message-ID | <10t8jp4$1gsnv$4@dont-email.me> |
| In reply to | #398211 |
On 2026-05-03 02:39, Keith Thompson wrote: > > No, real-world compilers do not intentionally cause mischief. > (The only counterexample I can think of is a very old version of > gcc that would invoke a dungeon game in response to an unrecognized > "#pragma".) [...] Given an undefined pragma; would that behavior be "mischief"? ;-) Somehow I expected that this game was an early Roguelike! :-) Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-03 16:50 -0700 |
| Message-ID | <10t8n03$39gdr$1@kst.eternal-september.org> |
| In reply to | #398260 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-05-03 02:39, Keith Thompson wrote:
>> No, real-world compilers do not intentionally cause mischief.
>> (The only counterexample I can think of is a very old version of
>> gcc that would invoke a dungeon game in response to an unrecognized
>> "#pragma".) [...]
>
> Given an undefined pragma; would that behavior be "mischief"? ;-)
>
> Somehow I expected that this game was an early Roguelike! :-)
Here's what C90 says about #pragma:
A preprocessing directive of the form
# pragma pp-tokens[opt] new-line
causes the implementation to behave in an implementation-defined
manner. Any pragma that is not recognized by the implementation
is ignored.
In gcc 1.34, released Feb 1989 (possibly before the final ANSI C
standard was published, but drafts were available) chose to define
the behavior as doing the first of these which succeeds:
/usr/games/hack
/usr/games/rogue
/usr/new/emacs -f hanoi 9 -kill
/usr/local/emacs -f hanoi 9 -kill
If all of those failed, it would emit a fatal error message:
"You are in a maze of twisty compiler features, all different"
The gcc 1.34 sources do not seem to be available. This was removed
(with "#if 0") in gcc 1.35, released in 1989. Ancient gcc sources
are available at <https://ftp.gnu.org/old-gnu/gcc/>; the relevant code
is in cccp.c.
Some details I had missed:
I had thought that gcc was performing this piece of mischief in
response to undefined behavior, and only for an unrecognized #pragma.
In fact the behavior was implementation-defined, and it was done
for all #pragmas. (There were no required #pragmas at the time.)
Strictly speaking, the behavior should have been documented;
I don't know whether it was.
Relevant to comp.lang.c: Except possibly for the documentation issue,
gcc's behavior conformed to the standard, but in a very silly manner.
--
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-02 18:53 +0100 |
| Message-ID | <10t5dn8$2aje4$1@dont-email.me> |
| In reply to | #398176 |
On 02/05/2026 14:52, David Brown wrote:
> On 02/05/2026 15:18, Bart wrote:
>> I ran your example with 6 compilers, with and without optimising, and
>> all returned -2.
>
> And I tried it on another compiler and got a crash "Program terminated
> with signal: SIGILL".
Which compiler?
I tried another experiment with printing the result of 2 * 2000000000
across several languages. All these printed -294967296:
C#
D
Java
Fortran
Kotlin
(All run from rextester.com.) These also printed an overflowed result:
Pascal (16-bit overflow)
Go (Overflowed 64 bits with a bigger calculation)
Lua 5.4 (Overflowed 64 bits)
So quite a few languages including mainstream ones don't seem bothered
by it. Only C seems to get in a tizz about it, ands it's mainly a few
people posting here who seem think it is such a big deal.
Some languages either didn't overflow, like CLisp, Clojure, Scheme, MySQL.
Rust generated a runtime panic (after I tweaked it so that it could not
be detected at compile-time). I believe Rust can be compiled in release
mode, so that it would generate the above result, but I didn't know how.
But unlike C, Rust also doesn't like it when unsigned types overflow. So
the inconsistency from C is not there.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-02 21:20 +0200 |
| Message-ID | <10t5ip1$2crol$2@dont-email.me> |
| In reply to | #398183 |
On 02/05/2026 19:53, Bart wrote: > On 02/05/2026 14:52, David Brown wrote: >> On 02/05/2026 15:18, Bart wrote: > >>> I ran your example with 6 compilers, with and without optimising, and >>> all returned -2. >> >> And I tried it on another compiler and got a crash "Program terminated >> with signal: SIGILL". > > Which compiler? gcc -O1 -fsanitize -fsanitize-trap -std=c99 -Werror=pendantic That's a conforming C compiler, baring bugs, and any possible gcc oddities that were not caught by -Werror=pedantic. > > I tried another experiment with printing the result of 2 * 2000000000 > across several languages. All these printed -294967296: > > C# > D > Java > Fortran > Kotlin > > (All run from rextester.com.) These also printed an overflowed result: > > Pascal (16-bit overflow) > Go (Overflowed 64 bits with a bigger calculation) > Lua 5.4 (Overflowed 64 bits) > > So quite a few languages including mainstream ones don't seem bothered > by it. Only C seems to get in a tizz about it, ands it's mainly a few > people posting here who seem think it is such a big deal. > > Some languages either didn't overflow, like CLisp, Clojure, Scheme, MySQL. > > Rust generated a runtime panic (after I tweaked it so that it could not > be detected at compile-time). I believe Rust can be compiled in release > mode, so that it would generate the above result, but I didn't know how. > > But unlike C, Rust also doesn't like it when unsigned types overflow. So > the inconsistency from C is not there. > Rust has its own even worse inconsistency - the behaviour of overflows depends on release or debug mode.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-02 14:46 -0700 |
| Message-ID | <10t5rbk$2elg5$2@kst.eternal-september.org> |
| In reply to | #398186 |
David Brown <david.brown@hesbynett.no> writes:
> On 02/05/2026 19:53, Bart wrote:
>> On 02/05/2026 14:52, David Brown wrote:
[...]
>>> And I tried it on another compiler and got a crash "Program
>>> terminated with signal: SIGILL".
>> Which compiler?
>
> gcc -O1 -fsanitize -fsanitize-trap -std=c99 -Werror=pendantic
>
> That's a conforming C compiler, baring bugs, and any possible gcc
> oddities that were not caught by -Werror=pedantic.
[...]
Do you really have a gcc that accepts "-fsanitize" without
an argument? The versions I've tried require an argument,
"-fsanitize=ARG", where ARG can be "address", "kernel-address",
"hwaddress", and so on. I haven't checked versions of gcc older
than 13.3.0.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-03 01:14 +0200 |
| Message-ID | <10t60g2$2gp96$1@dont-email.me> |
| In reply to | #398191 |
On 02/05/2026 23:46, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 02/05/2026 19:53, Bart wrote: >>> On 02/05/2026 14:52, David Brown wrote: > [...] >>>> And I tried it on another compiler and got a crash "Program >>>> terminated with signal: SIGILL". >>> Which compiler? >> >> gcc -O1 -fsanitize -fsanitize-trap -std=c99 -Werror=pendantic >> >> That's a conforming C compiler, baring bugs, and any possible gcc >> oddities that were not caught by -Werror=pedantic. > [...] > > Do you really have a gcc that accepts "-fsanitize" without > an argument? The versions I've tried require an argument, > "-fsanitize=ARG", where ARG can be "address", "kernel-address", > "hwaddress", and so on. I haven't checked versions of gcc older > than 13.3.0. > You are correct - -fsanitize=undefined is the appropriate option. (You can try it on godbolt without installation - you can even run it and see the results.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-02 17:02 -0700 |
| Message-ID | <10t63a5$2h360$2@kst.eternal-september.org> |
| In reply to | #398196 |
David Brown <david.brown@hesbynett.no> writes:
> On 02/05/2026 23:46, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 02/05/2026 19:53, Bart wrote:
>>>> On 02/05/2026 14:52, David Brown wrote:
>> [...]
>>>>> And I tried it on another compiler and got a crash "Program
>>>>> terminated with signal: SIGILL".
>>>> Which compiler?
>>>
>>> gcc -O1 -fsanitize -fsanitize-trap -std=c99 -Werror=pendantic
>>>
>>> That's a conforming C compiler, baring bugs, and any possible gcc
>>> oddities that were not caught by -Werror=pedantic.
>> [...]
>> Do you really have a gcc that accepts "-fsanitize" without
>> an argument? The versions I've tried require an argument,
>> "-fsanitize=ARG", where ARG can be "address", "kernel-address",
>> "hwaddress", and so on. I haven't checked versions of gcc older
>> than 13.3.0.
>
> You are correct - -fsanitize=undefined is the appropriate option.
>
> (You can try it on godbolt without installation - you can even run it
> and see the results.)
And it's "-Werror=pedantic", not "...pendantic".
I recommend copy-and-paste, both for code and for commands.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-03 12:46 +0200 |
| Message-ID | <10t792c$2qne2$3@dont-email.me> |
| In reply to | #398203 |
On 03/05/2026 02:02, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 02/05/2026 23:46, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 02/05/2026 19:53, Bart wrote: >>>>> On 02/05/2026 14:52, David Brown wrote: >>> [...] >>>>>> And I tried it on another compiler and got a crash "Program >>>>>> terminated with signal: SIGILL". >>>>> Which compiler? >>>> >>>> gcc -O1 -fsanitize -fsanitize-trap -std=c99 -Werror=pendantic >>>> >>>> That's a conforming C compiler, baring bugs, and any possible gcc >>>> oddities that were not caught by -Werror=pedantic. >>> [...] >>> Do you really have a gcc that accepts "-fsanitize" without >>> an argument? The versions I've tried require an argument, >>> "-fsanitize=ARG", where ARG can be "address", "kernel-address", >>> "hwaddress", and so on. I haven't checked versions of gcc older >>> than 13.3.0. >> >> You are correct - -fsanitize=undefined is the appropriate option. >> >> (You can try it on godbolt without installation - you can even run it >> and see the results.) > > And it's "-Werror=pedantic", not "...pendantic". > > I recommend copy-and-paste, both for code and for commands. > Usually I do copy and paste, but I had been testing out a variety of options on godbolt at the time. My manual copying failed me here :-( My apologies if that caused anyone confusion.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-02 23:51 +0100 |
| Message-ID | <10t5v4p$2g7lq$1@dont-email.me> |
| In reply to | #398186 |
On 02/05/2026 20:20, David Brown wrote: > On 02/05/2026 19:53, Bart wrote: >> On 02/05/2026 14:52, David Brown wrote: >>> On 02/05/2026 15:18, Bart wrote: >> >>>> I ran your example with 6 compilers, with and without optimising, >>>> and all returned -2. >>> >>> And I tried it on another compiler and got a crash "Program >>> terminated with signal: SIGILL". >> >> Which compiler? > > gcc -O1 -fsanitize -fsanitize-trap -std=c99 -Werror=pendantic > > That's a conforming C compiler, baring bugs, and any possible gcc > oddities that were not caught by -Werror=pedantic. I wasn't able to test that, it didn't like '-fsanitize' (and I fixed the later typo). Without that, it produced an executable that gave the same results as my tests below. But I assume that somehow you have told it to check for such overflows and report an error? Then you have deliberately told it to crash. But it would not do so otherwise. > > >> >> I tried another experiment with printing the result of 2 * 2000000000 >> across several languages. All these printed -294967296: >> >> C# >> D >> Java >> Fortran >> Kotlin >> >> (All run from rextester.com.) These also printed an overflowed result: >> >> Pascal (16-bit overflow) >> Go (Overflowed 64 bits with a bigger calculation) >> Lua 5.4 (Overflowed 64 bits) >> >> So quite a few languages including mainstream ones don't seem bothered >> by it. Only C seems to get in a tizz about it, ands it's mainly a few >> people posting here who seem think it is such a big deal. >> >> Some languages either didn't overflow, like CLisp, Clojure, Scheme, >> MySQL. >> >> Rust generated a runtime panic (after I tweaked it so that it could >> not be detected at compile-time). I believe Rust can be compiled in >> release mode, so that it would generate the above result, but I didn't >> know how. >> >> But unlike C, Rust also doesn't like it when unsigned types overflow. >> So the inconsistency from C is not there. >> > > Rust has its own even worse inconsistency - the behaviour of overflows > depends on release or debug mode. That doesn't sound much different from giving gcc options to force a crash. > >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-03 01:20 +0200 |
| Message-ID | <10t60sp$2gp96$2@dont-email.me> |
| In reply to | #398194 |
On 03/05/2026 00:51, Bart wrote: > On 02/05/2026 20:20, David Brown wrote: >> On 02/05/2026 19:53, Bart wrote: >>> On 02/05/2026 14:52, David Brown wrote: >>>> On 02/05/2026 15:18, Bart wrote: >>> >>>>> I ran your example with 6 compilers, with and without optimising, >>>>> and all returned -2. >>>> >>>> And I tried it on another compiler and got a crash "Program >>>> terminated with signal: SIGILL". >>> >>> Which compiler? >> >> gcc -O1 -fsanitize -fsanitize-trap -std=c99 -Werror=pendantic >> >> That's a conforming C compiler, baring bugs, and any possible gcc >> oddities that were not caught by -Werror=pedantic. > > I wasn't able to test that, it didn't like '-fsanitize' (and I fixed the > later typo). Without that, it produced an executable that gave the same > results as my tests below. > Sorry - it should be "-fsanitize=undefined". > But I assume that somehow you have told it to check for such overflows > and report an error? > > Then you have deliberately told it to crash. But it would not do so > otherwise. > I did not tell it to crash - I told gcc to help find UB bugs. If there had not been UB in the code, there would have been no crash. But the point is that this is perfectly acceptable behaviour for a compiler in the face of such UB. The compiler, with "-fsanitize=undefined", is just as conforming as without that option. You could reasonably argue that it is a good idea to have such options enabled even in released code, to limit the consequences of unknown bugs in code. In a language that says integer arithmetic overflow is defined as wrapping, you have no such option - compilers can't add in that kind of damage limitation or bug-finding help. The language definition requires that absurd and meaningless results are "correct", and you have to live with it. Thus in a language that defines wrapping signed integer arithmetic, you are /more/ likely to have to add manual checks in your code for overflow, because tools can't provide automated help. >> >> Rust has its own even worse inconsistency - the behaviour of overflows >> depends on release or debug mode. > > That doesn't sound much different from giving gcc options to force a crash. > It is very much worse. Rust tools (AFAIUI - I am not a Rust programmer, and this is not a Rust group) distinguish between debug mode and release mode as two different runtime environments for the language. You don't have the choice to mix and match, as you do with gcc.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-05-03 07:43 +0800 |
| Message-ID | <25fd121d7cbe895b0f9de5f9176fa2e6f423c85c.camel@gmail.com> |
| In reply to | #398197 |
On Sun, 2026-05-03 at 01:20 +0200, David Brown wrote: > On 03/05/2026 00:51, Bart wrote: > > On 02/05/2026 20:20, David Brown wrote: > > > On 02/05/2026 19:53, Bart wrote: > > > > On 02/05/2026 14:52, David Brown wrote: > > > > > On 02/05/2026 15:18, Bart wrote: > > > > > > > > > > I ran your example with 6 compilers, with and without optimising, > > > > > > and all returned -2. > > > > > > > > > > And I tried it on another compiler and got a crash "Program > > > > > terminated with signal: SIGILL". > > > > > > > > Which compiler? > > > > > > gcc -O1 -fsanitize -fsanitize-trap -std=c99 -Werror=pendantic > > > > > > That's a conforming C compiler, baring bugs, and any possible gcc > > > oddities that were not caught by -Werror=pedantic. > > > > I wasn't able to test that, it didn't like '-fsanitize' (and I fixed the > > later typo). Without that, it produced an executable that gave the same > > results as my tests below. > > > > Sorry - it should be "-fsanitize=undefined". > > > But I assume that somehow you have told it to check for such overflows > > and report an error? > > > > Then you have deliberately told it to crash. But it would not do so > > otherwise. > > > > I did not tell it to crash - I told gcc to help find UB bugs. If there > had not been UB in the code, there would have been no crash. I think you made a wording error yourself, UB is not a bug by the standard. LLM: "In the eyes of the ISO C Standard, UB is not technically a "bug" in the compiler; it is a "violation of the programmer's contract." However, in the eyes of a programmer, it is a bug because the program is no longer behaving predictably." I don't know how many word game are, or will be there. There are many things to adjust for the 'silent error', and you call it the programmer's responsibility. > But the point is that this is perfectly acceptable behaviour for a > compiler in the face of such UB. The compiler, with > "-fsanitize=undefined", is just as conforming as without that option. > You could reasonably argue that it is a good idea to have such options > enabled even in released code, to limit the consequences of unknown bugs > in code. > > In a language that says integer arithmetic overflow is defined as > wrapping, you have no such option - compilers can't add in that kind of > damage limitation or bug-finding help. The language definition requires > that absurd and meaningless results are "correct", and you have to live > with it. > > Thus in a language that defines wrapping signed integer arithmetic, you > are /more/ likely to have to add manual checks in your code for > overflow, because tools can't provide automated help. > > > > > > > Rust has its own even worse inconsistency - the behaviour of overflows > > > depends on release or debug mode. > > > > That doesn't sound much different from giving gcc options to force a crash. > > > > It is very much worse. Rust tools (AFAIUI - I am not a Rust programmer, > and this is not a Rust group) distinguish between debug mode and release > mode as two different runtime environments for the language. You don't > have the choice to mix and match, as you do with gcc.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-03 12:50 +0200 |
| Message-ID | <10t79aa$2qne2$4@dont-email.me> |
| In reply to | #398198 |
On 03/05/2026 01:43, wij wrote: > On Sun, 2026-05-03 at 01:20 +0200, David Brown wrote: >> On 03/05/2026 00:51, Bart wrote: >>> On 02/05/2026 20:20, David Brown wrote: >>>> On 02/05/2026 19:53, Bart wrote: >>>>> On 02/05/2026 14:52, David Brown wrote: >>>>>> On 02/05/2026 15:18, Bart wrote: >>>>> >>>>>>> I ran your example with 6 compilers, with and without optimising, >>>>>>> and all returned -2. >>>>>> >>>>>> And I tried it on another compiler and got a crash "Program >>>>>> terminated with signal: SIGILL". >>>>> >>>>> Which compiler? >>>> >>>> gcc -O1 -fsanitize -fsanitize-trap -std=c99 -Werror=pendantic >>>> >>>> That's a conforming C compiler, baring bugs, and any possible gcc >>>> oddities that were not caught by -Werror=pedantic. >>> >>> I wasn't able to test that, it didn't like '-fsanitize' (and I fixed the >>> later typo). Without that, it produced an executable that gave the same >>> results as my tests below. >>> >> >> Sorry - it should be "-fsanitize=undefined". >> >>> But I assume that somehow you have told it to check for such overflows >>> and report an error? >>> >>> Then you have deliberately told it to crash. But it would not do so >>> otherwise. >>> >> >> I did not tell it to crash - I told gcc to help find UB bugs. If there >> had not been UB in the code, there would have been no crash. > > I think you made a wording error yourself, UB is not a bug by the standard. If your code executes UB, then there is either a bug in your code, or a bug in whatever is calling your code (other code, or passing inappropriate values to the program). > > LLM: "In the eyes of the ISO C Standard, UB is not technically a "bug" in the compiler; it is a > "violation of the programmer's contract." However, in the eyes of a programmer, it is a bug because > the program is no longer behaving predictably." Please top using LLMs. You are only confusing yourself and being mislead. If you keep talking to them and believing the half-truths or complete fabrications they generate, it will be very difficult for you to learn how the C language actually works. UB in your own code is not in any sense a bug in the compiler.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-03 14:27 -0400 |
| Message-ID | <10t8429$33csl$1@dont-email.me> |
| In reply to | #398198 |
On 03/05/2026 01:43, wij wrote: ... > I think you made a wording error yourself, UB is not a bug by the standard. C is not an assembly language, it's a language where you tell the compiler what behavior you want, and the compiler is free to choose any sequence of machine code instructions that will produce the same observable behavior as you requested. When you write code with Undefined behavior, that means the standard imposes no restrictions on the behavior, so you are in effect asking the compiler to do whatever it wants to do - you are explicitly saying that you don't care what it does. It is very rare for people to actually intend that meaning - it is normally a bug.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-03 20:27 -0700 |
| Message-ID | <86jytjyhuf.fsf@linuxsc.com> |
| In reply to | #398238 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: [...] > When you write code with Undefined behavior, that means the standard > imposes no restrictions on the behavior, so you are in effect asking > the compiler to do whatever it wants to do - you are explicitly > saying that you don't care what it does. [...] Assuming the use of a construction with undefined behavior was intentional, I would say this statement is at least incomplete. It could be that the UB invoker is saying, in effect, "I know that other compilers might do the wrong thing here, but I also know that the compiler being used for this project will do what is wanted." That might be because of a defined extension; or because the behavior desired is verified in some way; or perhaps some other reason. In any case certainly it is possible that the choice was made not because of lack of caring but because some awareness of the particular circumstances allows more confidence in what will happen than "undefined behavior" generally provides.
[toc] | [prev] | [next] | [standalone]
Page 4 of 37 — ← Prev page 1 2 3 [4] 5 6 … 37 Next page →
Back to top | Article view | comp.lang.c
csiph-web