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 1 of 37 [1] 2 3 … 37 Next page →
| From | kalevi@kolttonen.fi (Kalevi Kolttonen) |
|---|---|
| Date | 2026-04-30 00:39 +0000 |
| Subject | Safety of casting from 'long' to 'int' |
| Message-ID | <10su8cn$am9i$1@dont-email.me> |
Hello!
A simple question and yes, I know I could ask AI bots
but the problem is that I cannot always trust their
responses.
Is it always safe and not undefined behavior to do:
int i;
long l;
i = (int)l;
as long as you have first veried that 'l' is within
the range between INT_MIN and INT_MAX? Thanks.
br,
KK
[toc] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-04-30 09:11 +0800 |
| Message-ID | <c337c87a5cb48e0c9400cc546a53abbc0a95110b.camel@gmail.com> |
| In reply to | #398106 |
On Thu, 2026-04-30 at 00:39 +0000, Kalevi Kolttonen wrote: > Hello! > > A simple question and yes, I know I could ask AI bots > but the problem is that I cannot always trust their > responses. > > Is it always safe and not undefined behavior to do: > > int i; > long l; > i = (int)l; > > as long as you have first veried that 'l' is within > the range between INT_MIN and INT_MAX? Thanks. > > br, > KK Yes, 'behavior' is defined. Don't over-interpret what C standard says. Basically, C is portable assembly (may include optimizations,..).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-04-29 21:12 -0400 |
| Message-ID | <10suaa4$9qeg$2@dont-email.me> |
| In reply to | #398106 |
On 2026-04-29 20:39, Kalevi Kolttonen wrote: > Hello! > > A simple question and yes, I know I could ask AI bots > but the problem is that I cannot always trust their > responses. > > Is it always safe and not undefined behavior to do: > > int i; > long l; > i = (int)l; > > as long as you have first veried that 'l' is within > the range between INT_MIN and INT_MAX? Thanks. Yes. <picky> Your code as written has undefined behavior if it occurs at block scope (which seems likely, given the indentation) because l hasn't been given a value. Your question implies that it must have been given a value, otherwise how could you have known that the value was in range. Still, It would have been better to include a line like the following after the declaration of and before the value of l is retrieved: // Set l to a value. While technically redundant because of your subsequent question, this avoids any confusion. </picky>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-04-29 19:56 -0700 |
| Message-ID | <10sugd6$cep2$1@kst.eternal-september.org> |
| In reply to | #398106 |
kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
> Hello!
>
> A simple question and yes, I know I could ask AI bots
> but the problem is that I cannot always trust their
> responses.
>
> Is it always safe and not undefined behavior to do:
>
> int i;
> long l;
> i = (int)l;
>
> as long as you have first veried that 'l' is within
> the range between INT_MIN and INT_MAX? Thanks.
It depends. If `l` has had a value stored in it, and you then check
whether it's in the range INT_MIN to INT_MAX, then you're fine:
int i;
long l;
l = some_arbitrary_value();
if (l >= INT_MIN && l <= INT_MAX) {
i = l; // implicit conversion, no cast is needed
}
else {
// what now??
}
But if `l` is uninitialized, the act of checking it has undefined
behavior:
int i;
long l;
if (l >= INT_MIN && l <= INT_MAX) { // undefined behavior
// ...
}
(I advise disregarding wij's reply.)
--
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 | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-04-30 11:30 +0800 |
| Message-ID | <befd238b3d7c222df98b2b14ae1f57a4093472d0.camel@gmail.com> |
| In reply to | #398116 |
On Wed, 2026-04-29 at 19:56 -0700, Keith Thompson wrote:
> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
> > Hello!
> >
> > A simple question and yes, I know I could ask AI bots
> > but the problem is that I cannot always trust their
> > responses.
> >
> > Is it always safe and not undefined behavior to do:
> >
> > int i;
> > long l;
> > i = (int)l;
> >
> > as long as you have first veried that 'l' is within
> > the range between INT_MIN and INT_MAX? Thanks.
>
> It depends. If `l` has had a value stored in it, and you then check
> whether it's in the range INT_MIN to INT_MAX, then you're fine:
>
> int i;
> long l;
> l = some_arbitrary_value();
> if (l >= INT_MIN && l <= INT_MAX) {
> i = l; // implicit conversion, no cast is needed
> }
> else {
> // what now??
> }
>
> But if `l` is uninitialized, the act of checking it has undefined
> behavior:
>
> int i;
> long l;
> if (l >= INT_MIN && l <= INT_MAX) { // undefined behavior
> // ...
> }
>
> (I advise disregarding wij's reply.)
I just talked with LLM:
"...reading an uninitialized value of automatic storage duration is undefined behavior.
Undefined behavior means: the compiler can do literally anything. It is not required to generate code
to perform the assignment."
UB seems a short and good answer.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-30 00:56 -0700 |
| Message-ID | <86pl3gzxt3.fsf@linuxsc.com> |
| In reply to | #398106 |
kalevi@kolttonen.fi (Kalevi Kolttonen) writes: > Hello! > > A simple question and yes, I know I could ask AI bots > but the problem is that I cannot always trust their > responses. > > Is it always safe and not undefined behavior to do: > > int i; > long l; > i = (int)l; > > as long as you have first veried that 'l' is within > the range between INT_MIN and INT_MAX? Thanks. Assuming the variable 'l' has been given a value, the assignment to 'i' is always defined (and by the way the cast is not needed), and never undefined behavior. If the value in 'l' lies within the range of int the value is unchanged. If the value in 'l' lies outside the range of int, the result is implementation-defined or an implementation-defined signal is raised.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-30 10:47 +0200 |
| Message-ID | <10sv4v0$h9mn$1@dont-email.me> |
| In reply to | #398106 |
On 30/04/2026 02:39, Kalevi Kolttonen wrote: > Hello! > > A simple question and yes, I know I could ask AI bots > but the problem is that I cannot always trust their > responses. > > Is it always safe and not undefined behavior to do: > > int i; > long l; > i = (int)l; > > as long as you have first veried that 'l' is within > the range between INT_MIN and INT_MAX? Thanks. > > br, > KK Others have given you the answer to your question. Asking here will get you accurate answers (James, Keith and Tim are all experts at the details of C), while AI may or may not be correct at this kind of thing. There are a lot of people who misunderstand the subtleties of C, especially when you are asking what the standards actually say rather than just what is likely to work on a particular compiler. When people write the kind of nonsense wij does, AI "learns" from them too, and can regurgitate the same mistakes. The ultimate guide here is, of course, the C standards (for whichever version you prefer - this particular behaviour has not changed in any significant way). The C standards can often be hard to read if you are not used to them (though this bit, section 6.3.1.3, is clear). If you prefer a different organisation of the information in the standards, I recommend the "cppreference.com" website, which is supported directly by the C++ standards committee. (The site covers C and C++.) It is an accurate reference, and has the advantage of showing clearly when things have changed between C standards versions. <https://cppreference.com/c/language/conversion>
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-04-30 19:35 +0800 |
| Message-ID | <84c1c180f4d5b96259a631bdb09b6054b4eb44d2.camel@gmail.com> |
| In reply to | #398126 |
On Thu, 2026-04-30 at 10:47 +0200, David Brown wrote: > On 30/04/2026 02:39, Kalevi Kolttonen wrote: > > Hello! > > > > A simple question and yes, I know I could ask AI bots > > but the problem is that I cannot always trust their > > responses. > > > > Is it always safe and not undefined behavior to do: > > > > int i; > > long l; > > i = (int)l; > > > > as long as you have first veried that 'l' is within > > the range between INT_MIN and INT_MAX? Thanks. > > > > br, > > KK > > Others have given you the answer to your question. Asking here will get > you accurate answers (James, Keith and Tim are all experts at the > details of C), while AI may or may not be correct at this kind of thing. > There are a lot of people who misunderstand the subtleties of C, > especially when you are asking what the standards actually say rather > than just what is likely to work on a particular compiler. When people > write the kind of nonsense wij does, AI "learns" from them too, and can > regurgitate the same mistakes. What mistake? Can compiler generate code other than "i=(int)l;" appears to be? I did not write C program for >30 years, something might be missed. So, what would this expert say? > The ultimate guide here is, of course, the C standards (for whichever > version you prefer - this particular behaviour has not changed in any > significant way). The C standards can often be hard to read if you are > not used to them (though this bit, section 6.3.1.3, is clear). If you > prefer a different organisation of the information in the standards, I > recommend the "cppreference.com" website, which is supported directly by > the C++ standards committee. (The site covers C and C++.) It is an > accurate reference, and has the advantage of showing clearly when things > have changed between C standards versions. > > <https://cppreference.com/c/language/conversion>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-04-30 14:04 +0200 |
| Message-ID | <10svgfv$l2bu$1@dont-email.me> |
| In reply to | #398130 |
On 30/04/2026 13:35, wij wrote: > On Thu, 2026-04-30 at 10:47 +0200, David Brown wrote: >> On 30/04/2026 02:39, Kalevi Kolttonen wrote: >>> Hello! >>> >>> A simple question and yes, I know I could ask AI bots >>> but the problem is that I cannot always trust their >>> responses. >>> >>> Is it always safe and not undefined behavior to do: >>> >>> int i; >>> long l; >>> i = (int)l; >>> >>> as long as you have first veried that 'l' is within >>> the range between INT_MIN and INT_MAX? Thanks. >>> >>> br, >>> KK >> >> Others have given you the answer to your question. Asking here will get >> you accurate answers (James, Keith and Tim are all experts at the >> details of C), while AI may or may not be correct at this kind of thing. >> There are a lot of people who misunderstand the subtleties of C, >> especially when you are asking what the standards actually say rather >> than just what is likely to work on a particular compiler. When people >> write the kind of nonsense wij does, AI "learns" from them too, and can >> regurgitate the same mistakes. > > What mistake? Can compiler generate code other than "i=(int)l;" appears to be? > > I did not write C program for >30 years, something might be missed. So, what > would this expert say? > Experts would /not/ say "C is portable assembly". When asked a question about the guaranteed meaning of something in C (rather than the likely behaviour of some particular compiler), they would /not/ say "don't over-interpret what the C standard says". They would /not/ be asking some AI for answers here. You were correct that the behaviour of the conversion is defined - the rest of your answer was directly counter-productive.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-05-02 12:32 +0800 |
| Message-ID | <fd7787f25cf958abb657d3098b0c9f5cc80df928.camel@gmail.com> |
| In reply to | #398131 |
On Thu, 2026-04-30 at 14:04 +0200, David Brown wrote:
> On 30/04/2026 13:35, wij wrote:
> > On Thu, 2026-04-30 at 10:47 +0200, David Brown wrote:
> > > On 30/04/2026 02:39, Kalevi Kolttonen wrote:
> > > > Hello!
> > > >
> > > > A simple question and yes, I know I could ask AI bots
> > > > but the problem is that I cannot always trust their
> > > > responses.
> > > >
> > > > Is it always safe and not undefined behavior to do:
> > > >
> > > > int i;
> > > > long l;
> > > > i = (int)l;
> > > >
> > > > as long as you have first veried that 'l' is within
> > > > the range between INT_MIN and INT_MAX? Thanks.
> > > >
> > > > br,
> > > > KK
> > >
> > > Others have given you the answer to your question. Asking here will get
> > > you accurate answers (James, Keith and Tim are all experts at the
> > > details of C), while AI may or may not be correct at this kind of thing.
> > > There are a lot of people who misunderstand the subtleties of C,
> > > especially when you are asking what the standards actually say rather
> > > than just what is likely to work on a particular compiler. When people
> > > write the kind of nonsense wij does, AI "learns" from them too, and can
> > > regurgitate the same mistakes.
> >
> > What mistake? Can compiler generate code other than "i=(int)l;" appears to be?
> >
> > I did not write C program for >30 years, something might be missed. So, what
> > would this expert say?
> >
>
> Experts would /not/ say "C is portable assembly". When asked a question
> about the guaranteed meaning of something in C (rather than the likely
> behaviour of some particular compiler), they would /not/ say "don't
> over-interpret what the C standard says". They would /not/ be asking
> some AI for answers here.
The problem with 'legal terms' is it is abstract (I think the main audience
of the standard is compiler implementer). Using it too much to explain C would
make the analysis like what 'TV expert' provides, lots of professional-looking
terms but no real substance inside. E.g.
int F() {
int a,b;
return a+b; // UB?
}
1. F is standard conforming as long as F does not mean to portably return
the value of the sum of a and b.
2. If the compiler translates the last line to "return a*b;", I am afraid such
translation is not rejected as non-standardare conforming, i.e. "a*b" is
still likely standard conforming from the common rule I read.
> You were correct that the behaviour of the conversion is defined - the
> rest of your answer was directly counter-productive.
In the early 2000, comp.lang.c++ is full of superstition (being abstract) as if
c++ is an AI language. I have the feel that C is following c++'s (failed) ideal.
I still think 'portable assembly' is good (to understand C).
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-02 08:57 +0200 |
| Message-ID | <10t4790$1gsnv$1@dont-email.me> |
| In reply to | #398170 |
On 2026-05-02 06:32, wij wrote:
>> [...]
>
> The problem with 'legal terms' is it is abstract (I think the main audience
> of the standard is compiler implementer). Using it too much to explain C would
> make the analysis like what 'TV expert' provides, lots of professional-looking
> terms but no real substance inside. E.g.
>
> int F() {
> int a,b;
> return a+b; // UB?
> }
I think if you write such code you have fundamental other
problems than the "language in which standards are written".
If you want to know what you can expect with above code the
use of the semi-formal standard is probably the best choice
you have (even if you don't implement compilers).
(I wonder what drives you to post such things and complain
about answers. You'd probably feel happier if you continue
to "talk with LLMs"?)
Janis
> [...]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-02 11:58 +0200 |
| Message-ID | <10t4hse$22u36$1@dont-email.me> |
| In reply to | #398170 |
On 02/05/2026 06:32, wij wrote:
> On Thu, 2026-04-30 at 14:04 +0200, David Brown wrote:
>> On 30/04/2026 13:35, wij wrote:
>>> On Thu, 2026-04-30 at 10:47 +0200, David Brown wrote:
>>>> On 30/04/2026 02:39, Kalevi Kolttonen wrote:
>>>>> Hello!
>>>>>
>>>>> A simple question and yes, I know I could ask AI bots
>>>>> but the problem is that I cannot always trust their
>>>>> responses.
>>>>>
>>>>> Is it always safe and not undefined behavior to do:
>>>>>
>>>>> int i;
>>>>> long l;
>>>>> i = (int)l;
>>>>>
>>>>> as long as you have first veried that 'l' is within
>>>>> the range between INT_MIN and INT_MAX? Thanks.
>>>>>
>>>>> br,
>>>>> KK
>>>>
>>>> Others have given you the answer to your question. Asking here will get
>>>> you accurate answers (James, Keith and Tim are all experts at the
>>>> details of C), while AI may or may not be correct at this kind of thing.
>>>> There are a lot of people who misunderstand the subtleties of C,
>>>> especially when you are asking what the standards actually say rather
>>>> than just what is likely to work on a particular compiler. When people
>>>> write the kind of nonsense wij does, AI "learns" from them too, and can
>>>> regurgitate the same mistakes.
>>>
>>> What mistake? Can compiler generate code other than "i=(int)l;" appears to be?
>>>
>>> I did not write C program for >30 years, something might be missed. So, what
>>> would this expert say?
>>>
>>
>> Experts would /not/ say "C is portable assembly". When asked a question
>> about the guaranteed meaning of something in C (rather than the likely
>> behaviour of some particular compiler), they would /not/ say "don't
>> over-interpret what the C standard says". They would /not/ be asking
>> some AI for answers here.
>
> The problem with 'legal terms' is it is abstract (I think the main audience
> of the standard is compiler implementer). Using it too much to explain C would
> make the analysis like what 'TV expert' provides, lots of professional-looking
> terms but no real substance inside. E.g.
You are completely wrong.
The C standards provide a contract between the compiler implementers,
and compiler users - C programmers. Both parties need to understand the
C standards.
Of course a C compiler implementer will need to read the whole standard
thoroughly and understand it in great detail. A typical C user does not
need such complete knowledge. For example, I don't have use of floating
point in my code other than "approximating real number calculations" - I
haven't read the details of handling of NaNs, floating point exceptions,
etc., because they are not relevant to my work and not of particular
interest to me. Other parts of the standards I have studied more carefully.
Many C programmers never bother reading the C standards at all. But
they should all refer back to them. What happens when your signed
integer arithmetic overflows? A good C programmer knows it is UB, and
anything can happen - including nasal daemons, or the compiler skipping
code, so they avoid letting it happen in their code. They know it is UB
because they know the standard says it is UB - even if they have not
read the standard. It is how the language is defined. They may get
their knowledge of the C standards indirectly, from books, courses,
websites, questions and answers in a forum like this, but it all traces
back to the standards.
>
> int F() {
> int a,b;
> return a+b; // UB?
> }
>
> 1. F is standard conforming as long as F does not mean to portably return
> the value of the sum of a and b.
No. Reading and using the value of an uninitialised variable is UB.
(It is not UB to define and compile the function F here - it is UB to
call it at runtime.) The code is clearly nonsense - "take two numbers
from nowhere, add them, and return the sum". I don't know if there is a
good word for writing meaningless text that happens to match the syntax
of a programming language, but it is certainly not "programming".
> 2. If the compiler translates the last line to "return a*b;", I am afraid such
> translation is not rejected as non-standardare conforming, i.e. "a*b" is
> still likely standard conforming from the common rule I read.
>
The compiler can translate the code into anything it likes - including a
system call to format your harddrive. (Again, the UB - and thus the
drive format - is only if F() is actually called at runtime.) Ignoring
the DS9000 compiler, real compilers use knowledge of UB to generate
smaller and faster code in the event that the UB is not called. Thus a
typical implementation from a compiler might be "F: ret" - do nothing at
all. Other possibilities include generating code to aid debugging and
fault-finding, such as "F: trap" (or "F: ub2" in x86 assembly). A
minimal implementation, "F: " that simple runs on to whatever is in
memory after that label, is also fine.
>> You were correct that the behaviour of the conversion is defined - the
>> rest of your answer was directly counter-productive.
>
> I still think 'portable assembly' is good (to understand C).
>
Then you are still wrong.
People that read the standards that define the C language tell you you
are wrong. People that work with a wide variety of C compilers tell you
that you are wrong. People that write C compilers tell you that you are
wrong. What makes you think that you know better? You haven't given
the slightest evidence for any of your "portable assembly" claims, and
ignored the reality of the defining document and of real-world compilers.
This article series is worth reading - it is written by one of the lead
LLVM/clang developers:
<https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>
Try out compilers here:
<https://godbolt.org/z/azq9oTv6E>
You'll see a variety of different results. Some compilers /will/
generate an "add" instruction - others will not. gcc takes a "safe"
option of always returning 0, clang gives a minimal "ret". The source
code is UB, and no results are guaranteed.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-05-02 19:59 +0800 |
| Message-ID | <97a1c40bf71cfe8edab25d5ac8a1ad435c3995e5.camel@gmail.com> |
| In reply to | #398172 |
On Sat, 2026-05-02 at 11:58 +0200, David Brown wrote:
> On 02/05/2026 06:32, wij wrote:
> > On Thu, 2026-04-30 at 14:04 +0200, David Brown wrote:
> > > On 30/04/2026 13:35, wij wrote:
> > > > On Thu, 2026-04-30 at 10:47 +0200, David Brown wrote:
> > > > > On 30/04/2026 02:39, Kalevi Kolttonen wrote:
> > > > > > Hello!
> > > > > >
> > > > > > A simple question and yes, I know I could ask AI bots
> > > > > > but the problem is that I cannot always trust their
> > > > > > responses.
> > > > > >
> > > > > > Is it always safe and not undefined behavior to do:
> > > > > >
> > > > > > int i;
> > > > > > long l;
> > > > > > i = (int)l;
> > > > > >
> > > > > > as long as you have first veried that 'l' is within
> > > > > > the range between INT_MIN and INT_MAX? Thanks.
> > > > > >
> > > > > > br,
> > > > > > KK
> > > > >
> > > > > Others have given you the answer to your question. Asking here will get
> > > > > you accurate answers (James, Keith and Tim are all experts at the
> > > > > details of C), while AI may or may not be correct at this kind of thing.
> > > > > There are a lot of people who misunderstand the subtleties of C,
> > > > > especially when you are asking what the standards actually say rather
> > > > > than just what is likely to work on a particular compiler. When people
> > > > > write the kind of nonsense wij does, AI "learns" from them too, and can
> > > > > regurgitate the same mistakes.
> > > >
> > > > What mistake? Can compiler generate code other than "i=(int)l;" appears to be?
> > > >
> > > > I did not write C program for >30 years, something might be missed. So, what
> > > > would this expert say?
> > > >
> > >
> > > Experts would /not/ say "C is portable assembly". When asked a question
> > > about the guaranteed meaning of something in C (rather than the likely
> > > behaviour of some particular compiler), they would /not/ say "don't
> > > over-interpret what the C standard says". They would /not/ be asking
> > > some AI for answers here.
> >
> > The problem with 'legal terms' is it is abstract (I think the main audience
> > of the standard is compiler implementer). Using it too much to explain C would
> > make the analysis like what 'TV expert' provides, lots of professional-looking
> > terms but no real substance inside. E.g.
>
> You are completely wrong.
>
> The C standards provide a contract between the compiler implementers,
> and compiler users - C programmers. Both parties need to understand the
> C standards.
>
> Of course a C compiler implementer will need to read the whole standard
> thoroughly and understand it in great detail. A typical C user does not
> need such complete knowledge. For example, I don't have use of floating
> point in my code other than "approximating real number calculations" - I
> haven't read the details of handling of NaNs, floating point exceptions,
> etc., because they are not relevant to my work and not of particular
> interest to me. Other parts of the standards I have studied more carefully.
>
> Many C programmers never bother reading the C standards at all. But
> they should all refer back to them. What happens when your signed
> integer arithmetic overflows? A good C programmer knows it is UB, and
> anything can happen - including nasal daemons, or the compiler skipping
> code, so they avoid letting it happen in their code. They know it is UB
> because they know the standard says it is UB - even if they have not
> read the standard. It is how the language is defined. They may get
> their knowledge of the C standards indirectly, from books, courses,
> websites, questions and answers in a forum like this, but it all traces
> back to the standards.
>
> >
> > int F() {
> > int a,b;
> > return a+b; // UB?
> > }
> >
> > 1. F is standard conforming as long as F does not mean to portably return
> > the value of the sum of a and b.
>
> No. Reading and using the value of an uninitialised variable is UB.
> (It is not UB to define and compile the function F here - it is UB to
> call it at runtime.) The code is clearly nonsense - "take two numbers
> from nowhere, add them, and return the sum". I don't know if there is a
> good word for writing meaningless text that happens to match the syntax
> of a programming language, but it is certainly not "programming".
>
> > 2. If the compiler translates the last line to "return a*b;", I am afraid such
> > translation is not rejected as non-standardare conforming, i.e. "a*b" is
> > still likely standard conforming from the common rule I read.
> >
>
> The compiler can translate the code into anything it likes - including a
> system call to format your harddrive. (Again, the UB - and thus the
> drive format - is only if F() is actually called at runtime.) Ignoring
> the DS9000 compiler, real compilers use knowledge of UB to generate
> smaller and faster code in the event that the UB is not called. Thus a
> typical implementation from a compiler might be "F: ret" - do nothing at
> all. Other possibilities include generating code to aid debugging and
> fault-finding, such as "F: trap" (or "F: ub2" in x86 assembly). A
> minimal implementation, "F: " that simple runs on to whatever is in
> memory after that label, is also fine.
>
> > > You were correct that the behaviour of the conversion is defined - the
> > > rest of your answer was directly counter-productive.
> >
> > I still think 'portable assembly' is good (to understand C).
> >
>
> Then you are still wrong.
>
> People that read the standards that define the C language tell you you
> are wrong. People that work with a wide variety of C compilers tell you
> that you are wrong. People that write C compilers tell you that you are
> wrong. What makes you think that you know better? You haven't given
> the slightest evidence for any of your "portable assembly" claims, and
> ignored the reality of the defining document and of real-world compilers.
>
> This article series is worth reading - it is written by one of the lead
> LLVM/clang developers:
>
> <https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>
>
int F3() {
int a=2;
return a*INT_MAX; // UB? Compiler can replace this line with anything?
};
I asked the above example to LLM, it says: "...Once the compiler detects UB, it
is no longer bound by the rules of the C language for that execution path."
I buy what the LLM said to me so far (roughly the same as in the idea you tried
to convey). C is no more an imperative language as I used to thought.
Back to the F3 example above, I can't believe how many programs really check
overflows to prevent UB, a burdensome task?
> Try out compilers here:
>
> <https://godbolt.org/z/azq9oTv6E>
>
> You'll see a variety of different results. Some compilers /will/
> generate an "add" instruction - others will not. gcc takes a "safe"
> option of always returning 0, clang gives a minimal "ret". The source
> code is UB, and no results are guaranteed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-02 15:13 +0200 |
| Message-ID | <10t4t8v$25van$1@dont-email.me> |
| In reply to | #398173 |
On 02/05/2026 13:59, wij wrote:
> On Sat, 2026-05-02 at 11:58 +0200, David Brown wrote:
>> On 02/05/2026 06:32, wij wrote:
>>> On Thu, 2026-04-30 at 14:04 +0200, David Brown wrote:
>>>> On 30/04/2026 13:35, wij wrote:
>>>>> On Thu, 2026-04-30 at 10:47 +0200, David Brown wrote:
>>>>>> On 30/04/2026 02:39, Kalevi Kolttonen wrote:
>>>>>>> Hello!
>>>>>>>
>>>>>>> A simple question and yes, I know I could ask AI bots
>>>>>>> but the problem is that I cannot always trust their
>>>>>>> responses.
>>>>>>>
>>>>>>> Is it always safe and not undefined behavior to do:
>>>>>>>
>>>>>>> int i;
>>>>>>> long l;
>>>>>>> i = (int)l;
>>>>>>>
>>>>>>> as long as you have first veried that 'l' is within
>>>>>>> the range between INT_MIN and INT_MAX? Thanks.
>>>>>>>
>>>>>>> br,
>>>>>>> KK
>>>>>>
>>>>>> Others have given you the answer to your question. Asking here will get
>>>>>> you accurate answers (James, Keith and Tim are all experts at the
>>>>>> details of C), while AI may or may not be correct at this kind of thing.
>>>>>> There are a lot of people who misunderstand the subtleties of C,
>>>>>> especially when you are asking what the standards actually say rather
>>>>>> than just what is likely to work on a particular compiler. When people
>>>>>> write the kind of nonsense wij does, AI "learns" from them too, and can
>>>>>> regurgitate the same mistakes.
>>>>>
>>>>> What mistake? Can compiler generate code other than "i=(int)l;" appears to be?
>>>>>
>>>>> I did not write C program for >30 years, something might be missed. So, what
>>>>> would this expert say?
>>>>>
>>>>
>>>> Experts would /not/ say "C is portable assembly". When asked a question
>>>> about the guaranteed meaning of something in C (rather than the likely
>>>> behaviour of some particular compiler), they would /not/ say "don't
>>>> over-interpret what the C standard says". They would /not/ be asking
>>>> some AI for answers here.
>>>
>>> The problem with 'legal terms' is it is abstract (I think the main audience
>>> of the standard is compiler implementer). Using it too much to explain C would
>>> make the analysis like what 'TV expert' provides, lots of professional-looking
>>> terms but no real substance inside. E.g.
>>
>> You are completely wrong.
>>
>> The C standards provide a contract between the compiler implementers,
>> and compiler users - C programmers. Both parties need to understand the
>> C standards.
>>
>> Of course a C compiler implementer will need to read the whole standard
>> thoroughly and understand it in great detail. A typical C user does not
>> need such complete knowledge. For example, I don't have use of floating
>> point in my code other than "approximating real number calculations" - I
>> haven't read the details of handling of NaNs, floating point exceptions,
>> etc., because they are not relevant to my work and not of particular
>> interest to me. Other parts of the standards I have studied more carefully.
>>
>> Many C programmers never bother reading the C standards at all. But
>> they should all refer back to them. What happens when your signed
>> integer arithmetic overflows? A good C programmer knows it is UB, and
>> anything can happen - including nasal daemons, or the compiler skipping
>> code, so they avoid letting it happen in their code. They know it is UB
>> because they know the standard says it is UB - even if they have not
>> read the standard. It is how the language is defined. They may get
>> their knowledge of the C standards indirectly, from books, courses,
>> websites, questions and answers in a forum like this, but it all traces
>> back to the standards.
>>
>>>
>>> int F() {
>>> int a,b;
>>> return a+b; // UB?
>>> }
>>>
>>> 1. F is standard conforming as long as F does not mean to portably return
>>> the value of the sum of a and b.
>>
>> No. Reading and using the value of an uninitialised variable is UB.
>> (It is not UB to define and compile the function F here - it is UB to
>> call it at runtime.) The code is clearly nonsense - "take two numbers
>> from nowhere, add them, and return the sum". I don't know if there is a
>> good word for writing meaningless text that happens to match the syntax
>> of a programming language, but it is certainly not "programming".
>>
>>> 2. If the compiler translates the last line to "return a*b;", I am afraid such
>>> translation is not rejected as non-standardare conforming, i.e. "a*b" is
>>> still likely standard conforming from the common rule I read.
>>>
>>
>> The compiler can translate the code into anything it likes - including a
>> system call to format your harddrive. (Again, the UB - and thus the
>> drive format - is only if F() is actually called at runtime.) Ignoring
>> the DS9000 compiler, real compilers use knowledge of UB to generate
>> smaller and faster code in the event that the UB is not called. Thus a
>> typical implementation from a compiler might be "F: ret" - do nothing at
>> all. Other possibilities include generating code to aid debugging and
>> fault-finding, such as "F: trap" (or "F: ub2" in x86 assembly). A
>> minimal implementation, "F: " that simple runs on to whatever is in
>> memory after that label, is also fine.
>>
>>>> You were correct that the behaviour of the conversion is defined - the
>>>> rest of your answer was directly counter-productive.
>>>
>>> I still think 'portable assembly' is good (to understand C).
>>>
>>
>> Then you are still wrong.
>>
>> People that read the standards that define the C language tell you you
>> are wrong. People that work with a wide variety of C compilers tell you
>> that you are wrong. People that write C compilers tell you that you are
>> wrong. What makes you think that you know better? You haven't given
>> the slightest evidence for any of your "portable assembly" claims, and
>> ignored the reality of the defining document and of real-world compilers.
>>
>> This article series is worth reading - it is written by one of the lead
>> LLVM/clang developers:
>>
>> <https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>
>>
>
> int F3() {
> int a=2;
> return a*INT_MAX; // UB? Compiler can replace this line with anything?
> };
>
> I asked the above example to LLM, it says: "...Once the compiler detects UB, it
> is no longer bound by the rules of the C language for that execution path."
> I buy what the LLM said to me so far (roughly the same as in the idea you tried
> to convey). C is no more an imperative language as I used to thought.
LLM's are not a reliable source of knowledge or information (though they
can give some ideas that you can then use to look up details). But in
this case, it is correct.
C is very much an imperative language. But perhaps you don't know what
that means (or at least, don't understand the implications). An
imperative programming language means you state a list of things that
the program should do - it is a focus on how the program should run, as
distinct from declarative programming that focuses on describing the
results you want. However, programs in high level languages are "run"
on an abstract machine - the generated code does not have to simulate it
instruction-for-instruction on the target processor. It merely has to
match up the results at particular points - "observable behaviour" in C
terminology.
That means if you write "x + x + x", the compiler can generate
instructions for "3 * x" in the code. Equally, if you write "3 * x" and
the target processor does not have a hardware multiplication
instruction, the compiler can generate a call to a library function or
two additional operations. The programming language is still
imperative, but it takes your list of instructions and generates code
that has the same effect.
And since "2 * INT_MAX" has no meaningful effect, the compiler can do
what it wants with it - while remaining an imperative language.
>
> Back to the F3 example above, I can't believe how many programs really check
> overflows to prevent UB, a burdensome task?
>
People do not usually check for overflows in their integer arithmetic -
a far better idea is usually to use types that are big enough that you
won't see overflows. Validate data coming into the program from
outside, and write code that will give the correct answer for valid
inputs. Then you don't need to check for overflow.
So if you have a program that finds the average age of kids in a school
class, you will probably want to do that by adding up the ages and
dividing by the number of kids. Decide on limits for your data -
perhaps you limit kids ages to 20 and class sizes to 100. Validate the
data coming in, and you know your sum will never exceed 20,000 - a sum
type of "int16_t" will be fine. Your program won't work for finding the
average age of students at a university, but that's not what it was made
for - extending it means identifying and specifying new limits, and
changing data types appropriately.
In my 30+ years of professional programming, much of it in C, I don't
remember ever having specifically coded a "check for integer arithmetic
overflow". I also don't remember ever having had an integer overflow
bug. I have, however, often written checks for sane data before doing
calculations.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-05-02 22:32 +0800 |
| Message-ID | <cf1673b2d5ba4423e4504e30a201ec90c3e0267c.camel@gmail.com> |
| In reply to | #398174 |
On Sat, 2026-05-02 at 15:13 +0200, David Brown wrote:
> On 02/05/2026 13:59, wij wrote:
> > On Sat, 2026-05-02 at 11:58 +0200, David Brown wrote:
> > > On 02/05/2026 06:32, wij wrote:
> > > > On Thu, 2026-04-30 at 14:04 +0200, David Brown wrote:
> > > > > On 30/04/2026 13:35, wij wrote:
> > > > > > On Thu, 2026-04-30 at 10:47 +0200, David Brown wrote:
> > > > > > > On 30/04/2026 02:39, Kalevi Kolttonen wrote:
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > A simple question and yes, I know I could ask AI bots
> > > > > > > > but the problem is that I cannot always trust their
> > > > > > > > responses.
> > > > > > > >
> > > > > > > > Is it always safe and not undefined behavior to do:
> > > > > > > >
> > > > > > > > int i;
> > > > > > > > long l;
> > > > > > > > i = (int)l;
> > > > > > > >
> > > > > > > > as long as you have first veried that 'l' is within
> > > > > > > > the range between INT_MIN and INT_MAX? Thanks.
> > > > > > > >
> > > > > > > > br,
> > > > > > > > KK
> > > > > > >
> > > > > > > Others have given you the answer to your question. Asking here will get
> > > > > > > you accurate answers (James, Keith and Tim are all experts at the
> > > > > > > details of C), while AI may or may not be correct at this kind of thing.
> > > > > > > There are a lot of people who misunderstand the subtleties of C,
> > > > > > > especially when you are asking what the standards actually say rather
> > > > > > > than just what is likely to work on a particular compiler. When people
> > > > > > > write the kind of nonsense wij does, AI "learns" from them too, and can
> > > > > > > regurgitate the same mistakes.
> > > > > >
> > > > > > What mistake? Can compiler generate code other than "i=(int)l;" appears to be?
> > > > > >
> > > > > > I did not write C program for >30 years, something might be missed. So, what
> > > > > > would this expert say?
> > > > > >
> > > > >
> > > > > Experts would /not/ say "C is portable assembly". When asked a question
> > > > > about the guaranteed meaning of something in C (rather than the likely
> > > > > behaviour of some particular compiler), they would /not/ say "don't
> > > > > over-interpret what the C standard says". They would /not/ be asking
> > > > > some AI for answers here.
> > > >
> > > > The problem with 'legal terms' is it is abstract (I think the main audience
> > > > of the standard is compiler implementer). Using it too much to explain C would
> > > > make the analysis like what 'TV expert' provides, lots of professional-looking
> > > > terms but no real substance inside. E.g.
> > >
> > > You are completely wrong.
> > >
> > > The C standards provide a contract between the compiler implementers,
> > > and compiler users - C programmers. Both parties need to understand the
> > > C standards.
> > >
> > > Of course a C compiler implementer will need to read the whole standard
> > > thoroughly and understand it in great detail. A typical C user does not
> > > need such complete knowledge. For example, I don't have use of floating
> > > point in my code other than "approximating real number calculations" - I
> > > haven't read the details of handling of NaNs, floating point exceptions,
> > > etc., because they are not relevant to my work and not of particular
> > > interest to me. Other parts of the standards I have studied more carefully.
> > >
> > > Many C programmers never bother reading the C standards at all. But
> > > they should all refer back to them. What happens when your signed
> > > integer arithmetic overflows? A good C programmer knows it is UB, and
> > > anything can happen - including nasal daemons, or the compiler skipping
> > > code, so they avoid letting it happen in their code. They know it is UB
> > > because they know the standard says it is UB - even if they have not
> > > read the standard. It is how the language is defined. They may get
> > > their knowledge of the C standards indirectly, from books, courses,
> > > websites, questions and answers in a forum like this, but it all traces
> > > back to the standards.
> > >
> > > >
> > > > int F() {
> > > > int a,b;
> > > > return a+b; // UB?
> > > > }
> > > >
> > > > 1. F is standard conforming as long as F does not mean to portably return
> > > > the value of the sum of a and b.
> > >
> > > No. Reading and using the value of an uninitialised variable is UB.
> > > (It is not UB to define and compile the function F here - it is UB to
> > > call it at runtime.) The code is clearly nonsense - "take two numbers
> > > from nowhere, add them, and return the sum". I don't know if there is a
> > > good word for writing meaningless text that happens to match the syntax
> > > of a programming language, but it is certainly not "programming".
> > >
> > > > 2. If the compiler translates the last line to "return a*b;", I am afraid such
> > > > translation is not rejected as non-standardare conforming, i.e. "a*b" is
> > > > still likely standard conforming from the common rule I read.
> > > >
> > >
> > > The compiler can translate the code into anything it likes - including a
> > > system call to format your harddrive. (Again, the UB - and thus the
> > > drive format - is only if F() is actually called at runtime.) Ignoring
> > > the DS9000 compiler, real compilers use knowledge of UB to generate
> > > smaller and faster code in the event that the UB is not called. Thus a
> > > typical implementation from a compiler might be "F: ret" - do nothing at
> > > all. Other possibilities include generating code to aid debugging and
> > > fault-finding, such as "F: trap" (or "F: ub2" in x86 assembly). A
> > > minimal implementation, "F: " that simple runs on to whatever is in
> > > memory after that label, is also fine.
> > >
> > > > > You were correct that the behaviour of the conversion is defined - the
> > > > > rest of your answer was directly counter-productive.
> > > >
> > > > I still think 'portable assembly' is good (to understand C).
> > > >
> > >
> > > Then you are still wrong.
> > >
> > > People that read the standards that define the C language tell you you
> > > are wrong. People that work with a wide variety of C compilers tell you
> > > that you are wrong. People that write C compilers tell you that you are
> > > wrong. What makes you think that you know better? You haven't given
> > > the slightest evidence for any of your "portable assembly" claims, and
> > > ignored the reality of the defining document and of real-world compilers.
> > >
> > > This article series is worth reading - it is written by one of the lead
> > > LLVM/clang developers:
> > >
> > > <https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>
> > >
> >
> > int F3() {
> > int a=2;
> > return a*INT_MAX; // UB? Compiler can replace this line with anything?
> > };
> >
> > I asked the above example to LLM, it says: "...Once the compiler detects UB, it
> > is no longer bound by the rules of the C language for that execution path."
> > I buy what the LLM said to me so far (roughly the same as in the idea you tried
> > to convey). C is no more an imperative language as I used to thought.
>
> LLM's are not a reliable source of knowledge or information (though they
> can give some ideas that you can then use to look up details). But in
> this case, it is correct.
>
> C is very much an imperative language. But perhaps you don't know what
> that means (or at least, don't understand the implications). An
> imperative programming language means you state a list of things that
> the program should do - it is a focus on how the program should run, as
> distinct from declarative programming that focuses on describing the
> results you want. However, programs in high level languages are "run"
> on an abstract machine - the generated code does not have to simulate it
> instruction-for-instruction on the target processor. It merely has to
> match up the results at particular points - "observable behaviour" in C
> terminology.
What does "abstract machine" mean exactly? What is the "observable behaviour"
of the "abstract machine"? I don't expect the answer, it just terms relying on
another terms...
> That means if you write "x + x + x", the compiler can generate
> instructions for "3 * x" in the code. Equally, if you write "3 * x" and
> the target processor does not have a hardware multiplication
> instruction, the compiler can generate a call to a library function or
> two additional operations. The programming language is still
> imperative, but it takes your list of instructions and generates code
> that has the same effect.
>
> And since "2 * INT_MAX" has no meaningful effect, the compiler can do
> what it wants with it - while remaining an imperative language.
I see UB as a feature that compiler can silently change the behavior of a
detected error. C now can do things in back (in the name of optimization)!
> >
> > Back to the F3 example above, I can't believe how many programs really check
> > overflows to prevent UB, a burdensome task?
> >
>
> People do not usually check for overflows in their integer arithmetic -
> a far better idea is usually to use types that are big enough that you
> won't see overflows. Validate data coming into the program from
> outside, and write code that will give the correct answer for valid
> inputs. Then you don't need to check for overflow.
>
> So if you have a program that finds the average age of kids in a school
> class, you will probably want to do that by adding up the ages and
> dividing by the number of kids. Decide on limits for your data -
> perhaps you limit kids ages to 20 and class sizes to 100. Validate the
> data coming in, and you know your sum will never exceed 20,000 - a sum
> type of "int16_t" will be fine. Your program won't work for finding the
> average age of students at a university, but that's not what it was made
> for - extending it means identifying and specifying new limits, and
> changing data types appropriately.
>
> In my 30+ years of professional programming, much of it in C, I don't
> remember ever having specifically coded a "check for integer arithmetic
> overflow". I also don't remember ever having had an integer overflow
> bug. I have, however, often written checks for sane data before doing
> calculations.
There are lots cases arithmetic ops can overflow. Library codes need to check
them all. That leads to that any function should do the same if it want to be
reusable.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-02 17:17 +0200 |
| Message-ID | <10t54is$28gto$1@dont-email.me> |
| In reply to | #398177 |
On 02/05/2026 16:32, wij wrote:
> On Sat, 2026-05-02 at 15:13 +0200, David Brown wrote:
>> On 02/05/2026 13:59, wij wrote:
>>> On Sat, 2026-05-02 at 11:58 +0200, David Brown wrote:
>>>> On 02/05/2026 06:32, wij wrote:
>>>>> On Thu, 2026-04-30 at 14:04 +0200, David Brown wrote:
>>>>>> On 30/04/2026 13:35, wij wrote:
>>>>>>> On Thu, 2026-04-30 at 10:47 +0200, David Brown wrote:
>>>>>>>> On 30/04/2026 02:39, Kalevi Kolttonen wrote:
>>>>>>>>> Hello!
>>>>>>>>>
>>>>>>>>> A simple question and yes, I know I could ask AI bots
>>>>>>>>> but the problem is that I cannot always trust their
>>>>>>>>> responses.
>>>>>>>>>
>>>>>>>>> Is it always safe and not undefined behavior to do:
>>>>>>>>>
>>>>>>>>> int i;
>>>>>>>>> long l;
>>>>>>>>> i = (int)l;
>>>>>>>>>
>>>>>>>>> as long as you have first veried that 'l' is within
>>>>>>>>> the range between INT_MIN and INT_MAX? Thanks.
>>>>>>>>>
>>>>>>>>> br,
>>>>>>>>> KK
>>>>>>>>
>>>>>>>> Others have given you the answer to your question. Asking here will get
>>>>>>>> you accurate answers (James, Keith and Tim are all experts at the
>>>>>>>> details of C), while AI may or may not be correct at this kind of thing.
>>>>>>>> There are a lot of people who misunderstand the subtleties of C,
>>>>>>>> especially when you are asking what the standards actually say rather
>>>>>>>> than just what is likely to work on a particular compiler. When people
>>>>>>>> write the kind of nonsense wij does, AI "learns" from them too, and can
>>>>>>>> regurgitate the same mistakes.
>>>>>>>
>>>>>>> What mistake? Can compiler generate code other than "i=(int)l;" appears to be?
>>>>>>>
>>>>>>> I did not write C program for >30 years, something might be missed. So, what
>>>>>>> would this expert say?
>>>>>>>
>>>>>>
>>>>>> Experts would /not/ say "C is portable assembly". When asked a question
>>>>>> about the guaranteed meaning of something in C (rather than the likely
>>>>>> behaviour of some particular compiler), they would /not/ say "don't
>>>>>> over-interpret what the C standard says". They would /not/ be asking
>>>>>> some AI for answers here.
>>>>>
>>>>> The problem with 'legal terms' is it is abstract (I think the main audience
>>>>> of the standard is compiler implementer). Using it too much to explain C would
>>>>> make the analysis like what 'TV expert' provides, lots of professional-looking
>>>>> terms but no real substance inside. E.g.
>>>>
>>>> You are completely wrong.
>>>>
>>>> The C standards provide a contract between the compiler implementers,
>>>> and compiler users - C programmers. Both parties need to understand the
>>>> C standards.
>>>>
>>>> Of course a C compiler implementer will need to read the whole standard
>>>> thoroughly and understand it in great detail. A typical C user does not
>>>> need such complete knowledge. For example, I don't have use of floating
>>>> point in my code other than "approximating real number calculations" - I
>>>> haven't read the details of handling of NaNs, floating point exceptions,
>>>> etc., because they are not relevant to my work and not of particular
>>>> interest to me. Other parts of the standards I have studied more carefully.
>>>>
>>>> Many C programmers never bother reading the C standards at all. But
>>>> they should all refer back to them. What happens when your signed
>>>> integer arithmetic overflows? A good C programmer knows it is UB, and
>>>> anything can happen - including nasal daemons, or the compiler skipping
>>>> code, so they avoid letting it happen in their code. They know it is UB
>>>> because they know the standard says it is UB - even if they have not
>>>> read the standard. It is how the language is defined. They may get
>>>> their knowledge of the C standards indirectly, from books, courses,
>>>> websites, questions and answers in a forum like this, but it all traces
>>>> back to the standards.
>>>>
>>>>>
>>>>> int F() {
>>>>> int a,b;
>>>>> return a+b; // UB?
>>>>> }
>>>>>
>>>>> 1. F is standard conforming as long as F does not mean to portably return
>>>>> the value of the sum of a and b.
>>>>
>>>> No. Reading and using the value of an uninitialised variable is UB.
>>>> (It is not UB to define and compile the function F here - it is UB to
>>>> call it at runtime.) The code is clearly nonsense - "take two numbers
>>>> from nowhere, add them, and return the sum". I don't know if there is a
>>>> good word for writing meaningless text that happens to match the syntax
>>>> of a programming language, but it is certainly not "programming".
>>>>
>>>>> 2. If the compiler translates the last line to "return a*b;", I am afraid such
>>>>> translation is not rejected as non-standardare conforming, i.e. "a*b" is
>>>>> still likely standard conforming from the common rule I read.
>>>>>
>>>>
>>>> The compiler can translate the code into anything it likes - including a
>>>> system call to format your harddrive. (Again, the UB - and thus the
>>>> drive format - is only if F() is actually called at runtime.) Ignoring
>>>> the DS9000 compiler, real compilers use knowledge of UB to generate
>>>> smaller and faster code in the event that the UB is not called. Thus a
>>>> typical implementation from a compiler might be "F: ret" - do nothing at
>>>> all. Other possibilities include generating code to aid debugging and
>>>> fault-finding, such as "F: trap" (or "F: ub2" in x86 assembly). A
>>>> minimal implementation, "F: " that simple runs on to whatever is in
>>>> memory after that label, is also fine.
>>>>
>>>>>> You were correct that the behaviour of the conversion is defined - the
>>>>>> rest of your answer was directly counter-productive.
>>>>>
>>>>> I still think 'portable assembly' is good (to understand C).
>>>>>
>>>>
>>>> Then you are still wrong.
>>>>
>>>> People that read the standards that define the C language tell you you
>>>> are wrong. People that work with a wide variety of C compilers tell you
>>>> that you are wrong. People that write C compilers tell you that you are
>>>> wrong. What makes you think that you know better? You haven't given
>>>> the slightest evidence for any of your "portable assembly" claims, and
>>>> ignored the reality of the defining document and of real-world compilers.
>>>>
>>>> This article series is worth reading - it is written by one of the lead
>>>> LLVM/clang developers:
>>>>
>>>> <https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>
>>>>
>>>
>>> int F3() {
>>> int a=2;
>>> return a*INT_MAX; // UB? Compiler can replace this line with anything?
>>> };
>>>
>>> I asked the above example to LLM, it says: "...Once the compiler detects UB, it
>>> is no longer bound by the rules of the C language for that execution path."
>>> I buy what the LLM said to me so far (roughly the same as in the idea you tried
>>> to convey). C is no more an imperative language as I used to thought.
>>
>> LLM's are not a reliable source of knowledge or information (though they
>> can give some ideas that you can then use to look up details). But in
>> this case, it is correct.
>>
>> C is very much an imperative language. But perhaps you don't know what
>> that means (or at least, don't understand the implications). An
>> imperative programming language means you state a list of things that
>> the program should do - it is a focus on how the program should run, as
>> distinct from declarative programming that focuses on describing the
>> results you want. However, programs in high level languages are "run"
>> on an abstract machine - the generated code does not have to simulate it
>> instruction-for-instruction on the target processor. It merely has to
>> match up the results at particular points - "observable behaviour" in C
>> terminology.
>
> What does "abstract machine" mean exactly? What is the "observable behaviour"
> of the "abstract machine"? I don't expect the answer, it just terms relying on
> another terms...
>
This is a voluntary forum, so you can never /expect/ answers - but you
can certainly hope for them when you ask a reasonable question!
The terms "abstract machine" and "observable behaviour" are from the C
standards. In C, the meaning of a program is as though it were run on a
hypothetical "abstract machine" that follows the instructions in the
code. (This is distinct from an assembly language, that is defined in
terms of the behaviour on an actual processor.) "Observable behaviour"
is basically inputs and outputs of the program, along with "volatile"
accesses - program start and stop, printf output, file IO, etc.
Internal calculations, functions and variables that are not directly
connected to IO and do not use volatile accesses, are not "observable".
That means if you have code like :
int x, y;
int foo(int a) {
x = a;
y = 2;
int z = x * y;
y = z - a;
return y - a;
}
the compiler can treat it as :
int foo(int a) {
x = a;
y = a;
return 0;
}
Note that the two writes to "y" are combined - the individual writes are
not observable, but some other part of the program might read "y" later.
(The compiler has to assume that any code it can't see, has observable
behaviour - it can only optimise what it can see at the time.)
But if "y" had been declared "volatile int y;", then the writes to "y"
/would/ be observable behaviour, and both writes would have to be generated.
>> That means if you write "x + x + x", the compiler can generate
>> instructions for "3 * x" in the code. Equally, if you write "3 * x" and
>> the target processor does not have a hardware multiplication
>> instruction, the compiler can generate a call to a library function or
>> two additional operations. The programming language is still
>> imperative, but it takes your list of instructions and generates code
>> that has the same effect.
>>
>> And since "2 * INT_MAX" has no meaningful effect, the compiler can do
>> what it wants with it - while remaining an imperative language.
>
> I see UB as a feature that compiler can silently change the behavior of a
> detected error. C now can do things in back (in the name of optimization)!
UB simply means that there is no specification or requirement for
behaviour, thus any behaviour (or lack thereof) fits the requirements.
You can think of writing things like "a * b" as telling the compiler "I
promise that the values of "a" and "b" here will be such that "a * b"
does not overflow - and I want you to give me the best generated code
with that assumption". You can alternatively think of it as saying
"give me the result of "a * b" if that is in the range of "int", and I
don't care what happens if it is outside that range".
Some people think it is "wrong" for a compiler to optimise on the
assumption that UB does not occur. Usually when trying to express what
they think a compiler should be allowed to do, and what it should not be
allowed to do, they fail to provide any kind of consistent or rational
dividing line.
From the viewpoint of a C programmer, therefore, you should assume that
compilers can do absolutely anything if they encounter UB, and make no
assumptions about the kind of code or results you get from it. (If
compiler documentation says that particular types of code have
particular behaviour, that's a different matter - then the code is not
portable, but not UB on that compiler.)
>
>>>
>>> Back to the F3 example above, I can't believe how many programs really check
>>> overflows to prevent UB, a burdensome task?
>>>
>>
>> People do not usually check for overflows in their integer arithmetic -
>> a far better idea is usually to use types that are big enough that you
>> won't see overflows. Validate data coming into the program from
>> outside, and write code that will give the correct answer for valid
>> inputs. Then you don't need to check for overflow.
>>
>> So if you have a program that finds the average age of kids in a school
>> class, you will probably want to do that by adding up the ages and
>> dividing by the number of kids. Decide on limits for your data -
>> perhaps you limit kids ages to 20 and class sizes to 100. Validate the
>> data coming in, and you know your sum will never exceed 20,000 - a sum
>> type of "int16_t" will be fine. Your program won't work for finding the
>> average age of students at a university, but that's not what it was made
>> for - extending it means identifying and specifying new limits, and
>> changing data types appropriately.
>>
>> In my 30+ years of professional programming, much of it in C, I don't
>> remember ever having specifically coded a "check for integer arithmetic
>> overflow". I also don't remember ever having had an integer overflow
>> bug. I have, however, often written checks for sane data before doing
>> calculations.
>
> There are lots cases arithmetic ops can overflow. Library codes need to check
> them all. That leads to that any function should do the same if it want to be
> reusable.
>
No, libraries don't need to check for overflow everywhere. It's fine
for a library to say "function "foo" only works if called with a value
between 0 and 1000" - then it is the caller's responsibility to make
sure it is called with an appropriate value, and the library
implementation can assume the value is appropriate and have runtime UB
in other cases.
Of course it is often helpful if functions do more checking at major
boundaries, like library API's. That can limit the consequences of
mistakes in the calling code, and help people find faults in their
programs. But it is the caller's responsibility to make sure the inputs
to a function call are appropriate.
If you buy a T-shirt and it says "maximum washing temperature 40 C",
then washing it at 60 C is undefined behaviour as far as the T-shirt is
concerned. Maybe it will be fine, maybe its colour will fade, maybe its
fabric will dissolve and clog your drains. The T-shirt manufacturer has
no obligation to add a temperature sensor that sets off an alarm at 45 C.
People often seem to think UB is a concept from C programming, and only
for C programming - it is not. It is everywhere.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-05-02 16:56 -0400 |
| Message-ID | <10t5oeo$2e8t8$1@dont-email.me> |
| In reply to | #398179 |
On 2026-05-02 11:17, David Brown wrote: ... > terms of the behaviour on an actual processor.) "Observable behaviour" > is basically inputs and outputs of the program, along with "volatile" > accesses - program start and stop, printf output, file IO, etc. An important point, which I'm sure you understand, but wij probably doesn't: "observerable behavior" is a piece of specialized jargon whose definition is provided by the C standard. It does not have it's ordinary English meaning of "behavior which can be observed". For instance, how quickly a program executes is behavior which can trivially be observed, but it does not qualify as "observable behavior" as defined by the C standard. If your software or hardware is suitably instrumented, which actual instructions are executed and what values the registers contain could be observed - but again, that does not make them qualify as "observable behavior". Oddly enough, the standard makes almost no use of the term "observable behavior" other than defining what the term means. What it says about observable behavior, it says during the listing of what counts as observable behavior, and it says that about the list, not about the term defined by that list. The term is defined merely as a convenient way of referring to the itemized list of things to which those rules apply.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-03 20:11 -0700 |
| Message-ID | <86o6ivyilp.fsf@linuxsc.com> |
| In reply to | #398187 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: [...] > Oddly enough, the standard makes almost no use of the term "observable > behavior" other than defining what the term means. What it says about > observable behavior, it says during the listing of what counts as > observable behavior, and it says that about the list, not about the > term defined by that list. The term is defined merely as a convenient > way of referring to the itemized list of things to which those rules > apply. Didn't this change in N3220 (or perhaps an earlier draft)? Certainly it looks like it did, comparing N3220 to earlier versions of the standard.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-02 14:35 -0700 |
| Message-ID | <10t5qne$2elg5$1@kst.eternal-september.org> |
| In reply to | #398179 |
David Brown <david.brown@hesbynett.no> writes:
> On 02/05/2026 16:32, wij wrote:
[...]
>> What does "abstract machine" mean exactly? What is the "observable
>> behaviour" of the "abstract machine"? I don't expect the answer, it
>> just terms relying on another terms...
The phrase "abstract machine" doesn't have a formal definition in
the standard (it's not in the glossary and isn't shown in italics).
The phrase "observable behavior" is defined.
Both are discussed in the "Program semantics" subsection of the
standard (N3220 5.1.2.4; the subsection number might differ in
other editions). It discusses the differences between the abstract
machine and what's permitted in actual implementations. Anyone who
cares about these terms should read it.
> This is a voluntary forum, so you can never /expect/ answers - but you
> can certainly hope for them when you ask a reasonable question!
>
> The terms "abstract machine" and "observable behaviour" are from the C
> standards. In C, the meaning of a program is as though it were run on
> a hypothetical "abstract machine" that follows the instructions in the
> code.
I suggest that "instructions" is a poor word choice. It could imply CPU
instructions, which the C standard doesn't discuss, even in reference to
the abstract machine.
> (This is distinct from an assembly language, that is defined in
> terms of the behaviour on an actual processor.)
My understanding is that an assembly language says nothing about
run-time behavior. It defines a mapping from assembly language
source code to machine code, which includes CPU instructions.
The behavior of the CPU instructions is specified by the CPU
architecture. If a new version of a CPU changes the behavior of
an instruction, that change doesn't affect an assembler.
[...]
>> I see UB as a feature that compiler can silently change the behavior
>> of a detected error. C now can do things in back (in the name of
>> optimization)!
UB has nothing to do with *detected* errors. It's sometimes
possible for a compiler to detct that a given construct has undefined
behavior, but it's sometimes not possible, and it's never required.
> UB simply means that there is no specification or requirement for
> behaviour, thus any behaviour (or lack thereof) fits the requirements.
Right. More precisely it means that the C standard imposes no
requirements.
> You can think of writing things like "a * b" as telling the compiler
> "I promise that the values of "a" and "b" here will be such that "a *
> b" does not overflow - and I want you to give me the best generated
> code with that assumption".
As far as the C standard is concerned, "best" is meaningless.
Of course we expect compilers to do a good job.
> You can alternatively think of it as
> saying "give me the result of "a * b" if that is in the range of
> "int", and I don't care what happens if it is outside that range".
Right. (Unless a and b are of an unsigned type.)
[...]
--
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 22:45 +0100 |
| Message-ID | <10t5r9f$2f4pf$1@dont-email.me> |
| In reply to | #398189 |
On 02/05/2026 22:35, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> (This is distinct from an assembly language, that is defined in >> terms of the behaviour on an actual processor.) > > My understanding is that an assembly language says nothing about > run-time behavior. It defines a mapping from assembly language > source code to machine code, which includes CPU instructions. > The behavior of the CPU instructions is specified by the CPU > architecture. If a new version of a CPU changes the behavior of > an instruction, that change doesn't affect an assembler. People colloquially use 'assembly' to mean native code (ie. binary machine code). Most who try to examine the latter have it disassembled to textual format. Nearly everyone also mixes up 'assembly' (the textual source language) and 'assembler' (the program that converts textual assembly to binary).
[toc] | [prev] | [next] | [standalone]
Page 1 of 37 [1] 2 3 … 37 Next page →
Back to top | Article view | comp.lang.c
csiph-web