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 2 of 37 — ← Prev page 1 [2] 3 4 … 37 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-02 15:02 -0700 |
| Message-ID | <10t5sa8$2feuv$2@kst.eternal-september.org> |
| In reply to | #398190 |
Bart <bc@freeuk.com> writes:
> 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.
Really? I don't think I've ever encountered that incorrect usage.
Assembly language is text; machine code is binary. How would you
distinguish between compilers that generate textual assembly code
and compilers that directly generate binary object code?
But I won't be debating the point, since it doesn't matter here.
> Nearly everyone also mixes up 'assembly' (the textual source language)
> and 'assembler' (the program that converts textual assembly to
> binary).
Sure, "assembly language" is sometimes called "assembler".
But again, I fail to see the relevance.
Did you intend to respond to anything I wrote, or did you just want
to quibble about terminology that I used correctly and consistently?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-02 17:24 +0200 |
| Message-ID | <10t54up$1gsnu$2@dont-email.me> |
| In reply to | #398177 |
On 2026-05-02 16:32, wij wrote: > On Sat, 2026-05-02 at 15:13 +0200, David Brown wrote: >> [...] >> ["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... Beyond the actual terms (and its semi-formal definition) it's here (in our communication) been used to explain to you that you should *abstract* from any concrete system and personal thoughts you might have how a specific expression shows up in the "observable" results that you, as a programmer, are confronted with. It implies that you cannot rely on any mental model or presumption *you* may have how the compiler will handle that and what code it creates or execution behavior it shows. In context of your posted samples it effectively "warns" you that you should not expect anything sensible if you're moving in the dark areas of unspecified corner cases or edge cases. > > 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)! It's no feature, it's a hint on border-cases that are (for reasons) just not defined. You just cannot rely on a defined behavior here. (It's been already explained a couple of times that there are reasons for having certain things declared UB as opposed to producing errors. I won't engage here.) > > There are lots cases arithmetic ops can overflow. Yes, it's the programmers' task to write such code correctly. > Library codes need to check them all. Ideally, yes. And with the libraries long existing and widely spread we can observe that the quality is typically quite good. (Errors would get reported soon with large user-bases.)[*] > That leads to that any function should do the same if it want to be > reusable. Sure. Janis [*] Anecdotally; incidentally I once had observed that the Unix 'bc' multiple precision calculator program produced systematic errors in cases with numbers of about 1000 digits length. Back these days I reported an error but then I saw that (per standard) correct function is only defined up to 100 digits. My expectation was that if the GNU software is, as usual, exceeding any standard limits it should at least produce an error message (or just fix that misbehavior). (That was decades ago and I don't know the current state of 'bc' in this case.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-02 10:54 -0700 |
| Message-ID | <861pftzogw.fsf@linuxsc.com> |
| In reply to | #398177 |
wij <wyniijj5@gmail.com> writes: > What does "abstract machine" mean exactly? The term "abstract machine" comes from the ISO C standard. It refers to an environment in which the behavior of constructs in the C language can be defined, and which is independent of any actual hardware or compiler. It's an important concept to understand, for anyone who wants to reason about what C programs are supposed to do, what they are allowed to do by the C standard, and what they are not allowed to do if being run on a conforming implementation of ISO C. Note that there is nothing stopping a compiler from claiming to be a "C compiler," even if it doesn't conform to the requirements of the ISO C standard. That is why it's important to understand what are the rules of the "abstract machine", because it allows us to talk about what to expect of C programs, without having to refer to how any particular hardware behaves, or what any particular compiler does, but just considering the C program itself.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-05-03 05:19 +0800 |
| Message-ID | <c5692e45ff87daf0f3935d6f8628ba52bf5e2771.camel@gmail.com> |
| In reply to | #398184 |
On Sat, 2026-05-02 at 10:54 -0700, Tim Rentsch wrote: > wij <wyniijj5@gmail.com> writes: > > > What does "abstract machine" mean exactly? > > The term "abstract machine" comes from the ISO C standard. It > refers to an environment in which the behavior of constructs in the > C language can be defined, and which is independent of any actual > hardware or compiler. It's an important concept to understand, for > anyone who wants to reason about what C programs are supposed to do, > what they are allowed to do by the C standard, and what they are not > allowed to do if being run on a conforming implementation of ISO C. > > Note that there is nothing stopping a compiler from claiming to be a > "C compiler," even if it doesn't conform to the requirements of the > ISO C standard. That is why it's important to understand what are > the rules of the "abstract machine", because it allows us to talk > about what to expect of C programs, without having to refer to how > any particular hardware behaves, or what any particular compiler > does, but just considering the C program itself. I understand it is a must with the setup of the "abstract machine.." theory. So, according to C standard, if the compiler of 'C' language encounters an overflow error, the 'C' compiler is free to silently convert the erroneous code to any thing it feels like. Strictly speeking, the standard cannot be wrong itself, human interpreter (expert) must spell out reasons it is 'correct' as demonstrated (of course, it will be invalid in form of cyclic argument). E.g. in this UB case, because it is undefined, the compiler is not required to report this error. So, logically, UB is not an error, neither, to be consistent. So, everything is fine to the language 'expert'. But, actually, all are 'interpretation', not different than what I say now. We just cannot say the standard is wrong (sadly, my interpretation suggests so). I am not interested in such kind of word game.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-02 16:50 -0700 |
| Message-ID | <86wlxlxtf9.fsf@linuxsc.com> |
| In reply to | #398188 |
wij <wyniijj5@gmail.com> writes: > On Sat, 2026-05-02 at 10:54 -0700, Tim Rentsch wrote: > >> wij <wyniijj5@gmail.com> writes: >> >>> What does "abstract machine" mean exactly? >> >> The term "abstract machine" comes from the ISO C standard. It >> refers to an environment in which the behavior of constructs in the >> C language can be defined, and which is independent of any actual >> hardware or compiler. It's an important concept to understand, for >> anyone who wants to reason about what C programs are supposed to do, >> what they are allowed to do by the C standard, and what they are not >> allowed to do if being run on a conforming implementation of ISO C. >> >> Note that there is nothing stopping a compiler from claiming to be a >> "C compiler," even if it doesn't conform to the requirements of the >> ISO C standard. That is why it's important to understand what are >> the rules of the "abstract machine", because it allows us to talk >> about what to expect of C programs, without having to refer to how >> any particular hardware behaves, or what any particular compiler >> does, but just considering the C program itself. > > I understand it is a must with the setup of the "abstract machine.." > theory. So, according to C standard, if the compiler of 'C' > language encounters an overflow error, the 'C' compiler is free to > silently convert the erroneous code to any thing it feels like. > > Strictly speeking, the standard cannot be wrong itself, human > interpreter (expert) must spell out reasons it is 'correct' as > demonstrated (of course, it will be invalid in form of cyclic > argument). E.g. in this UB case, because it is undefined, the > compiler is not required to report this error. So, logically, UB is > not an error, neither, to be consistent. So, everything is fine to > the language 'expert'. But, actually, all are 'interpretation', not > different than what I say now. We just cannot say the standard is > wrong (sadly, my interpretation suggests so). I am not interested > in such kind of word game. You asked a question. I answered it. Don't blame me if the answer is not to your liking. If you didn't want to hear the answer you shouldn't have asked the question.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2026-05-03 07:56 +0800 |
| Message-ID | <ccf07953d655aa30a3c84993cb513c2f62a51bdd.camel@gmail.com> |
| In reply to | #398199 |
On Sat, 2026-05-02 at 16:50 -0700, Tim Rentsch wrote: > wij <wyniijj5@gmail.com> writes: > > > On Sat, 2026-05-02 at 10:54 -0700, Tim Rentsch wrote: > > > > > wij <wyniijj5@gmail.com> writes: > > > > > > > What does "abstract machine" mean exactly? > > > > > > The term "abstract machine" comes from the ISO C standard. It > > > refers to an environment in which the behavior of constructs in the > > > C language can be defined, and which is independent of any actual > > > hardware or compiler. It's an important concept to understand, for > > > anyone who wants to reason about what C programs are supposed to do, > > > what they are allowed to do by the C standard, and what they are not > > > allowed to do if being run on a conforming implementation of ISO C. > > > > > > Note that there is nothing stopping a compiler from claiming to be a > > > "C compiler," even if it doesn't conform to the requirements of the > > > ISO C standard. That is why it's important to understand what are > > > the rules of the "abstract machine", because it allows us to talk > > > about what to expect of C programs, without having to refer to how > > > any particular hardware behaves, or what any particular compiler > > > does, but just considering the C program itself. > > > > I understand it is a must with the setup of the "abstract machine.." > > theory. So, according to C standard, if the compiler of 'C' > > language encounters an overflow error, the 'C' compiler is free to > > silently convert the erroneous code to any thing it feels like. > > > > Strictly speeking, the standard cannot be wrong itself, human > > interpreter (expert) must spell out reasons it is 'correct' as > > demonstrated (of course, it will be invalid in form of cyclic > > argument). E.g. in this UB case, because it is undefined, the > > compiler is not required to report this error. So, logically, UB is > > not an error, neither, to be consistent. So, everything is fine to > > the language 'expert'. But, actually, all are 'interpretation', not > > different than what I say now. We just cannot say the standard is > > wrong (sadly, my interpretation suggests so). I am not interested > > in such kind of word game. > > You asked a question. I answered it. Don't blame me if the > answer is not to your liking. If you didn't want to hear the > answer you shouldn't have asked the question. I like on-topic opinion.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-02 14:18 +0100 |
| Message-ID | <10t4tjd$25vb5$1@dont-email.me> |
| In reply to | #398173 |
On 02/05/2026 12: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.
>
> Back to the F3 example above, I can't believe how many programs really check
> overflows to prevent UB, a burdensome task?
I ran your example with 6 compilers, with and without optimising, and
all returned -2.
This is what would be expected on a machine where 'int' is 32 bits and
representation is two's complement. Because INT_MAX, which is 011...111
in binary, is multiplied by two, effectively shifting it left by one
bit, to get 111...110, which is the bit-pattern for -2.
It is UB in C because up to C23, other integer representations were
deemed possible, with different behaviour on overflow. But that hasn't
really been the case for decades.
C23 now accepts two's complement is dominant, but the UB stays, since so
many compilers have taken advantage of it for optimisation purposes. In
this example I guess there wasn't an opportunity to do anything weird.
In the compilers I write and in the languages I implement, such overflow
behaviour is guaranteed, when an i32 calculation needs to have an i32
result.
With other people's optimising C compilers, then you either cross your
fingers, and find which option is needed to give your desired behaviour.
Since the language itself won't help. So much for 'portable assembly'!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-02 15:52 +0200 |
| Message-ID | <10t4viv$25van$2@dont-email.me> |
| In reply to | #398175 |
On 02/05/2026 15:18, Bart wrote:
> On 02/05/2026 12: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.
>>
>> Back to the F3 example above, I can't believe how many programs really
>> check
>> overflows to prevent UB, a burdensome task?
>
> I ran your example with 6 compilers, with and without optimising, and
> all returned -2.
And I tried it on another compiler and got a crash "Program terminated
with signal: SIGILL".
And in real code, when results might be used for different purposes
rather than being ignored, you could get different results.
It is UB. Anything can happen. That includes giving the absurd and
ridiculous result of multiplying a positive number by another positive
number and getting an negative number.
void G(int a, int b)
{
if (a < 0) return;
if (b < 0) return;
if (a * b < 0) printf("That's weird\n");
}
Calling "G(2, INT_MAX)" now will /not/ result in "2 * INT_MAX" giving
the result of -2 - good compilers will optimise "G" to a single "return"
instruction because they know that no matter what value you pass for "a"
and "b", no valid defined paths through the code can result in "a * b"
being negative, so the message is never printed and the whole function
can be dropped.
>
> This is what would be expected on a machine where 'int' is 32 bits and
> representation is two's complement. Because INT_MAX, which is 011...111
> in binary, is multiplied by two, effectively shifting it left by one
> bit, to get 111...110, which is the bit-pattern for -2.
No, it is /not/ the result you'd expect from multiplying two positive
numbers.
If you are doing modular arithmetic on the ring of integers modulo 2^32,
and using integers between -2^31 and 2^31 - 1 to represent the
congruence classes, then it is the value you would expect.
But C signed integer arithmetic does not model modular arithmetic, it
models normal mathematical integer arithmetic with the limitation that
unrepresentable results are undefined behaviour. (C /unsigned/ integer
arithmetic models modular arithmetic.)
The fact that on most processors, the hardware implements modular
arithmetic is incidental and irrelevant to signed integer arithmetic in
C. The definition in C is based on mathematical choices, not hardware
implementation. (See also the choice of rounding behaviour for division
of negative signed integers.)
>
> It is UB in C because up to C23, other integer representations were
> deemed possible, with different behaviour on overflow. But that hasn't
> really been the case for decades.
>
Please stop spreading such misconceptions.
Some aspects of C's behaviour may have originally been UB because some
hardware could not implement particular choices of defined behaviour.
But normally if different hardware had different "natural" behaviour,
the C standard says the results are implementation dependent. Look
carefully through the standards for things like integer conversions and
integer operations - the C standards are precise about what is fully
defined, what is implementation defined, and what is undefined.
The standard says "If an exceptional condition occurs during the
evaluation of an expression (that is, if the result is not
mathematically defined or not in the range of representable values for
its type), the behavior is undefined".
Signed integer overflow is UB because the results cannot be represented
in the appropriate type. You cannot represent 2 * INT_MAX in type int -
thus there is no correct or appropriate value that can be stored in an
int. So it is UB.
Hardware representation, or target implementation, has /nothing/ to do
with it.
>
> In the compilers I write and in the languages I implement, such overflow
> behaviour is guaranteed, when an i32 calculation needs to have an i32
> result.
No one cares what your languages - or other languages - say about signed
integer overflow. This is a C discussion. If the muppets who designed
Java thought they were being helpful by saying that signed integer
arithmetic has wrapping behaviour so that there is no UB, that's their
folly and the Java programmers have to live with that. Fortunately C
programmers can take advantage of better design choices.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-02 16:39 +0100 |
| Message-ID | <10t55r6$28suo$1@dont-email.me> |
| In reply to | #398176 |
On 02/05/2026 14:52, David Brown wrote:
> On 02/05/2026 15:18, Bart wrote:
> The fact that on most processors, the hardware implements modular
> arithmetic is incidental and irrelevant to signed integer arithmetic in
> C. The definition in C is based on mathematical choices, not hardware
> implementation.
Since when?
>
>> It is UB in C because up to C23, other integer representations were
>> deemed possible, with different behaviour on overflow. But that hasn't
>> really been the case for decades.
>>
>
> Please stop spreading such misconceptions.
>
> Some aspects of C's behaviour may have originally been UB because some
> hardware could not implement particular choices of defined behaviour.
> But normally if different hardware had different "natural" behaviour,
> the C standard says the results are implementation dependent. Look
> carefully through the standards for things like integer conversions and
> integer operations - the C standards are precise about what is fully
> defined, what is implementation defined, and what is undefined.
>
> The standard says "If an exceptional condition occurs during the
> evaluation of an expression (that is, if the result is not
> mathematically defined or not in the range of representable values for
> its type), the behavior is undefined".
>
> Signed integer overflow is UB because the results cannot be represented
> in the appropriate type. You cannot represent 2 * INT_MAX in type int -
> thus there is no correct or appropriate value that can be stored in an
> int. So it is UB.
You can't represent 2 * UINT_MAX in type unsigned int either. That can
also be a bummer if you were interested in the actual value:
void G(unsigned int a, unsigned int b)
{ unsigned c;
if (a == 0 || b == 0) return;
c = a * b;
if (c < a || c < b) printf("That's weird\n");
}
G(2, UINT_MAX);
I'd like to know why C is OK with modular arithmetic for unsigned but
not signed integers. If the latter depended on the hardware, then why
wasn't it just implementation defined?
What about this:
int8_t n=127;
n = n + 1;
n will wrap around to -128. Is this also UB, and if not, why not?
> Hardware representation, or target implementation, has /nothing/ to do
> with it.
>
>>
>> In the compilers I write and in the languages I implement, such
>> overflow behaviour is guaranteed, when an i32 calculation needs to
>> have an i32 result.
>
> No one cares what your languages - or other languages - say about signed
> integer overflow. This is a C discussion.
C runs on real machines. Real machines tend to have well-defined signed
overflow. Actually, they tend to use the same instructions for signed
and unsigned arithmetic, other than for divide.
Some languages, not just assembly, like to expose that behaviour. And
some programmers including C programmers want to exploit that too.
> If the muppets who designed
> Java thought they were being helpful by saying that signed integer
> arithmetic has wrapping behaviour so that there is no UB, that's their
> folly and the Java programmers have to live with that. Fortunately C
> programmers can take advantage of better design choices.
This is the description of the 'iadd' JVM instruction:
"The result is the 32 low-order bits of the true mathematical result in
a sufficiently wide two's-complement format, represented as a value of
type int. If overflow occurs, then the sign of the result may not be the
same as the sign of the mathematical sum of the two values.
Despite the fact that overflow may occur, execution of an iadd
instruction never throws a run-time exception."
There's a similar one for 'imul', and for 'ladd', which is for 64-bits.
I can't see the issue.
In C, signed overflow can occur /at any time/, and it is apparently UB,
but it is only UB detected at compile-time that would cause a compiler
to do weird stuff.
It can't do that weird stuff it it doesn't know for sure that overflow
will occur. In that case, the result, presumably, is just the natural
one that the hardware will give you, and that you probably want.
Or does the compiler, intent on causing mischief, inject code to detect
such overflow, even though it will not happen 99.999999% of the time, so
that in that 0.000001%, where it might have been intentional, it can go
and format your hard drive.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-02 21:16 +0200 |
| Message-ID | <10t5ij2$2crol$1@dont-email.me> |
| In reply to | #398181 |
On 02/05/2026 17:39, Bart wrote:
> On 02/05/2026 14:52, David Brown wrote:
>> On 02/05/2026 15:18, Bart wrote:
>
>> The fact that on most processors, the hardware implements modular
>> arithmetic is incidental and irrelevant to signed integer arithmetic
>> in C. The definition in C is based on mathematical choices, not
>> hardware implementation.
>
> Since when?
Since always. "The result of the binary + operator is the sum of the
operands".
>
>>
>>> It is UB in C because up to C23, other integer representations were
>>> deemed possible, with different behaviour on overflow. But that
>>> hasn't really been the case for decades.
>>>
>>
>> Please stop spreading such misconceptions.
>>
>> Some aspects of C's behaviour may have originally been UB because some
>> hardware could not implement particular choices of defined behaviour.
>> But normally if different hardware had different "natural" behaviour,
>> the C standard says the results are implementation dependent. Look
>> carefully through the standards for things like integer conversions
>> and integer operations - the C standards are precise about what is
>> fully defined, what is implementation defined, and what is undefined.
>>
>> The standard says "If an exceptional condition occurs during the
>> evaluation of an expression (that is, if the result is not
>> mathematically defined or not in the range of representable values for
>> its type), the behavior is undefined".
>>
>> Signed integer overflow is UB because the results cannot be
>> represented in the appropriate type. You cannot represent 2 * INT_MAX
>> in type int - thus there is no correct or appropriate value that can
>> be stored in an int. So it is UB.
>
>
> You can't represent 2 * UINT_MAX in type unsigned int either. That can
> also be a bummer if you were interested in the actual value:
Sure. I think unsigned integer arithmetic overflow should be UB too.
(I also think that modulo arithmetic can be useful on rare occasions.)
>
> void G(unsigned int a, unsigned int b)
> { unsigned c;
> if (a == 0 || b == 0) return;
> c = a * b;
> if (c < a || c < b) printf("That's weird\n");
> }
>
> G(2, UINT_MAX);
>
> I'd like to know why C is OK with modular arithmetic for unsigned but
> not signed integers. If the latter depended on the hardware, then why
> wasn't it just implementation defined?
Signed integer arithmetic is /not/ dependent on hardware - overflow is UB.
Unsigned integer arithmetic is /not/ dependent on hardware - it is
defined mathematically, as modulo behaviour.
>
> What about this:
>
> int8_t n=127;
> n = n + 1;
>
> n will wrap around to -128. Is this also UB, and if not, why not?
>
C does not have arithmetic on integer types smaller than "int". So "n"
is promoted to "int", and the addition is done. Since the type "int" is
at least 16 bits, there is no overflow and the result is 128. Then the
int result is converted back to "int8_t". Since 128 cannot be
represented in an int8_t, "either the result is implementation-defined
or an implementation-defined signal is raised". Usually,
implementations define such conversions based on what is most efficient
in the hardware - for two's complement processors, that means a value of
-128 will be stored in n.
But it is an implementation-defined conversion from int to int8_t here,
not wrapping arithmetic.
>
>
>> Hardware representation, or target implementation, has /nothing/ to do
>> with it.
>>
>>>
>>> In the compilers I write and in the languages I implement, such
>>> overflow behaviour is guaranteed, when an i32 calculation needs to
>>> have an i32 result.
>>
>> No one cares what your languages - or other languages - say about
>> signed integer overflow. This is a C discussion.
>
> C runs on real machines. Real machines tend to have well-defined signed
> overflow. Actually, they tend to use the same instructions for signed
> and unsigned arithmetic, other than for divide.
C does not have defined signed arithmetic overflow. C does not use the
same instructions for signed and unsigned arithmetic - C does not have
instructions.
>
> Some languages, not just assembly, like to expose that behaviour. And
> some programmers including C programmers want to exploit that too.
>
Some high-level languages might define signed integer arithmetic as
wrapping. But I seriously doubt if they define operations in terms of
instructions on target processors - defining the semantics independently
of the target processor is part of the point of high-level languages.
>
>> If the muppets who designed Java thought they were being helpful by
>> saying that signed integer arithmetic has wrapping behaviour so that
>> there is no UB, that's their folly and the Java programmers have to
>> live with that. Fortunately C programmers can take advantage of
>> better design choices.
>
>
> This is the description of the 'iadd' JVM instruction:
>
> "The result is the 32 low-order bits of the true mathematical result in
> a sufficiently wide two's-complement format, represented as a value of
> type int. If overflow occurs, then the sign of the result may not be the
> same as the sign of the mathematical sum of the two values.
>
> Despite the fact that overflow may occur, execution of an iadd
> instruction never throws a run-time exception."
>
Okay, so the the Java virtual machine instruction is has wrapping
behaviour. So what? It just makes it a little less useful for
programmers. And Java the language may or may not define its addition
as wrapping - that could be different. Whatever it is, it is not C.
> There's a similar one for 'imul', and for 'ladd', which is for 64-bits.
>
> I can't see the issue.
>
> In C, signed overflow can occur /at any time/, and it is apparently UB,
> but it is only UB detected at compile-time that would cause a compiler
> to do weird stuff.
No, it cannot occur at any time - it can only occur if the programmer
has made a mistake and tried to run code with inappropriate values.
And no, "weird stuff" is not restricted to compile time.
>
> It can't do that weird stuff it it doesn't know for sure that overflow
> will occur. In that case, the result, presumably, is just the natural
> one that the hardware will give you, and that you probably want.
>
I want the correct results for correct inputs, as fast as possible. Do
not make presumptions about what I or anyone else would want for
incorrect inputs.
> Or does the compiler, intent on causing mischief, inject code to detect
> such overflow, even though it will not happen 99.999999% of the time, so
> that in that 0.000001%, where it might have been intentional, it can go
> and format your hard drive.
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-03 01:38 +0100 |
| Message-ID | <10t65dl$2houe$1@dont-email.me> |
| In reply to | #398185 |
On 02/05/2026 20:16, David Brown wrote:
> On 02/05/2026 17:39, Bart wrote:
>> What about this:
>>
>> int8_t n=127;
>> n = n + 1;
>>
>> n will wrap around to -128. Is this also UB, and if not, why not?
>>
>
> C does not have arithmetic on integer types smaller than "int". So "n"
> is promoted to "int", and the addition is done. Since the type "int" is
> at least 16 bits, there is no overflow and the result is 128. Then the
> int result is converted back to "int8_t". Since 128 cannot be
> represented in an int8_t, "either the result is implementation-defined
> or an implementation-defined signal is raised". Usually,
> implementations define such conversions based on what is most efficient
> in the hardware - for two's complement processors, that means a value of
> -128 will be stored in n.
>
> But it is an implementation-defined conversion from int to int8_t here,
> not wrapping arithmetic.
So:
int8_t a = 127;
int16_t b = 32767;
int32_t c = 2147483647;
int64_t d = 9223372036854775807;
++a; // implementation-defined
++b; // implementation-defined
++c; // UB
++d; // UB
Looks like another inconsistency to me. All variables contain the wrong
values if you don't want wrapping behaviour.
But if you do want it, then only half of them are UB.
And supposed 'int' was 64 bits on this system; would only the last be
UB? It seems odd that whether '++c' is UB or not depends on whether -m32
or -m64 was used.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-02 17:52 -0700 |
| Message-ID | <10t668m$2h360$5@kst.eternal-september.org> |
| In reply to | #398210 |
Bart <bc@freeuk.com> writes:
> On 02/05/2026 20:16, David Brown wrote:
>> On 02/05/2026 17:39, Bart wrote:
>
>>> What about this:
>>>
>>> int8_t n=127;
>>> n = n + 1;
>>>
>>> n will wrap around to -128. Is this also UB, and if not, why not?
>>>
>> C does not have arithmetic on integer types smaller than "int". So
>> "n" is promoted to "int", and the addition is done. Since the type
>> "int" is at least 16 bits, there is no overflow and the result is
>> 128. Then the int result is converted back to "int8_t". Since 128
>> cannot be represented in an int8_t, "either the result is
>> implementation-defined or an implementation-defined signal is
>> raised". Usually, implementations define such conversions based on
>> what is most efficient in the hardware - for two's complement
>> processors, that means a value of -128 will be stored in n.
>> But it is an implementation-defined conversion from int to int8_t
>> here, not wrapping arithmetic.
(You replied to an article from 3 months ago.)
> So:
>
> int8_t a = 127;
> int16_t b = 32767;
> int32_t c = 2147483647;
> int64_t d = 9223372036854775807;
>
> ++a; // implementation-defined
> ++b; // implementation-defined
> ++c; // UB
> ++d; // UB
Almost. ++b has undefined behavior if INT_MAX==32767.
> Looks like another inconsistency to me. All variables contain the
> wrong values if you don't want wrapping behaviour.
Yes, I know it looks like another inconsistency *to you*.
You're able to correctly state the consequences of the rules of the C
standard, but you re not able to refrain from complaining about them.
Integer types narrower than int are treated quite differently than
integer types as wide as or wider than int. As David wrote and you
quoted, C has no arithmetic operations on integer types narrower
than int.
Though it's not something I often bother to mention, I don't
particularly like this. I think the language would be cleaner
if there were direct operations for all integer types, including
narrow ones, with no implicit promotion to int or unsigned int.
SCHAR_MAX+1, SHRT_MAX+1, and INT_MAX+1 would all have undefined
behavior for exactly the same reason.
It likely wouldn't be practical to make such a change in a future
edition of the C standard. It's likely that it would cause problems,
and certain that it would require a lot of work to determine just
what problems it would cause. I do not expect or advocate any such
change in the future. (I would advocate using simpler rules when
designing new languages.)
But the C standard says what it says, and there is no inconsistency.
The rules consistently imply that SCHAR_MAX+1 yields an
implementation-defined result or raises an implementation-defined
signal, and that INT_MAX+1 has undefined behavior.
> But if you do want it, then only half of them are UB.
>
> And supposed 'int' was 64 bits on this system; would only the last be
> UB? It seems odd that whether '++c' is UB or not depends on whether
> -m32 or -m64 was used.
Sure, it's odd. What's your point? Everyone here already knows
that C has oddities.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-03 12:39 +0200 |
| Message-ID | <10t78la$2qne2$2@dont-email.me> |
| In reply to | #398212 |
On 03/05/2026 02:52, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 02/05/2026 20:16, David Brown wrote: >>> On 02/05/2026 17:39, Bart wrote: >> >>>> What about this: >>>> >>>> int8_t n=127; >>>> n = n + 1; >>>> >>>> n will wrap around to -128. Is this also UB, and if not, why not? >>>> >>> C does not have arithmetic on integer types smaller than "int". So >>> "n" is promoted to "int", and the addition is done. Since the type >>> "int" is at least 16 bits, there is no overflow and the result is >>> 128. Then the int result is converted back to "int8_t". Since 128 >>> cannot be represented in an int8_t, "either the result is >>> implementation-defined or an implementation-defined signal is >>> raised". Usually, implementations define such conversions based on >>> what is most efficient in the hardware - for two's complement >>> processors, that means a value of -128 will be stored in n. >>> But it is an implementation-defined conversion from int to int8_t >>> here, not wrapping arithmetic. > > (You replied to an article from 3 months ago.) (Are you mixing up your dates - reading little-endian UK date formats as though they were muddled-endian USA date formats?) > >> So: >> >> int8_t a = 127; >> int16_t b = 32767; >> int32_t c = 2147483647; >> int64_t d = 9223372036854775807; >> >> ++a; // implementation-defined >> ++b; // implementation-defined >> ++c; // UB >> ++d; // UB > > Almost. ++b has undefined behavior if INT_MAX==32767. > >> Looks like another inconsistency to me. All variables contain the >> wrong values if you don't want wrapping behaviour. > > Yes, I know it looks like another inconsistency *to you*. > > You're able to correctly state the consequences of the rules of the C > standard, but you re not able to refrain from complaining about them. > > Integer types narrower than int are treated quite differently than > integer types as wide as or wider than int. As David wrote and you > quoted, C has no arithmetic operations on integer types narrower > than int. > > Though it's not something I often bother to mention, I don't > particularly like this. I think the language would be cleaner > if there were direct operations for all integer types, including > narrow ones, with no implicit promotion to int or unsigned int. > SCHAR_MAX+1, SHRT_MAX+1, and INT_MAX+1 would all have undefined > behavior for exactly the same reason. > I agree with you here. I understand the purpose of the integer promotion rules when they were designed, but I'd rather the language did not have them. (And even in a language that does have them, I'd have preferred them to be slightly different - especially in regard to signed and unsigned mixes.) We can now use _BitInt() types as an alternative - these do not promote, and are therefore more consistent. And for our neighbours in c.l.c++, it's not difficult to make types in C++ that act pretty much entirely like standard integer types except that they do not promote. (And for those that think it makes sense to take a pile of 127 apples, put a new apple on top and get a hole in the universe shaped like 128 apples, you can even give them wrapping semantics.) Yet in practice, it's easy enough to simply know and understand the C integer promotion rules and write code that works correctly without UB and with the portability you need for the task at hand. > It likely wouldn't be practical to make such a change in a future > edition of the C standard. It's likely that it would cause problems, > and certain that it would require a lot of work to determine just > what problems it would cause. I do not expect or advocate any such > change in the future. (I would advocate using simpler rules when > designing new languages.) > Agreed. > But the C standard says what it says, and there is no inconsistency. > The rules consistently imply that SCHAR_MAX+1 yields an > implementation-defined result or raises an implementation-defined > signal, and that INT_MAX+1 has undefined behavior. > >> But if you do want it, then only half of them are UB. >> >> And supposed 'int' was 64 bits on this system; would only the last be >> UB? It seems odd that whether '++c' is UB or not depends on whether >> -m32 or -m64 was used. > > Sure, it's odd. What's your point? Everyone here already knows > that C has oddities. >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-03 14:19 -0700 |
| Message-ID | <10t8e4v$36t8v$1@kst.eternal-september.org> |
| In reply to | #398225 |
David Brown <david.brown@hesbynett.no> writes:
> On 03/05/2026 02:52, Keith Thompson wrote:
[...]
>> (You replied to an article from 3 months ago.)
>
> (Are you mixing up your dates - reading little-endian UK date formats
> as though they were muddled-endian USA date formats?)
Yes, I did. My mistake.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-04 08:41 +0200 |
| Message-ID | <10t9f3o$3f5ei$1@dont-email.me> |
| In reply to | #398252 |
On 03/05/2026 23:19, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 03/05/2026 02:52, Keith Thompson wrote: > [...] >>> (You replied to an article from 3 months ago.) >> >> (Are you mixing up your dates - reading little-endian UK date formats >> as though they were muddled-endian USA date formats?) > > Yes, I did. My mistake. > Usually I consider the USA date format to be madness - but today, all is forgiven because without it there would be no Star Wars Day :-)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-04 11:22 +0200 |
| Message-ID | <10t9ofs$1gsnu$8@dont-email.me> |
| In reply to | #398274 |
On 2026-05-04 08:41, David Brown wrote: > > Usually I consider the USA date format to be madness - but today, all is > forgiven because without it there would be no Star Wars Day :-) Hey, that's today, indeed! But the English _textual_/colloquial form, "May, the fourth" doesn't require to use a convoluted _numerical_ format, mind. (And the pun anyway works only in English.) Janis -- One of the 5 persons worldwide that isn't a fan of these movies. ;-)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-05-04 13:47 -0700 |
| Message-ID | <10tb0l4$3v8ut$1@dont-email.me> |
| In reply to | #398185 |
On 5/2/2026 12:16 PM, David Brown wrote: > On 02/05/2026 17:39, Bart wrote: >> On 02/05/2026 14:52, David Brown wrote: >>> On 02/05/2026 15:18, Bart wrote: >> >>> The fact that on most processors, the hardware implements modular >>> arithmetic is incidental and irrelevant to signed integer arithmetic >>> in C. The definition in C is based on mathematical choices, not >>> hardware implementation. >> >> Since when? > > Since always. "The result of the binary + operator is the sum of the > operands". > >> >>> >>>> It is UB in C because up to C23, other integer representations were >>>> deemed possible, with different behaviour on overflow. But that >>>> hasn't really been the case for decades. >>>> >>> >>> Please stop spreading such misconceptions. >>> >>> Some aspects of C's behaviour may have originally been UB because >>> some hardware could not implement particular choices of defined >>> behaviour. But normally if different hardware had different "natural" >>> behaviour, the C standard says the results are implementation >>> dependent. Look carefully through the standards for things like >>> integer conversions and integer operations - the C standards are >>> precise about what is fully defined, what is implementation defined, >>> and what is undefined. >>> >>> The standard says "If an exceptional condition occurs during the >>> evaluation of an expression (that is, if the result is not >>> mathematically defined or not in the range of representable values >>> for its type), the behavior is undefined". >>> >>> Signed integer overflow is UB because the results cannot be >>> represented in the appropriate type. You cannot represent 2 * >>> INT_MAX in type int - thus there is no correct or appropriate value >>> that can be stored in an int. So it is UB. >> >> >> You can't represent 2 * UINT_MAX in type unsigned int either. That can >> also be a bummer if you were interested in the actual value: > > Sure. I think unsigned integer arithmetic overflow should be UB too. Humm... Not too sure about that. > (I > also think that modulo arithmetic can be useful on rare occasions.) [...]
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-05 02:12 +0200 |
| Message-ID | <10tbclv$1gsnv$8@dont-email.me> |
| In reply to | #398310 |
On 2026-05-04 22:47, Chris M. Thomasson wrote: > On 5/2/2026 12:16 PM, David Brown wrote: >> >> [...] I think unsigned integer arithmetic overflow should be UB too. > > Humm... Not too sure about that. Why? - I suppose because "we" are used to think in low-level register semantics? - But if you think about that; what's the reason to handle _a very special case_, namely how a register of length 8, 16, 32, 64, etc. behaves when adding values beyond its "capacity". - If we want a modulus, why not just expressing it as such; (a+b)%8, (a+b)%32, and, not restricting oneself to the special values, also (a+b)%53, etc.[*] Yes, I can think of applications where implicit wrap-around could be used; say, in the Unix "PID generation" process. But is it essential that there's - again, for a couple special numbers - a wrap-around? Or is it the super-duper-high performance-gain we get with wrap-around available? (Not really! Even if we don't assume primitive optimization to be applied by compilers to remove that undesired "complexity".) It shall also not be forgotten that in "C" you typically have little standardized information about concrete sizes of integral types; at least if we intend to write portable code independent of a platform. An explicit modulus, OTOH, is well and universally defined and can be understood by humans and C-compilers, and you also directly see its semantics in the source code without making assumptions or requiring an explicit comment. I came to the insight that a wrap-around semantics might not be as important as we may think. Janis [*] It may be worthwhile to remember here that standard algorithms that make use of a modulus are typically *not* using a power-of-two modulus because of the bad characteristics and distribution properties these reveal. Just BTW, to remind that the special values we're discussing here are probably much less important than we assume at first.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-05 15:02 +0000 |
| Message-ID | <9EnKR.903234$5GB4.294142@fx47.iad> |
| In reply to | #398326 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >On 2026-05-04 22:47, Chris M. Thomasson wrote: >> On 5/2/2026 12:16 PM, David Brown wrote: >>> >>> [...] I think unsigned integer arithmetic overflow should be UB too. >> >> Humm... Not too sure about that. > >Why? - I suppose because "we" are used to think in low-level register >semantics? Or because we need to _simulate_ low-level register semantics (which is my day job).
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-06 04:06 +0200 |
| Message-ID | <10te7ma$1gsnv$9@dont-email.me> |
| In reply to | #398376 |
On 2026-05-05 17:02, Scott Lurndal wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-05-04 22:47, Chris M. Thomasson wrote: >>> On 5/2/2026 12:16 PM, David Brown wrote: >>>> >>>> [...] I think unsigned integer arithmetic overflow should be UB too. >>> >>> Humm... Not too sure about that. >> >> Why? - I suppose because "we" are used to think in low-level register >> semantics? > > Or because we need to _simulate_ low-level register > semantics (which is my day job). If you simulate that you could resort to an explicit modulus, or not? Janis
[toc] | [prev] | [next] | [standalone]
Page 2 of 37 — ← Prev page 1 [2] 3 4 … 37 Next page →
Back to top | Article view | comp.lang.c
csiph-web