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 5 of 37 — ← Prev page 1 … 3 4 [5] 6 7 … 37 Next page →
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-05-03 00:30 +0000 |
| Message-ID | <10t64u6$36agp$2@paganini.bofh.team> |
| In reply to | #398183 |
Bart <bc@freeuk.com> wrote:
> On 02/05/2026 14:52, David Brown wrote:
>> On 02/05/2026 15:18, Bart wrote:
>
>>> I ran your example with 6 compilers, with and without optimising, and
>>> all returned -2.
>>
>> And I tried it on another compiler and got a crash "Program terminated
>> with signal: SIGILL".
>
> Which compiler?
>
> I tried another experiment with printing the result of 2 * 2000000000
> across several languages. All these printed -294967296:
>
> C#
> D
> Java
> Fortran
> Kotlin
>
> (All run from rextester.com.) These also printed an overflowed result:
>
> Pascal (16-bit overflow)
> Go (Overflowed 64 bits with a bigger calculation)
> Lua 5.4 (Overflowed 64 bits)
>
> So quite a few languages including mainstream ones don't seem bothered
> by it. Only C seems to get in a tizz about it, ands it's mainly a few
> people posting here who seem think it is such a big deal.
You do not get it. Like other languages C compiler will generate some
code which maybe will do what you expect, maybe not. The point is that
there is no warranty. AFAIK situation with other standarized languages
is that they have their equivalent of C undefined behaviour (in Pascal
it is called "error"). Some languages (like Lisp) demand arbitrary
precision integers, so when numbers get too big you will run out of
memory, but overflow is not possible. Some (maybe only Java) use
wrap-around semantics. But pretty typically overflow is undefined
behaviour.
BTW: Lisp has declaration and you can declare variable as having
specified range (say 64-bits). This allows generating more efficient
code, but if you violate declaration, then you get undefined
behaviour.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-03 01:55 +0100 |
| Message-ID | <10t66eg$2houe$2@dont-email.me> |
| In reply to | #398208 |
On 03/05/2026 01:30, Waldek Hebisch wrote:
> Bart <bc@freeuk.com> wrote:
>> On 02/05/2026 14:52, David Brown wrote:
>>> On 02/05/2026 15:18, Bart wrote:
>>
>>>> I ran your example with 6 compilers, with and without optimising, and
>>>> all returned -2.
>>>
>>> And I tried it on another compiler and got a crash "Program terminated
>>> with signal: SIGILL".
>>
>> Which compiler?
>>
>> I tried another experiment with printing the result of 2 * 2000000000
>> across several languages. All these printed -294967296:
>>
>> C#
>> D
>> Java
>> Fortran
>> Kotlin
>>
>> (All run from rextester.com.) These also printed an overflowed result:
>>
>> Pascal (16-bit overflow)
>> Go (Overflowed 64 bits with a bigger calculation)
>> Lua 5.4 (Overflowed 64 bits)
>>
>> So quite a few languages including mainstream ones don't seem bothered
>> by it. Only C seems to get in a tizz about it, ands it's mainly a few
>> people posting here who seem think it is such a big deal.
>
> You do not get it. Like other languages C compiler will generate some
> code which maybe will do what you expect, maybe not. The point is that
> there is no warranty. AFAIK situation with other standarized languages
> is that they have their equivalent of C undefined behaviour (in Pascal
> it is called "error"). Some languages (like Lisp) demand arbitrary
> precision integers, so when numbers get too big you will run out of
> memory, but overflow is not possible. Some (maybe only Java) use
> wrap-around semantics. But pretty typically overflow is undefined
> behaviour.
>
> BTW: Lisp has declaration and you can declare variable as having
> specified range (say 64-bits). This allows generating more efficient
> code, but if you violate declaration, then you get undefined
> behaviour.
>
But the output in every case is the equivalent of this:
load R0, 2
load R1, 2000000000
mul R0, R1
They all print whatever the value is in R0, which is the lower 32 bits
of the result. (Some languages may use a different word length so
overflow occurs at smaller or bigger magnitude.)
This is well-defined on the machines of interest.
How many of those languages guarantee that? If not, why not?
(Assembly will, and all of mine when I directly generate the backend code.)
For me, it is desirable to have this stability, and confidence in the
results.
If I wanted more accurate results, I'd use a wider type, or arbitrary
precision. (I use 64-bits at least, so 2*2000000000 will simply be
4000000000.)
C however is a lower-level language (though not as low as some seem to
think). If u32 calculations can wrap, and not be implementation-defined
or UB, even though that may indicate a logic error, then why can't i32
do the same?
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-05-03 02:21 +0000 |
| Message-ID | <10t6bf2$36qnd$1@paganini.bofh.team> |
| In reply to | #398214 |
Bart <bc@freeuk.com> wrote:
> On 03/05/2026 01:30, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
>>> On 02/05/2026 14:52, David Brown wrote:
>>>> On 02/05/2026 15:18, Bart wrote:
>>>
>>>>> I ran your example with 6 compilers, with and without optimising, and
>>>>> all returned -2.
>>>>
>>>> And I tried it on another compiler and got a crash "Program terminated
>>>> with signal: SIGILL".
>>>
>>> Which compiler?
>>>
>>> I tried another experiment with printing the result of 2 * 2000000000
>>> across several languages. All these printed -294967296:
>>>
>>> C#
>>> D
>>> Java
>>> Fortran
>>> Kotlin
>>>
>>> (All run from rextester.com.) These also printed an overflowed result:
>>>
>>> Pascal (16-bit overflow)
>>> Go (Overflowed 64 bits with a bigger calculation)
>>> Lua 5.4 (Overflowed 64 bits)
>>>
>>> So quite a few languages including mainstream ones don't seem bothered
>>> by it. Only C seems to get in a tizz about it, ands it's mainly a few
>>> people posting here who seem think it is such a big deal.
>>
>> You do not get it. Like other languages C compiler will generate some
>> code which maybe will do what you expect, maybe not. The point is that
>> there is no warranty. AFAIK situation with other standarized languages
>> is that they have their equivalent of C undefined behaviour (in Pascal
>> it is called "error"). Some languages (like Lisp) demand arbitrary
>> precision integers, so when numbers get too big you will run out of
>> memory, but overflow is not possible. Some (maybe only Java) use
>> wrap-around semantics. But pretty typically overflow is undefined
>> behaviour.
>>
>> BTW: Lisp has declaration and you can declare variable as having
>> specified range (say 64-bits). This allows generating more efficient
>> code, but if you violate declaration, then you get undefined
>> behaviour.
>>
>
> But the output in every case is the equivalent of this:
>
> load R0, 2
> load R1, 2000000000
> mul R0, R1
>
> They all print whatever the value is in R0, which is the lower 32 bits
> of the result. (Some languages may use a different word length so
> overflow occurs at smaller or bigger magnitude.)
>
> This is well-defined on the machines of interest.
>
> How many of those languages guarantee that? If not, why not?
Java guarantee that and possibly no other language. I am affraid
that we do not communicate well. Function like this is a trivial
one. A language should say something about such functions, but
language defintions are concerned with more complex functions.
Meaning (or lack of meaning) of such simple function should be
consequence of general rules. Would you like to use a language
which says: "if multiplication '2*INT_MAX' is the only arithmentic
operation inside a function, them the result is produced using
wrap-around semantics, but if function contains more operations,
then result is undefined"? I hope that you agree with me that
such definition would be insane. Consder code below:
int x;
/* compute x */
x = 2*x;
/* Use x */
int y = x>>1;
AFAICS with current definitions C compiler may save old value of
x when doing multiplication and then instead of shifting x
compiler could use old value.
If you write trival functions then it is easy to optimize them
by hand, but with more complicated ones compiler optimizations
are more important. Note that function may look small, but
due to macros or inlining may actually contain quite a lot of
code. In such cases optimizing by hand is undesirable (as it
would presumably require much more work than writing simple
small looking version). And interesting compiler optimizations
involve interaction of various code pieces. The only sane
way to specify such interactions it to have simple general
rules. Now, wrap-around is a simple rule saying what happens
in case of overflow. But wrap-around disables several
possible optimizations and rarely is desired behaviour.
Experience with early languages showed that trying to
define some corner cases is counterproductive. That is,
it does not help that result is well defined when it is
wrong. That is why leaving overflow undefined was deemed
right choice: if there is overflow, then usually it means
that results are wrong anyway and if there are no overflow,
then compiler can better optimize.
Once you have wrong intermediate result in a program, then
it is very hard to give general warranty. I mean, for
specific program one could try to reason as you do: "I only
print the result, at worst I will see some weird value".
But if compiler sees optimization opportunity, it may do
some othewise unexpected transformation. The effect may
at first look trivial, that is different value than you
expected. But if such value is used as array index it
may lead to out of bound access. Probability that
something really bad happens is pretty low. But
completely excluding bad effects is impossible. Trying
to formulate how exactly something bad may happen
(and implicitely, ensuring that in some cases nothing
bad happens) is counterproductive too: it would effectively
give some weird definition to currently undefined
operation. Such definition is unliekly to help writing
correct programs and when program is incorrect it may
have bad effect. As an example, consider program
computing workers pay using C unsigned artihmetic.
Let us say that worker really did not work, so
basic pay is 0. But he caues damage, so there is
penalty of 1, which is subtracted from basic pay.
Suddenly our worker gets paid large positive amount.
Fact that in this case artihmetic is defined by the
language does not change fact that result is wrong
and potentially could have large real life effect.
> (Assembly will, and all of mine when I directly generate the backend code.)
>
> For me, it is desirable to have this stability, and confidence in the
> results.
For confidence I would like implementation that traps on overflow,
so that I know that succesful computations had no overflow.
But most people seem to prefer getting results faster, without
checks for overflow. C allows both.
> If I wanted more accurate results, I'd use a wider type, or arbitrary
> precision. (I use 64-bits at least, so 2*2000000000 will simply be
> 4000000000.)
>
> C however is a lower-level language (though not as low as some seem to
> think). If u32 calculations can wrap, and not be implementation-defined
> or UB, even though that may indicate a logic error, then why can't i32
> do the same?
As I wrote, it is natural and common to leave overflow undefined.
But in rare cases wraparund (modulo behaviour) may be desirable.
C decided to offer both, in such case choosing wraparound for
unsigned type is a bit more natural than the oppositve (that
is undefined behaviour for unsigned types and wraparound for
signed types). I would also guess that signed types offer more
optimization possibilities. Arguably better language design
would make overflow undefined both for signed and unsigned
types, but introduce separate modulo types. But decisions
were made many years ago and C is unlikely to change here.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-05-03 08:53 +0300 |
| Message-ID | <20260503085356.000003be@yahoo.com> |
| In reply to | #398217 |
On Sun, 3 May 2026 02:21:24 -0000 (UTC) antispam@fricas.org (Waldek Hebisch) wrote: > Bart <bc@freeuk.com> wrote: > > On 03/05/2026 01:30, Waldek Hebisch wrote: > >> Bart <bc@freeuk.com> wrote: > >>> On 02/05/2026 14:52, David Brown wrote: > >>>> On 02/05/2026 15:18, Bart wrote: > >>> > >>>>> I ran your example with 6 compilers, with and without > >>>>> optimising, and all returned -2. > >>>> > >>>> And I tried it on another compiler and got a crash "Program > >>>> terminated with signal: SIGILL". > >>> > >>> Which compiler? > >>> > >>> I tried another experiment with printing the result of 2 * > >>> 2000000000 across several languages. All these printed -294967296: > >>> > >>> C# > >>> D > >>> Java > >>> Fortran > >>> Kotlin > >>> > >>> (All run from rextester.com.) These also printed an overflowed > >>> result: > >>> > >>> Pascal (16-bit overflow) > >>> Go (Overflowed 64 bits with a bigger calculation) > >>> Lua 5.4 (Overflowed 64 bits) > >>> > >>> So quite a few languages including mainstream ones don't seem > >>> bothered by it. Only C seems to get in a tizz about it, ands it's > >>> mainly a few people posting here who seem think it is such a big > >>> deal. > >> > >> You do not get it. Like other languages C compiler will generate > >> some code which maybe will do what you expect, maybe not. The > >> point is that there is no warranty. AFAIK situation with other > >> standarized languages is that they have their equivalent of C > >> undefined behaviour (in Pascal it is called "error"). Some > >> languages (like Lisp) demand arbitrary precision integers, so when > >> numbers get too big you will run out of memory, but overflow is > >> not possible. Some (maybe only Java) use wrap-around semantics. > >> But pretty typically overflow is undefined behaviour. > >> > >> BTW: Lisp has declaration and you can declare variable as having > >> specified range (say 64-bits). This allows generating more > >> efficient code, but if you violate declaration, then you get > >> undefined behaviour. > >> > > > > But the output in every case is the equivalent of this: > > > > load R0, 2 > > load R1, 2000000000 > > mul R0, R1 > > > > They all print whatever the value is in R0, which is the lower 32 > > bits of the result. (Some languages may use a different word length > > so overflow occurs at smaller or bigger magnitude.) > > > > This is well-defined on the machines of interest. > > > > How many of those languages guarantee that? If not, why not? > > Java guarantee that and possibly no other language. C# guarantees exception in checked context and two-complement wrap-around in unchecked context.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-03 11:59 +0100 |
| Message-ID | <10t79qb$2rcc9$1@dont-email.me> |
| In reply to | #398217 |
On 03/05/2026 03:21, Waldek Hebisch wrote:
> Bart <bc@freeuk.com> wrote:
>> How many of those languages guarantee that? If not, why not?
>
> Java guarantee that and possibly no other language. I am affraid
> that we do not communicate well. Function like this is a trivial
> one. A language should say something about such functions, but
> language defintions are concerned with more complex functions.
> Meaning (or lack of meaning) of such simple function should be
> consequence of general rules. Would you like to use a language
> which says: "if multiplication '2*INT_MAX' is the only arithmentic
> operation inside a function, them the result is produced using
> wrap-around semantics, but if function contains more operations,
> then result is undefined"? I hope that you agree with me that
> such definition would be insane. Consder code below:
>
> int x;
> /* compute x */
> x = 2*x;
> /* Use x */
> int y = x>>1;
>
> AFAICS with current definitions C compiler may save old value of
> x when doing multiplication and then instead of shifting x
> compiler could use old value.
Program code is not mathematics. If people assume that, then C and other
lower-level languages are the wrong ones for them.
BTW your example has UB anyway according to everyone here, since x is
not defined. I will assume the comment implies some value has been assigned.
In that case, let's see what happens with this version:
int x;
x = 2000000000;
printf("x = %d\n", x);
x = 2*x;
printf("x' = %d\n", x);
int y = x>>1;
printf("y (x'>>1) = %d\n", y);
I get:
x = 2000000000
x' = -294967296
y (x'>>1) = -147483648
So y is not using the old value of x, even using gcc -O3, and even
without the first two printfs
> If you write trival functions then it is easy to optimize them
> by hand, but with more complicated ones compiler optimizations
> are more important. Note that function may look small, but
> due to macros or inlining may actually contain quite a lot of
> code. In such cases optimizing by hand is undesirable (as it
> would presumably require much more work than writing simple
> small looking version). And interesting compiler optimizations
> involve interaction of various code pieces. The only sane
> way to specify such interactions it to have simple general
> rules. Now, wrap-around is a simple rule saying what happens
> in case of overflow. But wrap-around disables several
> possible optimizations and rarely is desired behaviour.
> Experience with early languages showed that trying to
> define some corner cases is counterproductive. That is,
> it does not help that result is well defined when it is
> wrong. That is why leaving overflow undefined was deemed
> right choice:
'Undefined' meaning that the result is wrong, it is just whatever the
implementation (ie. the machine used to execute the program) ends up
with, would have been better.
At least, if overflow was not desirable, you will know it from the wrong
results.
If the above program only printed 'y' with a value of 2000000000, then
that would have hidden the problem.
> if there is overflow, then usually it means
> that results are wrong anyway and if there are no overflow,
> then compiler can better optimize.
As I said, that hides problems.
> Once you have wrong intermediate result in a program, then
> it is very hard to give general warranty. I mean, for
> specific program one could try to reason as you do: "I only
> print the result, at worst I will see some weird value".
> But if compiler sees optimization opportunity, it may do
> some othewise unexpected transformation. The effect may
> at first look trivial, that is different value than you
> expected. But if such value is used as array index it
> may lead to out of bound access. Probability that
> something really bad happens is pretty low. But
> completely excluding bad effects is impossible. Trying
> to formulate how exactly something bad may happen
> (and implicitely, ensuring that in some cases nothing
> bad happens) is counterproductive too: it would effectively
> give some weird definition to currently undefined
> operation. Such definition is unliekly to help writing
> correct programs and when program is incorrect it may
> have bad effect. As an example, consider program
> computing workers pay using C unsigned artihmetic.
> Let us say that worker really did not work, so
> basic pay is 0. But he caues damage, so there is
> penalty of 1, which is subtracted from basic pay.
> Suddenly our worker gets paid large positive amount.
> Fact that in this case artihmetic is defined by the
> language does not change fact that result is wrong
> and potentially could have large real life effect.
This is why saying that overflow is perfectly fine with unsigned but not
signed is wrong.
With signed, unexpected things happening from overflow tend to occur
when at least one operand is very large. If the language chooses 64-bit
default integers, then operands need to be 4 billion times bigger for
overflow to occur.
But with unsigned, you get unexpected things happening with much smaller
numbers, such as '1 - 2', even using 64 bits (which makes the wrong
result even more astronomically large).
(In my languages, i64 is the primary integer type, which can also
represent all possible u8 u16 u32 values. u64 is secondary with poorer
support.)
>> If I wanted more accurate results, I'd use a wider type, or arbitrary
>> precision. (I use 64-bits at least, so 2*2000000000 will simply be
>> 4000000000.)
>>
>> C however is a lower-level language (though not as low as some seem to
>> think). If u32 calculations can wrap, and not be implementation-defined
>> or UB, even though that may indicate a logic error, then why can't i32
>> do the same?
>
> As I wrote, it is natural and common to leave overflow undefined.
> But in rare cases wraparund (modulo behaviour) may be desirable.
> C decided to offer both, in such case choosing wraparound for
'C decided...'! I'm pretty none of this of this was in the minds of the
designers when they created C on that PDP7. They just wanted something
more productive than writing assembly.
At some point such things have been retrofitted to the standard, but at
a time when lots of diverse implementations already existed.
So it might have been the best of a bad job, but why pretend that that's
what was intended right from the start?
> unsigned type is a bit more natural than the oppositve (that
> is undefined behaviour for unsigned types and wraparound for
> signed types). I would also guess that signed types offer more
> optimization possibilities. Arguably better language design
> would make overflow undefined both for signed and unsigned
> types, but introduce separate modulo types. But decisions
> were made many years ago and C is unlikely to change here.
Can an implementation choose to make signed overflow well-defined?
Wasn't there a gcc option that enabled signed overflow? (I seem to
remember enabling it to see if applications ran any slower.)
In that case, what have we been arguing about if C allows it after all?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-03 13:27 +0200 |
| Message-ID | <10t7bel$2rr3t$1@dont-email.me> |
| In reply to | #398228 |
On 03/05/2026 12:59, Bart wrote:
> Can an implementation choose to make signed overflow well-defined?
>
The C standards say signed integer arithmetic overflow is undefined
behaviour - which means the standards impose no requirements at all.
That also means they impose no restrictions, and compilers can do as
they want in the face of UB. Assuming a non-antagonistic compiler, that
means doing what the compiler user wants in the face of UB. Usually
that means generating more efficient (smaller and/or faster) code on the
assumption that the UB is not hit at runtime. But it can also mean
other things, typically under control of compiler flags, but sometimes
set by default by the compiler. Two common choices are controlled error
reports (like "-fsanitize=undefined" gives you on gcc ad clang), and
specific defined behaviour.
The most common choice of specific defined behaviour is wrapping,
because that is usually efficient to implement, can occasionally be
useful for detecting problems after the fact, and because some people
have weird ideas about it being the "right" way to handle overflow
despite the result usually being totally useless. Other specific
behaviour that might be more useful, albeit less efficient on most
hardware, includes saturation, or treating a specific value as a kind of
"integer NaN" indicator.
> Wasn't there a gcc option that enabled signed overflow? (I seem to
> remember enabling it to see if applications ran any slower.)
>
"-fwrapv".
If you enable that, gcc guarantees wrapping semantics for signed integer
overflow.
> In that case, what have we been arguing about if C allows it after all?
People have being trying to correct your (and wij's) misunderstandings
with the facts about what the C standard says. I've no idea why /you/
have been arguing. It's like if I told you the grass on my lawn was
green, and you alternate between telling me it's purple, it should be
pink, and other people have orange grass in their gardens.
You have been told numerous times that you personally should be using
"-fwrapv" with gcc to get the semantics you want for signed overflow.
Better still, use a pragma in your code:
#pragma GCC optimize("-fwrapv")
But rather than take that advice, you seem to prefer to forget it and
then regurgitate the same muddled thoughts on a regular basis.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-03 13:46 +0100 |
| Message-ID | <10t7g3r$2srmg$1@dont-email.me> |
| In reply to | #398229 |
On 03/05/2026 12:27, David Brown wrote: > On 03/05/2026 12:59, Bart wrote: > >> Can an implementation choose to make signed overflow well-defined? >> > > The C standards say signed integer arithmetic overflow is undefined > behaviour - which means the standards impose no requirements at all. > > That also means they impose no restrictions, and compilers can do as > they want in the face of UB. Assuming a non-antagonistic compiler, that > means doing what the compiler user wants in the face of UB. So UB can also just mean implementation-defined? I'm glad we cleared that up! In addition, it can also mean that signed overflow can be just as well-defined as unsigned 'overflow'. So that arguments about one being bad and the other good are specious. This means that all the behaviours I observed with non-C languages and non-optimising C compilers, that seem to be in line with how I and lots of other people want, are likely by design, and not by chance, as some have suggested. > Usually > that means generating more efficient (smaller and/or faster) code on the > assumption that the UB is not hit at runtime. But it can also mean > other things, typically under control of compiler flags, but sometimes > set by default by the compiler. Two common choices are controlled error > reports (like "-fsanitize=undefined" gives you on gcc ad clang), and > specific defined behaviour. > > The most common choice of specific defined behaviour is wrapping, > because that is usually efficient to implement, can occasionally be > useful for detecting problems after the fact, and because some people > have weird ideas about it being the "right" way to handle overflow > despite the result usually being totally useless. Other specific > behaviour that might be more useful, albeit less efficient on most > hardware, includes saturation, or treating a specific value as a kind of > "integer NaN" indicator. > >> Wasn't there a gcc option that enabled signed overflow? (I seem to >> remember enabling it to see if applications ran any slower.) >> > > "-fwrapv". OK, thanks. If I try that on two, tight, single-file C programs, then -fwrapv makes them 3-4% slower (comparing the fastest time of 20 runs each) If I apply it to one of my single-file transpiled-C files, then I get a 4% slowdown. However, using my original language non-C compiler, I can match or beat that faster time anyway. So this is likely a poor test because there are other things the C compiler has to contend with.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-03 15:06 +0200 |
| Message-ID | <10t7h8v$2t8lt$1@dont-email.me> |
| In reply to | #398230 |
On 03/05/2026 14:46, Bart wrote: > On 03/05/2026 12:27, David Brown wrote: >> On 03/05/2026 12:59, Bart wrote: >> >>> Can an implementation choose to make signed overflow well-defined? >>> >> >> The C standards say signed integer arithmetic overflow is undefined >> behaviour - which means the standards impose no requirements at all. >> >> That also means they impose no restrictions, and compilers can do as >> they want in the face of UB. Assuming a non-antagonistic compiler, >> that means doing what the compiler user wants in the face of UB. > > So UB can also just mean implementation-defined? > No. > I'm glad we cleared that up! It appears that we did not. "Implementation defined" means that the implementation has to define (and ideally document) a particular behaviour, usually from a restricted choice of options or guided by suggestions in the C standard. "Undefined behaviour" means the C standard says nothing about what can happen. An implementation can choose to do particular predictable and reliable things in the case of a particular type of UB. Or it can choose not to do so. This is totally different from IB. > > In addition, it can also mean that signed overflow can be just as well- > defined as unsigned 'overflow'. So that arguments about one being bad > and the other good are specious. > No. Of course it is possible to give a definition of signed integer arithmetic overflow, or any other kind of UB you pick. But that does not mean you have a "good" definition. To take a clearer example, you /could/ give a definition for 1 / 0 - you could say that in your programming language, division of integers is always normal division, rounded towards 0 (that's one of several rounding options) except that 1 / 0 is defined as 1. It's a definition, but is it a good one? Now you no longer have useful identities mixing multiplication and division. And 1 = (1 / 0) = (2 * 1) / (2 * 0) = 2 * (1 / 0) = 2 * 1 = 2. So you have given a definition for some UB and now have a language that says 1 == 2. It is /wrong/ to think that a definition is "good" or "useful" simply because it is defined. There are situations where particular defined behaviour of signed integer overflow can be useful, but no definition is inherently "good" because no definition gives the "correct" answer - because no correct answer exists. > This means that all the behaviours I observed with non-C languages and > non-optimising C compilers, that seem to be in line with how I and lots > of other people want, are likely by design, and not by chance, as some > have suggested. > Nobody has suggested that wrapping behaviour is "by chance". In particular, some people have explicitly told you they do not think it is by chance, and that they do not appreciate you claiming that they said so. Your arguments are not only unfounded, often exaggerated about what you think "other people" think or want, but cross the line into direct dishonesty. Please stop deliberately misrepresenting what other people write. > >> Usually that means generating more efficient (smaller and/or faster) >> code on the assumption that the UB is not hit at runtime. But it can >> also mean other things, typically under control of compiler flags, but >> sometimes set by default by the compiler. Two common choices are >> controlled error reports (like "-fsanitize=undefined" gives you on gcc >> ad clang), and specific defined behaviour. >> >> The most common choice of specific defined behaviour is wrapping, >> because that is usually efficient to implement, can occasionally be >> useful for detecting problems after the fact, and because some people >> have weird ideas about it being the "right" way to handle overflow >> despite the result usually being totally useless. Other specific >> behaviour that might be more useful, albeit less efficient on most >> hardware, includes saturation, or treating a specific value as a kind >> of "integer NaN" indicator. >> >>> Wasn't there a gcc option that enabled signed overflow? (I seem to >>> remember enabling it to see if applications ran any slower.) >>> >> >> "-fwrapv". > > OK, thanks. If I try that on two, tight, single-file C programs, then - > fwrapv makes them 3-4% slower (comparing the fastest time of 20 runs each) > Sure, do some irrelevant testing if you like. But I recommend that you use it for your own work, without regard to any speed benefits or costs, because it gives you the semantics you want from your C code. > If I apply it to one of my single-file transpiled-C files, then I get a > 4% slowdown. However, using my original language non-C compiler, I can > match or beat that faster time anyway. So this is likely a poor test > because there are other things the C compiler has to contend with. > >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-03 17:39 +0100 |
| Message-ID | <10t7tn9$30eqg$1@dont-email.me> |
| In reply to | #398231 |
On 03/05/2026 14:06, David Brown wrote: > On 03/05/2026 14:46, Bart wrote: >> On 03/05/2026 12:27, David Brown wrote: >>> On 03/05/2026 12:59, Bart wrote: >>> >>>> Can an implementation choose to make signed overflow well-defined? >>>> >>> >>> The C standards say signed integer arithmetic overflow is undefined >>> behaviour - which means the standards impose no requirements at all. >>> >>> That also means they impose no restrictions, and compilers can do as >>> they want in the face of UB. Assuming a non-antagonistic compiler, >>> that means doing what the compiler user wants in the face of UB. >> >> So UB can also just mean implementation-defined? >> > > No. "compilers can do what they want in the face of UB" Except make something implementation-defined? You're confusing matters. Can a compiler always choose to make signed overflow UB into a specific behaviour (eg. wrap) or not? If so, then my conclusion that UB /can/ be IB must be correct. > An implementation can choose to do particular predictable and reliable > things in the case of a particular type of UB. Or it can choose not to > do so. This is totally different from IB. You're saying contradictory things. I wonder if they have the same sorts of discussions about any other language. > There are situations where particular defined behaviour of signed > integer overflow can be useful, but no definition is inherently "good" > because no definition gives the "correct" answer - because no correct > answer exists. It doens't need to be useful, just consistent and reliable. Basically computer arithmetic is like a clock with the markings either from 0 to 255, or -128 to 127. It either wraps from 255 to 0, or 127 to -128 (or vice versa of course). >> This means that all the behaviours I observed with non-C languages and >> non-optimising C compilers, that seem to be in line with how I and >> lots of other people want, are likely by design, and not by chance, as >> some have suggested. >> > > Nobody has suggested that wrapping behaviour is "by chance". In KT: "Congratulations, you've demonstrated that all of those compilers generate code with one of the infinitely many possible behaviors consistent with UB." [2 * INT_MAX yielding -2] 'Infinitely many'. The implication was that those results were by luck. > Your arguments are not only unfounded, often exaggerated about what > you think "other people" think or want, but cross the line into direct > dishonesty. Please stop deliberately misrepresenting what other people > write. That so many other languages (Rextester only allowed 8; others were paywalled or I didn't know a language well-enough) demonstrate identical wrap behaviour that it seems a reasonable conclusion. >>> "-fwrapv". >> >> OK, thanks. If I try that on two, tight, single-file C programs, then >> - fwrapv makes them 3-4% slower (comparing the fastest time of 20 runs >> each) >> > > Sure, do some irrelevant testing if you like. The point has been made several times that this kind of UB helps optimisers. You're suggesting that putting that to the test is not relevant? OK... BTW I have always C considered a poor choice of intermediate language for all these reasons and more. It was just the best of what is available. I find it much better to directly generate native code, even if it means less than optimal performance, and support for fewer targets. Recent discussions have reinforced that. I'm working on a new project now where it is convenient, for development, to generate a HLL intermediate. I decided to use my systems language for that, the first time I've done so, and so far it is a much nicer experience. There is no unnecessary UB for a start!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-03 20:54 +0200 |
| Message-ID | <10t85ku$348o1$1@dont-email.me> |
| In reply to | #398234 |
On 03/05/2026 18:39, Bart wrote: > On 03/05/2026 14:06, David Brown wrote: >> On 03/05/2026 14:46, Bart wrote: >>> On 03/05/2026 12:27, David Brown wrote: >>>> On 03/05/2026 12:59, Bart wrote: >>>> >>>>> Can an implementation choose to make signed overflow well-defined? >>>>> >>>> >>>> The C standards say signed integer arithmetic overflow is undefined >>>> behaviour - which means the standards impose no requirements at all. >>>> >>>> That also means they impose no restrictions, and compilers can do as >>>> they want in the face of UB. Assuming a non-antagonistic compiler, >>>> that means doing what the compiler user wants in the face of UB. >>> >>> So UB can also just mean implementation-defined? >>> >> >> No. > > "compilers can do what they want in the face of UB" > > Except make something implementation-defined? You seem to be having serious trouble understanding this. I think you are doing so intentionally, to try to justify your claims that C and the C standards are so very difficult. UB does not mean the same as IB. UB can not not "just mean IB". But if the standard says something is UB, compilers can choose if they want to provide some specific semantics and implementation. > > You're confusing matters. Can a compiler always choose to make signed > overflow UB into a specific behaviour (eg. wrap) or not? Yes, a compiler can make that choice. No, that does not mean that "UB" can also "just mean IB". Regardless of what one compiler chooses to do, signed integer overflow is UB in C. You can, if you want, write non-portable code that relies on the additional semantics given by that one compiler. And signed integer overflow is just one kind of UB. What sort of IB do you think is appropriate for someone trying to dereference a pointer that does not point to an object compatible with the pointer's type? What do you think is appropriate for someone calling a function with parameter number and types that do not match the function's definition? What do you think is appropriate for trying to modify an object that is declared const? > > If so, then my conclusion that UB /can/ be IB must be correct. >> An implementation can choose to do particular predictable and reliable >> things in the case of a particular type of UB. Or it can choose not >> to do so. This is totally different from IB. > > You're saying contradictory things. > > I wonder if they have the same sorts of discussions about any other > language. > > >> There are situations where particular defined behaviour of signed >> integer overflow can be useful, but no definition is inherently "good" >> because no definition gives the "correct" answer - because no correct >> answer exists. > > It doens't need to be useful, just consistent and reliable. Basically > computer arithmetic is like a clock with the markings either from 0 to > 255, or -128 to 127. It either wraps from 255 to 0, or 127 to -128 (or > vice versa of course). What benefit is "consistent, reliable, and useless" ? That has no upside, and all the downsides of not being UB (for optimisation and bug-hunting). > >>> This means that all the behaviours I observed with non-C languages >>> and non-optimising C compilers, that seem to be in line with how I >>> and lots of other people want, are likely by design, and not by >>> chance, as some have suggested. >>> >> >> Nobody has suggested that wrapping behaviour is "by chance". In > > KT: "Congratulations, you've demonstrated that all of those compilers > generate code with one of the infinitely many possible behaviors > consistent with UB." [2 * INT_MAX yielding -2] > > 'Infinitely many'. The implication was that those results were by luck. There is no such implication, by any stretch of the imagination. UB has no requirements on the behaviour, so there are infinitely many possible behaviours that meet those non-existent requirements. That does not in any sense imply that compilers generate code randomly. It means you cannot rely on any specific behaviour (unless the compiler documents what it does, or how you can choose the behaviour you want). > > >> Your arguments are not only unfounded, often exaggerated about what >> you think "other people" think or want, but cross the line into direct >> dishonesty. Please stop deliberately misrepresenting what other >> people write. > > That so many other languages (Rextester only allowed 8; others were > paywalled or I didn't know a language well-enough) demonstrate identical > wrap behaviour that it seems a reasonable conclusion. > If you were considering buying a car, and went to the seller to test it, would you drive it forward 2 metres and declare you've tested it fully? Your so-called tests are pitiful, and useless for understanding anything. >>>> "-fwrapv". >>> >>> OK, thanks. If I try that on two, tight, single-file C programs, then >>> - fwrapv makes them 3-4% slower (comparing the fastest time of 20 >>> runs each) >>> >> >> Sure, do some irrelevant testing if you like. > > The point has been made several times that this kind of UB helps > optimisers. You're suggesting that putting that to the test is not > relevant? OK... You have shown yourself completely incapable of any realistic testing. Feel free to do whatever tests you like, but don't expect anyone else to take them seriously. > > BTW I have always C considered a poor choice of intermediate language > for all these reasons and more. It was just the best of what is available. > > I find it much better to directly generate native code, even if it means > less than optimal performance, and support for fewer targets. Recent > discussions have reinforced that. Of course you will be able to get better results without going through an intermediary language. C cannot express everything, while assembly gives you full flexibility. And when you don't properly understand C and its semantics, and have a source language that does not fit well with C semantics in a number of aspects, then you are not going to be able to generate C code that is efficient and correct. > > I'm working on a new project now where it is convenient, for > development, to generate a HLL intermediate. I decided to use my systems > language for that, the first time I've done so, and so far it is a much > nicer experience. > I wish you luck (genuinely). > There is no unnecessary UB for a start! I should note that there are plenty of things that are UB in C that I do not think should be UB, and would not be UB if I were designing a new language. There are lots of things that are UB that should be possible to detect and reject at compile time. There are many reasons why some of these are UB, but I would have preferred a different balance of choices. (As a simple example taken almost at random from Annex J.2 - it is UB if "The specification of a function type includes any type qualifiers". That should, IMHO, have been a constraint error.) Signed integer overflow UB is, on the other hand, a useful one. It is not really /necessary/, but it is useful and better than giving it defined behaviour.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-03 21:29 +0100 |
| Message-ID | <10t8b87$362vr$1@dont-email.me> |
| In reply to | #398239 |
On 03/05/2026 19:54, David Brown wrote: > On 03/05/2026 18:39, Bart wrote: > And signed integer overflow is just one kind of UB. I'm picking on that as one kind of unnecessary UB. I'm not suggesting making random accesses to memory well-defined, even though for read-access on simple architectures, those can arguably be well-defined too. >> It doens't need to be useful, just consistent and reliable. Basically >> computer arithmetic is like a clock with the markings either from 0 to >> 255, or -128 to 127. It either wraps from 255 to 0, or 127 to -128 (or >> vice versa of course). > > What benefit is "consistent, reliable, and useless" ? That has no > upside, and all the downsides of not being UB (for optimisation and bug- > hunting). Why is it useless? I start with a signed variable A containing a large +ve value. I add X to it so that it overflows into a -ve value. I later subtract X from it to get the original A. That is useful to be able to do, and to depend on, even though the intermediate result is incorrect (not A + X) But that can't happen in C because that intermediate value is UB. Even if you get around that, you say that that result is useless and meaningless anyway. I disagree. >> 'Infinitely many'. The implication was that those results were by luck. > > There is no such implication, by any stretch of the imagination. > UB has no requirements on the behaviour, so there are infinitely many > possible behaviours that meet those non-existent requirements. And yet all those implementations agreed on the exact same behaviour, out of all those apparently vast possibilities. Why that particular one, given that, according to you, it is useless? I would almost suspect this particular UB of being contrived! > > You have shown yourself completely incapable of any realistic testing. > Feel free to do whatever tests you like, but don't expect anyone else to > take them seriously. I'm so sorry. I had thought up to now that measuring runtimes was one way of comparing one set of options to another. Clearly you know better! So, how /does/ anyone figure out whether -fwrapv makes a difference to how well the same program can be optimised? > C cannot express everything, while assembly > gives you full flexibility. I normally use an IL designed for this level of language. For anything unusual, I can add a new instruction for it. And when you don't properly understand C > and its semantics, and have a source language that does not fit well > with C semantics in a number of aspects, then you are not going to be > able to generate C code that is efficient and correct. > >> >> I'm working on a new project now where it is convenient, for >> development, to generate a HLL intermediate. I decided to use my >> systems language for that, the first time I've done so, and so far it >> is a much nicer experience. >> > > I wish you luck (genuinely). Um, thanks. >> There is no unnecessary UB for a start! > > I should note that there are plenty of things that are UB in C that I do > not think should be UB, and would not be UB if I were designing a new > language. Example?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-03 23:11 +0200 |
| Message-ID | <10t8dmd$36amf$2@dont-email.me> |
| In reply to | #398248 |
On 03/05/2026 22:29, Bart wrote: > On 03/05/2026 19:54, David Brown wrote: >> On 03/05/2026 18:39, Bart wrote: > >> And signed integer overflow is just one kind of UB. > > I'm picking on that as one kind of unnecessary UB. In the sense that it is possible to define a behaviour for signed integer overflow, then I agree that having it as UB is not necessary. Equally, defining the behaviour of signed integer overflow is not necessary. And for most situations, it is not at all helpful. (To be clear, I appreciate that there /are/ situations where wrapping behaviour - signed or unsigned - can be useful. If I were designing a language, "x + y" would have undefined overflow, as that's the normal behaviour. But there would be a way to specifically request wrapping semantics - such as "wrapping_add(x, y)", or "x +% y" for a language that likes lots of operators.) > > I'm not suggesting making random accesses to memory well-defined, even > though for read-access on simple architectures, those can arguably be > well-defined too. > Okay, nice to know. >>> It doens't need to be useful, just consistent and reliable. Basically >>> computer arithmetic is like a clock with the markings either from 0 >>> to 255, or -128 to 127. It either wraps from 255 to 0, or 127 to -128 >>> (or vice versa of course). >> >> What benefit is "consistent, reliable, and useless" ? That has no >> upside, and all the downsides of not being UB (for optimisation and >> bug- hunting). > > Why is it useless? Because you said "it doesn't need to be useful". > > I start with a signed variable A containing a large +ve value. I add X > to it so that it overflows into a -ve value. > > I later subtract X from it to get the original A. > > That is useful to be able to do, and to depend on, even though the > intermediate result is incorrect (not A + X) > > But that can't happen in C because that intermediate value is UB. Even > if you get around that, you say that that result is useless and > meaningless anyway. I don't think "happens to work in this one test" is useful. I prefer to be sure. For example, I'd cast one of the variables to a larger type. Then I know it is all correct. That's useful. > > I disagree. > >>> 'Infinitely many'. The implication was that those results were by luck. >> >> There is no such implication, by any stretch of the imagination. > >> UB has no requirements on the behaviour, so there are infinitely many >> possible behaviours that meet those non-existent requirements. > > And yet all those implementations agreed on the exact same behaviour, > out of all those apparently vast possibilities. In this one example, yes. The test cannot be generalised (as shown by other examples that have been posted). > > Why that particular one, given that, according to you, it is useless? > In many cases, the code generated by C compilers for integer arithmetic gives results consistent with wrapping semantics when there is overflow. That is because that's the code that is most efficient when there is no overflow. It is not because it is the "correct" or "useful" result. > I would almost suspect this particular UB of being contrived! > >> >> You have shown yourself completely incapable of any realistic testing. >> Feel free to do whatever tests you like, but don't expect anyone else >> to take them seriously. > > I'm so sorry. I had thought up to now that measuring runtimes was one > way of comparing one set of options to another. > > Clearly you know better! Let's not beat this dead donkey any more. Look back on old threads if you like. >> >> I should note that there are plenty of things that are UB in C that I >> do not think should be UB, and would not be UB if I were designing a >> new language. > > Example? > You snipped an example I gave. There's a fair number of other UB's that I think could be realistic to catch at compile time, and I would prefer it if they were constraint errors rather than UB. (Compilers can typically warn about them, but may require options to do so in some cases.) For example, looking at the list in Annex J.2 of C23 (n3220), number 2 is "A nonempty source file does not end in a newline character which is not immediately preceded by a backslash character or ends in a partial preprocessing token or comment". /That/ is unnecessary UB, I believe. I can't think of any run-time UB where I have felt "I'd be able to write simpler, clearer or more efficient code if that were not UB". Perhaps the best candidate would be some aspects of shift operations that could be IB (or even fully defined) rather than UB. I'd like for there to be a way to access "raw memory" with something other than unsigned char - either by special types or special functions - without it being UB. I would not want that to apply to any access from any type, however. So not "-fno-strict-aliasing" semantics - more a standardisation of gcc's "mayalias" type attribute. (Equally, I'd prefer if unsigned char did not have it's special "alias anything" power, but that boat has sailed long ago.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-03 15:47 -0700 |
| Message-ID | <10t8j9f$36t8v$5@kst.eternal-september.org> |
| In reply to | #398248 |
Bart <bc@freeuk.com> writes:
> On 03/05/2026 19:54, David Brown wrote:
>> On 03/05/2026 18:39, Bart wrote:
[...]
>>> 'Infinitely many'. The implication was that those results were by luck.
>> There is no such implication, by any stretch of the imagination.
>
>> UB has no requirements on the behaviour, so there are infinitely
>> many possible behaviours that meet those non-existent requirements.
>
> And yet all those implementations agreed on the exact same behaviour,
> out of all those apparently vast possibilities.
>
> Why that particular one, given that, according to you, it is useless?
Nobody has explained why you got the results you got because, until now,
you haven't asked. You've used the result you got in a failed attempt
to refute someone's correct statement that other results are permitted
by the standard, and falsely claimed that I implied that your result is
explained by "luck".
Now that you've asked, I'll try to answer.
As you know, most CPUs implement signed integer addition in a way that
results in two's-complement wraparound, so for example INT_MAX+1 yields
INT_MIN. The example we've been using is something similar to:
int x = 2000000000; // assume 32-bit int
x = 2*x;
A compiler that doesn't "notice" the overflow will probably
generate code that performs a signed multiplication (perhaps a MUL
instruction) which yields a result of -294967296. Apparently that's
exactly what all the implementations you tried actually did.
It's not luck or chance. It's just compilers behaving in an
unsurprising manner.
A compiler that does "notice" the overflow might do exactly the
same thing. The behavior is undefined, so it might as well do the
simplest thing.
(Production code is more likely to get the value 2000000000 from
some input or computation, rather than from a constant as in this
toy example.)
Where you go wrong is in assuming that this says anything about what
the standard requires. The previous statement that a conforming
compiler *could* generate no code for `x = 2*x;`, because that
statement's behavior is inevitably undefined, was perfectly correct.
Nobody claimed that any compiler actually does that. You've wasted
a great deal of time refuting a claim that nobody made.
Note in particular that the C standard is designed to work with
target machines that do not perform signed arithmetic in the
most common manner. If a target system unconditionally traps on
signed overflow, you can have a conforming C compiler for it.
(If C required signed wraparound, it would still be possible,
but a bit more work.)
[...]
> So, how /does/ anyone figure out whether -fwrapv makes a difference to
> how well the same program can be optimised?
Probably by compiling code with and without -fwrapv and comparing the
performance and/or examining the generated assembly/machine code.
Why do you ask? (I'll note that you seem to be more interested in
that question that most of the rest of us, so if you want advice
you need to ask clearly.)
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-03 23:59 +0100 |
| Message-ID | <10t8jvm$385cm$2@dont-email.me> |
| In reply to | #398259 |
On 03/05/2026 23:47, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> So, how /does/ anyone figure out whether -fwrapv makes a difference to >> how well the same program can be optimised? > > Probably by compiling code with and without -fwrapv and comparing the > performance and/or examining the generated assembly/machine code. That's exactly what I did (compare runtimes), but David Brown called it 'irrelevant': "Sure, do some irrelevant testing if you like." And later said: "You have shown yourself completely incapable of any realistic testing. Feel free to do whatever tests you like, but don't expect anyone else to take them seriously." Forgive me for not taking those comments seriously. > Why do you ask? (I'll note that you seem to be more interested in > that question that most of the rest of us, so if you want advice > you need to ask clearly.) One of the biggest reasons given for signed overflow being UB is to enable extra optimisations. So how much of a difference does it actually make?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-04 09:28 +0200 |
| Message-ID | <10t9hrf$3f5eh$1@dont-email.me> |
| In reply to | #398261 |
On 04/05/2026 00:59, Bart wrote:
> On 03/05/2026 23:47, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> So, how /does/ anyone figure out whether -fwrapv makes a difference to
>>> how well the same program can be optimised?
>>
>> Probably by compiling code with and without -fwrapv and comparing the
>> performance and/or examining the generated assembly/machine code.
>
> That's exactly what I did (compare runtimes), but David Brown called it
> 'irrelevant':
>
> "Sure, do some irrelevant testing if you like."
Your examples were irrelevant, meaningless little functions taken out of
context. Other tests you did, any differences would be drowned out by
noise.
Most optimisation strategies that a compiler can do make very little
difference to most code, once you get past the basics (like keeping
local variables in registers). A compiler does not generate more
efficient code because of one optimisation - it does so because it has
dozens or hundreds of optimisations, each making perhaps 1% difference
on average. And for some optimisations, you get no difference in most
code but for some types of code you get a very significant difference.
Additionally, the effect of optimisations can depend on the type of
target processor. Modern x86 processors are designed to work fast with
terrible code, using massive register renaming, superscaling, stack
access buffers, etc., to get good speed from the poorly optimised code
that is so common in the x86 world. Most RISC processors, on the other
hand, expect better from compilers and have a balance more towards power
and space efficient cores. So where you might see only a small
difference in speeds between "gcc -O0" and "gcc -O2", I might see a
factor of 5 on my targets for some code.
To me, one of the biggest benefits of optimising is that I can write
code in a manner that maximises clarity, flexibility and
maintainability, and let the compiler worry about the details. When I
have, in the past, written code for use with weak compilers, I need to
think about how to write the source code in a way that will generate the
most efficient object code. I had to "hand optimise" - write code to
pre-calculate pointer addresses because the compiler could not do common
expression elimination for multiple uses of "xs[i + 1]", or manually
inline code, or use generic "temp" names for local variables and re-use
them because the compiler did not do variable lifetime analysis. If
code is written for weaker tools - and that's not uncommon in older
source code - there is less benefit from using good optimising
compilers. But of course the source is harder to write, harder to read,
and harder to re-use.
So when you take your example code, compile it with and without
"-ftrapv", and compare the results, then you have learned how much
difference the flag makes to that particular compilation of that
particular example on that particular target processor. This assumes,
of course, that you are actually measuring the speed of the code rather
than just differences in startup speed or the effects of whatever your
OS or other programs happen to be doing in the background.
Sometimes such testing can be helpful, because you are trying to get the
most efficient results for a particular piece of code on a particular
target. But it tells you virtually nothing about the benefits (or lack
thereof) of any given optimisation.
People who /actually/ test optimisation passes, such as the folks
working on big compilers, run automated benchmarks on large numbers of
code samples with lots of variations of flags and usually on multiple
different targets. And they are often not so much interested in some
kind of average figure, but the outliers - the code that is particularly
faster, or particularly slower.
>
> And later said:
>
> "You have shown yourself completely incapable of any realistic testing.
> Feel free to do whatever tests you like, but don't expect anyone else to
> take them seriously."
>
> Forgive me for not taking those comments seriously.
It was seriously meant.
>
>> Why do you ask? (I'll note that you seem to be more interested in
>> that question that most of the rest of us, so if you want advice
>> you need to ask clearly.)
>
>
> One of the biggest reasons given for signed overflow being UB is to
> enable extra optimisations. So how much of a difference does it actually
> make?
>
In some cases, a lot. In some cases, little or no difference.
Here is a little example for you. It's a function that copies from one
array to another, compiled with an without "-fwrapv". Look at the
difference in the inner loop. Run that loop 10 times, and there will be
no measurable difference. Run it 1000000000 times, and it's a different
story.
<https://godbolt.org/z/9nWMnPGPb>
void foo1(int xs[], int ys[], int n, int i, int j) {
while (n--) {
xs[i++] = ys[j++];
}
}
#pragma GCC optimize("-fwrapv")
void foo2(int xs[], int ys[], int n, int i, int j) {
while (n--) {
xs[i++] = ys[j++];
}
}
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-04 13:22 +0100 |
| Message-ID | <10ta31s$3ldg6$1@dont-email.me> |
| In reply to | #398279 |
On 04/05/2026 08:28, David Brown wrote: > On 04/05/2026 00:59, Bart wrote: >> On 03/05/2026 23:47, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >> >>>> So, how /does/ anyone figure out whether -fwrapv makes a difference to >>>> how well the same program can be optimised? >>> >>> Probably by compiling code with and without -fwrapv and comparing the >>> performance and/or examining the generated assembly/machine code. >> >> That's exactly what I did (compare runtimes), but David Brown called >> it 'irrelevant': >> >> "Sure, do some irrelevant testing if you like." > > Your examples were irrelevant, meaningless little functions taken out of > context. I didn't go into details of the examples, but they weren't little functions. One was a 30Kloc one-file version of Lua, running Fibonacci (but most runtime is spent within the innards of this interpreter). The other was a 9Kloc compression program called MZ, but running one particular test. If I do one more (Jpeg decoder on an 81Mpixel image), then I see the same difference, perhaps 3% better without -fwrapv, although that is small enough that, with varaiance, there is much overlap in the sets of timings. > Additionally, the effect of optimisations can depend on the type of > target processor. Modern x86 processors are designed to work fast with > terrible code, using massive register renaming, superscaling, stack > access buffers, etc., to get good speed from the poorly optimised code > that is so common in the x86 world. Yes, that, and various other approaches, helps account for several magnitudes of improvements in processing speed, over decades. On the other hand, the difference between optimised and unoptimised code from a compiler hasn't really progressed from a fraction of one magnitude, in that same time scale. This is why I don't get worked up over the 1.5 x typical faster speed (in my language) or 2.0 x faster (in C) that a massively complicated and slow-to-deploy compiler can achieve over my toy one. Of course, CPU designers can decide to create a chip that is very hard to program efficiently without using very clever compilers that know all its ins and outs, but that hasn't quite happened yet. I think Intel produced something like that (Itanium?) but which didn't make it. > Most RISC processors, on the other > hand, expect better from compilers and have a balance more towards power > and space efficient cores. So where you might see only a small > difference in speeds between "gcc -O0" and "gcc -O2", I might see a > factor of 5 on my targets for some code. I can get 5-10x easily, and on x64, just by generating terrible C! > So when you take your example code, compile it with and without "- > ftrapv", and compare the results, then you have learned how much > difference the flag makes to that particular compilation of that > particular example on that particular target processor. I wanted to know the trade-offs. I never used -fwrapv, so I get any benefits, and presumably none of my programs rely on the wrap-around thing. So I want to keep any small advantage, while not needing to care about that particular UB. But adding -fwrapv when compiling poor quality C probably won't make a significant difference. > People who /actually/ test optimisation passes, such as the folks > working on big compilers, run automated benchmarks on large numbers of > code samples with lots of variations of flags and usually on multiple > different targets. And they are often not so much interested in some > kind of average figure, but the outliers - the code that is particularly > faster, or particularly slower. They tend not to be interested in testing the compilers themselves for speed!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-03 15:17 -0700 |
| Message-ID | <10t8hi1$36t8v$4@kst.eternal-september.org> |
| In reply to | #398234 |
Bart <bc@freeuk.com> writes:
> On 03/05/2026 14:06, David Brown wrote:
>> On 03/05/2026 14:46, Bart wrote:
>>> On 03/05/2026 12:27, David Brown wrote:
>>>> On 03/05/2026 12:59, Bart wrote:
>>>>> Can an implementation choose to make signed overflow well-defined?
>>>>
>>>> The C standards say signed integer arithmetic overflow is
>>>> undefined behaviour - which means the standards impose no
>>>> requirements at all.
>>>>
>>>> That also means they impose no restrictions, and compilers can do
>>>> as they want in the face of UB. Assuming a non-antagonistic
>>>> compiler, that means doing what the compiler user wants in the
>>>> face of UB.
>>>
>>> So UB can also just mean implementation-defined?
>>>
>> No.
>
> "compilers can do what they want in the face of UB"
>
> Except make something implementation-defined?
Compilers cannot alter the wording of the C standard.
The term "implementation-defined" does not just mean "defined by the
implementation". For each behavior that the standard states is
implementation-defined, all conforming implementations must document how
they make the choice. An implementation can choose to define what it
does for signed integer overflow (or it can make a specific choice and
not bother to document it), but that doesn't fall under the standard's
definition of "implementation-defined behavior".
> You're confusing matters. Can a compiler always choose to make signed
> overflow UB into a specific behaviour (eg. wrap) or not?
Yes, it can.
> If so, then my conclusion that UB /can/ be IB must be correct.
No.
[...]
> I wonder if they have the same sorts of discussions about any other
> language.
Not here.
[...]
>> Nobody has suggested that wrapping behaviour is "by chance". In
>
> KT: "Congratulations, you've demonstrated that all of those compilers
> generate code with one of the infinitely many possible behaviors
> consistent with UB." [2 * INT_MAX yielding -2]
>
> 'Infinitely many'. The implication was that those results were by luck.
There was no such implication, and I honestly have no idea why you
think there was.
[...]
> The point has been made several times that this kind of UB helps
> optimisers. You're suggesting that putting that to the test is not
> relevant? OK...
I don't suggest that putting it to the test is irrelevant.
The results of the test you performed are unsurprising, but you've
reached invalid conclusions from them.
Someone asserted that a particular result is permitted.
You demonstrated that, with one implementation in a certain
configuration, you got a different result. I'm sure you did,
but that says nothing about the original correct assertion.
"If you drop a lead weight, you might break your foot."
"I just dropped a lead weight and didn't break my foot."
"So what?"
[...]
--
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 | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-05-04 14:14 -0700 |
| Message-ID | <10tb28l$3vok6$1@dont-email.me> |
| In reply to | #398234 |
On 5/3/2026 9:39 AM, Bart wrote: [...] A compiler vendor can take an UB and say, well, lets define it for fun, or whatever. It can say, if you do 1.0 / 0.0, we can make it 1.0 / 0.00000042 for shits and giggles. If you want pure std C, use this setting... If not, well, your UB will ride the train into the universe and beyond... ;^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-05-04 14:21 -0700 |
| Message-ID | <10tb2kg$3vs6s$1@dont-email.me> |
| In reply to | #398313 |
On 5/4/2026 2:14 PM, Chris M. Thomasson wrote: > On 5/3/2026 9:39 AM, Bart wrote: > [...] > > A compiler vendor can take an UB and say, well, lets define it for fun, > or whatever. It can say, if you do 1.0 / 0.0, we can make it 1.0 / > 0.00000042 for shits and giggles. If you want pure std C, use this > setting... If not, well, your UB will ride the train into the universe > and beyond... ;^) Say, without --xyz_std_c, the compiler is not strictly implementing standard C, but a C-like dialect where some undefined behaviors may be given defined semantics as a vendor extension. With --xyz_std_c, the compiler attempts to follow the C standard more closely, including treating UB as having no defined behavior
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-04 16:05 -0700 |
| Message-ID | <10tb8ns$14hf$1@kst.eternal-september.org> |
| In reply to | #398314 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 5/4/2026 2:14 PM, Chris M. Thomasson wrote:
>> On 5/3/2026 9:39 AM, Bart wrote:
>> [...]
>> A compiler vendor can take an UB and say, well, lets define it for
>> fun, or whatever. It can say, if you do 1.0 / 0.0, we can make it
>> 1.0 / 0.00000042 for shits and giggles. If you want pure std C, use
>> this setting... If not, well, your UB will ride the train into the
>> universe and beyond... ;^)
>
> Say, without --xyz_std_c, the compiler is not strictly implementing
> standard C, but a C-like dialect where some undefined behaviors may be
> given defined semantics as a vendor extension. With --xyz_std_c, the
> compiler attempts to follow the C standard more closely, including
> treating UB as having no defined behavior
Any treatment of UB conforms to the ISO C standard. That's what
the term means. The hypothetical "--xyz_std_c" option, as you
describe it, does not affect conformance.
A fully conforming compiler can implement extensions by defining
behavior for constructs that are otherwise UB. It can implement
extensions by defining behavior for constructs that violate a
constraint or syntax rule, but a diagnostic is still required.
The only restriction on extensions is that they cannot alter the
behavior of any strictly conforming program.
A compiler can, of course, provide an option to disable all
extensions, but a conforming impementation is not required to
do so. Compilers are not required to provide any options at all.
"[T]reating UB as having no defined behavior", whatever that means,
is neither more nor less conforming than any other treatment.
It happens that most C compilers (at least the ones I've used)
are not conforming by default, but can be made to (attempt to)
be conforming with some command-line or other option.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 5 of 37 — ← Prev page 1 … 3 4 [5] 6 7 … 37 Next page →
Back to top | Article view | comp.lang.c
csiph-web