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 18 of 37 — ← Prev page 1 … 16 17 [18] 19 20 … 37 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-08 21:47 +0000 |
| Message-ID | <bSsLR.374135$HcOe.210583@fx20.iad> |
| In reply to | #398533 |
antispam@fricas.org (Waldek Hebisch) writes: >Bart <bc@freeuk.com> wrote: >> On 06/05/2026 20:35, Dan Cross wrote: >>> Everything on the list you presented is one or more of, >>> a. subjective, >>> b. arguably a bad choice, >>> c. hardly novel. >>> >>> None of it is evidence that your language "runs rings around C". >> >> I could provide a 100-long list that goes into more micro-features but >> I'd be wasting my time. There's no point in providing links either. You >> have already made up your mind. >> >> Note that: > >Let me put numbers to identify the claims: > >> * There are no C-style header files The same as most mainframe languages (well, COBOL had the COPY verb, as did the Burroughs Programming Language (BPL) and the OS implementation language SPRITE (rather modula2-like). >1. >> * There are no separate declarations needed, neither in shared headers, >> nor as prototypes >2. >> * If a module is imported by 50 others, it is processed exactly once >3. >> * Project info (modules etc) is present in only one module of a project. >> (Most module schemes require import directives in every module) >4. >> * That means no external build system is needed. >5. >> Just that is HUGE. All of this was the norm in the late 1970s. And it may be HUGE to you, but clearly it's more YAWN to everyone else. > >Well, UCSD/Turbo Pascal, Ada, Modula 2, Oberon all have module system >satisfying 3 and 5. UCSD/Turbo Pascal and Oberon do not have >separate interface files, so satisfy 1 (Ada and Modula 2 have >separate interface files, but they have different nature than >C header files). Oberon satisfies 2. So only possibly novel part >is 4. Burroughs SPRITE had a "module interface definition" which was a single file that held common definitions and defined data and instruction groupings (a la '.psect') for a an application. The operating system (MCP) was written in SPRITE, an the MID for the MCP was rather large. SPRITE language development began in the mid 1970s. Ultimately, that line of computers was discontinued (last one was powered off in 2010, first one powered on in 1964).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-08 22:58 +0100 |
| Message-ID | <10tlm9r$37dfl$1@dont-email.me> |
| In reply to | #398537 |
On 08/05/2026 22:47, Scott Lurndal wrote: > antispam@fricas.org (Waldek Hebisch) writes: >> Bart <bc@freeuk.com> wrote: >>> On 06/05/2026 20:35, Dan Cross wrote: > >>>> Everything on the list you presented is one or more of, >>>> a. subjective, >>>> b. arguably a bad choice, >>>> c. hardly novel. >>>> >>>> None of it is evidence that your language "runs rings around C". >>> >>> I could provide a 100-long list that goes into more micro-features but >>> I'd be wasting my time. There's no point in providing links either. You >>> have already made up your mind. >>> >>> Note that: >> >> Let me put numbers to identify the claims: >> >>> * There are no C-style header files > > The same as most mainframe languages (well, COBOL had the > COPY verb, as did the Burroughs Programming Language (BPL) > and the OS implementation language SPRITE (rather modula2-like). > > >> 1. >>> * There are no separate declarations needed, neither in shared headers, >>> nor as prototypes >> 2. >>> * If a module is imported by 50 others, it is processed exactly once >> 3. >>> * Project info (modules etc) is present in only one module of a project. >>> (Most module schemes require import directives in every module) >> 4. >>> * That means no external build system is needed. >> 5. >>> Just that is HUGE. > > All of this was the norm in the late 1970s. And it may be HUGE > to you, but clearly it's more YAWN to everyone else. So what happened since the late 70s? We're still doing independent compilation, still doing linking, still use makefiles. In fact its got a lot more complex rather than simpler. And in C (since the the comparison was with that) we STILL have massive sets of header files per library (nobody has managed to reduce them to a single compact file for production use) that has to be re-processed by every module of a project that uses even one entity in the library.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-08 16:56 -0700 |
| Message-ID | <86v7cxsbfq.fsf@linuxsc.com> |
| In reply to | #398539 |
Bart <bc@freeuk.com> writes: [... discussing #include files and module systems ...] > So what happened since the late 70s? We're still doing independent > compilation, still doing linking, still use makefiles. In fact its > got a lot more complex rather than simpler. > > And in C (since the the comparison was with that) we STILL have > massive sets of header files per library (nobody has managed to > reduce them to a single compact file for production use) that has > to be re-processed by every module of a project that uses even one > entity in the library. Languages with distinct modules and interfaces have their own problems. Neither approach is perfect; each has its own pluses and minuses.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-09 07:37 +0200 |
| Message-ID | <10tmh69$1l93k$4@dont-email.me> |
| In reply to | #398539 |
On 2026-05-08 23:58, Bart wrote: > > So what happened since the late 70s? We're still doing independent > compilation, still doing linking, still use makefiles. Luckily! > In fact its got a lot more complex rather than simpler. I'm shocked that even after thorough explanations of the Real Life outside your mental biotope nothing has reached your perception. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-09 17:39 +0000 |
| Message-ID | <mjKLR.486190$bBq.74987@fx06.iad> |
| In reply to | #398539 |
Bart <bc@freeuk.com> writes: >On 08/05/2026 22:47, Scott Lurndal wrote: >> antispam@fricas.org (Waldek Hebisch) writes: >>> Bart <bc@freeuk.com> wrote: <snip> >> >> >>> 1. >>>> * There are no separate declarations needed, neither in shared headers, >>>> nor as prototypes >>> 2. >>>> * If a module is imported by 50 others, it is processed exactly once >>> 3. >>>> * Project info (modules etc) is present in only one module of a project. >>>> (Most module schemes require import directives in every module) >>> 4. >>>> * That means no external build system is needed. >>> 5. >>>> Just that is HUGE. >> >> All of this was the norm in the late 1970s. And it may be HUGE >> to you, but clearly it's more YAWN to everyone else. > >So what happened since the late 70s? The state of the art has advanced. Modern development tools provide additional capabilities when compared the rather primitive tools of the 1970s. Much of this is due to the additional resources available (disk space, memory and faster CPUs) over time.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-05-09 00:05 +0000 |
| Message-ID | <10tltnu$183an$1@paganini.bofh.team> |
| In reply to | #398537 |
Scott Lurndal <scott@slp53.sl.home> wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
>>Bart <bc@freeuk.com> wrote:
>>> On 06/05/2026 20:35, Dan Cross wrote:
>
>>>> Everything on the list you presented is one or more of,
>>>> a. subjective,
>>>> b. arguably a bad choice,
>>>> c. hardly novel.
>>>>
>>>> None of it is evidence that your language "runs rings around C".
>>>
>>> I could provide a 100-long list that goes into more micro-features but
>>> I'd be wasting my time. There's no point in providing links either. You
>>> have already made up your mind.
>>>
>>> Note that:
>>
>>Let me put numbers to identify the claims:
>>
>>> * There are no C-style header files
>
> The same as most mainframe languages (well, COBOL had the
> COPY verb, as did the Burroughs Programming Language (BPL)
> and the OS implementation language SPRITE (rather modula2-like).
>
>
>>1.
>>> * There are no separate declarations needed, neither in shared headers,
>>> nor as prototypes
>>2.
>>> * If a module is imported by 50 others, it is processed exactly once
>>3.
>>> * Project info (modules etc) is present in only one module of a project.
>>> (Most module schemes require import directives in every module)
>>4.
>>> * That means no external build system is needed.
>>5.
>>> Just that is HUGE.
>
> All of this was the norm in the late 1970s.
Are you sure? Note that we speak about modules, not about separate
compilation. AFAICS separate compilation was the norm. But
Separate compilation either did not type check external references
or used extern declarations. Without something like C header files
(or COBOL COPY or includes via PL/1 preprocessor) extern declarations
could easily get out of sync. Module system ensures that module
internal things are invisible from outside and only exported
things are visible. Also, module system ensures that "the same"
names (even exported ones) in different modules do not clash.
In case which would otherwise led to clash one can use qualified
names. When there is no clash one can import names from other
modules and use them without qualifiecation. Each use of things
from other modules is type checked.
If you mean that having module system was the norm for languages
created in late 1970s, then this may be true, certainly several
languages created in this periad had module system. If you
mean that using module system was the norm in late 1970s, then
this is definitly false.
> And it may be HUGE
> to you, but clearly it's more YAWN to everyone else.
>
>>
>>Well, UCSD/Turbo Pascal, Ada, Modula 2, Oberon all have module system
>>satisfying 3 and 5. UCSD/Turbo Pascal and Oberon do not have
>>separate interface files, so satisfy 1 (Ada and Modula 2 have
>>separate interface files, but they have different nature than
>>C header files). Oberon satisfies 2. So only possibly novel part
>>is 4.
>
> Burroughs SPRITE had a "module interface definition" which was
> a single file that held common definitions and defined
> data and instruction groupings (a la '.psect') for a
> an application. The operating system (MCP) was written
> in SPRITE, an the MID for the MCP was rather large.
>
> SPRITE language development began in the mid 1970s.
>
> Ultimately, that line of computers was discontinued (last one
> was powered off in 2010, first one powered on in 1964).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-09 00:37 +0100 |
| Message-ID | <10tls2u$39j7a$1@dont-email.me> |
| In reply to | #398533 |
On 08/05/2026 22:02, Waldek Hebisch wrote:
> Bart <bc@freeuk.com> wrote:
>> Huh. This is C:
>>
>> uint64_t F(uint64_t s, uint64_t t, uint64_t u, uint64_t v) ...
>>
>> This is my language:
>>
>> func F(u64 s, t, u, v)u64 ...
>>
>> All the parameters are the same type. If you change that first u64, they
>> all change. The parameter names are 's t u v'.
>
> Yes, in this case having single type for parameters is simpler.
>
>> They are the same types in the C too, but you have to work harder to
>> double-check they are in fact identical. If you change that type, then
>> you have to change it at multiple sites; if you forget one, the compiler
>> will not tell you.
>
> Well, if there is mismatch, them compiler will tell you. If types
> make sense, but are different than intended, then you have trouble.
> But this trouble is not different from situation where you need to
> change one type, but keep other unchanged. For example, if you
> need
>
> uint64_t F(uint64_t s, uint64_t t, uint32_t u, uint64_t v)
>
> In such case C version is easier to modify correctly.
C has the same ability outside parameter lists. Imagine having to type this:
struct {float x; float y; float z;} ....
instead of:
struct {float x, y, z;} ....
> Anyway, in last 35 years programmable editors were widely available.
> If need to type extra characters bothers you,
It is the clutter, and not being able to see the parameters at a glance.
Especially if single-letter names are appropriate, but each type is
'heavier'.
>> Note that:
>
> Let me put numbers to identify the claims:
>
>> * There are no C-style header files
> 1.
>> * There are no separate declarations needed, neither in shared headers,
>> nor as prototypes
> 2.
>> * If a module is imported by 50 others, it is processed exactly once
> 3.
>> * Project info (modules etc) is present in only one module of a project.
>> (Most module schemes require import directives in every module)
> 4.
>> * That means no external build system is needed.
> 5.
>> Just that is HUGE.
>
> Well, UCSD/Turbo Pascal, Ada, Modula 2, Oberon all have module system
> satisfying 3 and 5. UCSD/Turbo Pascal and Oberon do not have
> separate interface files, so satisfy 1 (Ada and Modula 2 have
> separate interface files, but they have different nature than
> C header files). Oberon satisfies 2. So only possibly novel part
> is 4.
> Looking at implementation decisions, there were strong voices for
> separate interface files. So 1 is at least "subjective". I
> would say that 2 is probably "arguably bad idea". Concerning 4,
> I routinely use a module system where import directive are
> sometimes unnecessary: basicaly 'import' means that names from
> given module may be used without qualification. If somebody
> decided to use only qualified names, then 'import' is not
> necessary. Arguably, information saying from which module to
> take given name (and given module may simultaneously use the
> same name from multiple modules) is part of source code of
> given module. You apparently think differently, but I want
> to keep related things together, so want this information
> included in module source. So for me your 4 is "arguably
> bad idea".
I went through several versions of the module scheme. They all worked,
but with problems.
For example, with one version, each module of a 50-module project say,
would have a rag-tag collection of imports at the top, with whatever
subset of the other 49 was currently needed, that needed constant
maintainence.
Then you renamed one module, or combined two, or split one into two, and
you had a lot of editing to do. This kind is very common.
You see the equivalent in C with long collections of header files, but
here you have to generate and maintain the header files too, and you
have to hunt for them within the file system.
> Note that all languages that I mention are at roughly similar
> level as C, all are more (Oberon) or less (Ada) niche now.
> But I think that each of them has more users than your
> language (original UCSD Pascal and Turbo Pascal are dead, but
> there are Turbo Pascal compatible products in current developement).
>
> Also, users and developers of those languages probably think
> that they "run rings around C", but do not come here to complain
> how bad C is.
C sits at a particular level and mine is at about the same place.
For example, FreePascal transpiles to C; you don't hear of C transpiling
to FreePascal!
So C is that kind of language, and mine would also be if someone kindly
wrote decent compilers for it. But for its main platform, it can also be
used the same way (I'm doing that right now).
> Anyway, when you come here and propose your language as alternative
> to C,
I'm not pushing my languages at all; they are personal. I was replying
to this:
"You keep referring to your "systems language" as evidence that C
is bad. C may be bad; there are even ways that I think that C
_is_ bad. But your opinion is not evidence, and given that you
have shown it to be founded on misconceptions, it is utterly
irrelevant."
I'm showing I can create a decent language, one that has been tried and
tested so I know what worked and what didn't. And that enables me to
make an informed comparison with C, which is used in the same space.
> then you implicitly claim that your language is better than
> Ada, Modula 2, Pascal and a lot of other languages which competed
> with C.
Well, they didn't compete with C very well. Where were the real contenders?!
C was informal, and small, and allowed you great freedom (more than
necessary), but the way it was presented was poor (syntax etc) and now
is very dated (header files and relying too much on its token-based
macros to fix shortcomings).
Anyway, I'm not making a comparison with those. If I hadn't devised my
language (say my place of work provided the language to be used), then
most likely I would have been using C, not Pascal or Ada (which was
anyway still in the future).
> Even more, since C programmers did not switch to other
> languages earlier, your language must be _much_ better than
> other ones. Do you realize how grandiose claim it is? Maybe
> you do not mean this, but that is impression that you give.
No. I understand that in reality mine is a crappy little one-man
language that should have been put out of its misery at least 25 years
ago. It has no trendy modern features, no docs, no users, no libraries,
no nothing.
But one of the reasons it's still going is because C is, showing there
is still a demand for that class of primitive language. In that case I
know that niche pretty well!
It that case, then yes it is much more polished, is somewhat safer, with
fewer quirks and fewer surprises. This is the simplest function pointer
type in C, and in my language:
void(*)(void)
ref proc
and the same type used to declare variable:
void(*fnptr)(void);
ref proc fnptr
and here, an array of 10 of those pointers:
void(*table[10])(void);
[10]ref proc table
But, this is the kicker: to write that last C version, I had to use a
tool to figure where the parentheses and square brackets go. What kind
of HLL is that?!
Unless you're going argue that C's syntax has the edge, then my language
is indeed better.
I'm not claiming it's unique either (eg. my syntax was taken from
Algol68), but most modern alternatives are bigger and more ambitious.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-09 01:57 +0000 |
| Message-ID | <10tm49i$9d$1@reader1.panix.com> |
| In reply to | #398556 |
In article <10tls2u$39j7a$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 08/05/2026 22:02, Waldek Hebisch wrote: >> [snip] >> Note that all languages that I mention are at roughly similar >> level as C, all are more (Oberon) or less (Ada) niche now. >> But I think that each of them has more users than your >> language (original UCSD Pascal and Turbo Pascal are dead, but >> there are Turbo Pascal compatible products in current developement). >> >> Also, users and developers of those languages probably think >> that they "run rings around C", but do not come here to complain >> how bad C is. > >C sits at a particular level and mine is at about the same place. > >For example, FreePascal transpiles to C; You mean `fpc`? I see no evidence for that. I just looked at https://www.freepascal.org and I see no documentation about the compiler generating C code; it appears to generate object code for the target platform, and the software requirements don't mention a C compiler. >you don't hear of C transpiling >to FreePascal! ...why would you? FreePascal came much later, at which point C compilers were ubiquitous. If having `fpc` installed already implied that you had a C compiler like you suggested, why would someone write a C compiler that generated FreePascal code just so that `fpc` could turn it back into C to be compiled with that compiler? Why wouldn't they just compile the C code with the C compiler? >> Anyway, when you come here and propose your language as alternative >> to C, > >I'm not pushing my languages at all; they are personal. I was replying >to this: > >"You keep referring to your "systems language" as evidence that C >is bad. C may be bad; there are even ways that I think that C >_is_ bad. But your opinion is not evidence, and given that you >have shown it to be founded on misconceptions, it is utterly >irrelevant." > >I'm showing I can create a decent language, one that has been tried and >tested so I know what worked and what didn't. And that enables me to >make an informed comparison with C, which is used in the same space. No. Having a good understanding of C would enable you to make a good comparison with C. But, again, you haven't demonstrated that you have a good understanding of C, and you've expressed negative interest in gaining such understanding, so whatever you know about your own language is irrelevant. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-09 11:56 +0100 |
| Message-ID | <10tn3so$3j8hc$1@dont-email.me> |
| In reply to | #398566 |
On 09/05/2026 02:57, Dan Cross wrote: > In article <10tls2u$39j7a$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >> On 08/05/2026 22:02, Waldek Hebisch wrote: >>> [snip] >>> Note that all languages that I mention are at roughly similar >>> level as C, all are more (Oberon) or less (Ada) niche now. >>> But I think that each of them has more users than your >>> language (original UCSD Pascal and Turbo Pascal are dead, but >>> there are Turbo Pascal compatible products in current developement). >>> >>> Also, users and developers of those languages probably think >>> that they "run rings around C", but do not come here to complain >>> how bad C is. >> >> C sits at a particular level and mine is at about the same place. >> >> For example, FreePascal transpiles to C; > > You mean `fpc`? I see no evidence for that. I just looked at > https://www.freepascal.org and I see no documentation about the > compiler generating C code; it appears to generate object code > for the target platform, and the software requirements don't > mention a C compiler. When I tried it about a decade ago, it appeared to use a C backend from what I can remember. The same with Nim, or GHC. Or languages like Euphoria or Seed7 which are interpreted, but can lower to C as an option. But it is also possible I mixed it up with FreeBasic (I tried both). Programs however move on. If I download it now, then it does bundle something called 'gcc.exe', but it is a stub: it can load C files, but it is missing 'cc1'. The point is that some HLL X is commonly transpiled to C, either for bootstrapping, or for early versions or as an option. C rarely transpiles to some other HLL X, for the purposes of implementing C. But it sometimes does when language X wants to migrate existing C code to X. >> I'm showing I can create a decent language, one that has been tried and >> tested so I know what worked and what didn't. And that enables me to >> make an informed comparison with C, which is used in the same space. > > No. Having a good understanding of C would enable you to make a > good comparison with C. But, again, you haven't demonstrated > that you have a good understanding of C, and you've expressed > negative interest in gaining such understanding, so whatever you > know about your own language is irrelevant. As I kept saying, anybody can subjectively compare any language with any other as it pertains to their sphere, their experience and their requirements, down to individual features. In my case: * Pretty much all coding I did, outside of assembly and scripting, was for applications that anyone else would have used C for. * ALL of that was achieved via the features of my own languages * All the generated code was done via my own tools right down to the binary So for a particular micro-task, to get it from concept A in the source code to B in the binary executable for machine M, I know exactly how I expect it to work. I can then compare that with using C to try and get from A to B. I don't care how it does it internally or what are the reasons why it might give different behaviour. There are reasonable adjustments you need to make to switch languages, and there are unreasonables ones, such as needing to become a guru in the new language. Or having to use workarounds because your code has to work without UB on the DS9000, even though you are only interested in M, which has the same characteristics as all other target machines you are likely to use. And for my language, you can substitute 'X'. So I refute your claim that somebody can't make a comparison or express a preference without such indepth knowledge.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-09 15:18 +0000 |
| Message-ID | <10tnj8s$pnq$1@reader1.panix.com> |
| In reply to | #398578 |
In article <10tn3so$3j8hc$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 09/05/2026 02:57, Dan Cross wrote: >> In article <10tls2u$39j7a$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >>> On 08/05/2026 22:02, Waldek Hebisch wrote: >>>> [snip] >>>> Note that all languages that I mention are at roughly similar >>>> level as C, all are more (Oberon) or less (Ada) niche now. >>>> But I think that each of them has more users than your >>>> language (original UCSD Pascal and Turbo Pascal are dead, but >>>> there are Turbo Pascal compatible products in current developement). >>>> >>>> Also, users and developers of those languages probably think >>>> that they "run rings around C", but do not come here to complain >>>> how bad C is. >>> >>> C sits at a particular level and mine is at about the same place. >>> >>> For example, FreePascal transpiles to C; >> >> You mean `fpc`? I see no evidence for that. I just looked at >> https://www.freepascal.org and I see no documentation about the >> compiler generating C code; it appears to generate object code >> for the target platform, and the software requirements don't >> mention a C compiler. > >When I tried it about a decade ago, it appeared to use a C backend from >what I can remember. The same with Nim, or GHC. Or languages like >Euphoria or Seed7 which are interpreted, but can lower to C as an option. That's not true for GHC, either. It does use an intermediate representation language called "Cmm" that is described as a, "simple, C like language". But that is not C, and the compiler either generates native code or LLVM IR. I don't know about Nim. A cursory glance indicates that it has backends targeting a number of languages in the C family (C, C++, Objective-C) and JavaScript. The C backend seems to be the default. >But it is also possible I mixed it up with FreeBasic (I tried both). FreeBASIC appears to generate native code. >Programs however move on. If I download it now, then it does bundle >something called 'gcc.exe', but it is a stub: it can load C files, but >it is missing 'cc1'. This doesn't seem particularly relevant to anything. However, you may be confused because I'm some of these tools may invoke `gcc` (or similar) as a command driver to invoke the platform assembler and/or linker. But that doesn't mean they're invoking it to compile C source code (this can be surprisingly tedious, depending on the platform). >The point is that some HLL X is commonly transpiled to C, either for >bootstrapping, or for early versions or as an option. > >C rarely transpiles to some other HLL X, for the purposes of >implementing C. Why would it? C compilers are ubiquitous. I don't see how this is relevant to anything. >But it sometimes does when language X wants to migrate >existing C code to X. Ok. That's not C treating another language as (effectively) an IR, though. That's automated conversion. It may technically meet a definition of "transpilation", but it is qualitatively a different thing than what, say, `cfront` did for C++ in the early days. >>> I'm showing I can create a decent language, one that has been tried and >>> tested so I know what worked and what didn't. And that enables me to >>> make an informed comparison with C, which is used in the same space. >> >> No. Having a good understanding of C would enable you to make a >> good comparison with C. But, again, you haven't demonstrated >> that you have a good understanding of C, and you've expressed >> negative interest in gaining such understanding, so whatever you >> know about your own language is irrelevant. > >As I kept saying, anybody can subjectively compare any language with any >other as it pertains to their sphere, their experience and their >requirements, down to individual features. Sure. That doesn't mean those analyses are well-informed or useful. In your case, you don't have a good handle on C. Despite your protestations to the contrary, you've shown this repeatedly. Therefore, neither your opinion about C, nor your comparisons of C to your own language, are particularly useful. Having successfully used your ownyour own language, which I am sure that you do know very well, certainly does not factor into the matter. In particular given that you lack the critical requisite understanding _of C_ to make any comparison meaningful. Put another way, you can say whatever you want, but no one else is obliged to care. >In my case: > >* Pretty much all coding I did, outside of assembly and scripting, was >for applications that anyone else would have used C for. ...and so? You didn't use C for it, and you don't know C, so it does not follow that any of that prior experience matters here. >* ALL of that was achieved via the features of my own languages Ok. But that's not C, and you don't know C, so it's not relevant to discussing C. >* All the generated code was done via my own tools right down to the binary Ok. But that's not relevant to discussing C, either. >So for a particular micro-task, to get it from concept A in the source >code to B in the binary executable for machine M, I know exactly how I >expect it to work. Ok, but your expectation has no bearing on C. >I can then compare that with using C to try and get from A to B. No, that doesn't follow, since you don't know C. >I don't care how it does it internally or what are the reasons why it >might give different behaviour. This is why none of what you wrote above particularly matters. You don't care about C _as it is defined_. You only care about how _you think it should work based on your intuition_. Your incredulity at its definition not matching your expectations has no bearing on anything at all. >There are reasonable adjustments you need to make to switch languages, >and there are unreasonables ones, such as needing to become a guru in >the new language. It strikes me that you need to know the language if you want to use and discuss it. I understand that you do not want to use C. That's fine; no one is forcing you to. But if you want to discuss C, you'd get a lot more traction (and a lot less pushback) if you actually learned it. >Or having to use workarounds because your code has to work without UB on >the DS9000, even though you are only interested in M, which has the same >characteristics as all other target machines you are likely to use. Read: you need to know how to use the language. I gather you find C fiddly. That's ok; I find C fiddly. It is what it is, however, and no amount of gnashing teeth or wailing in despair is going to change that. >And for my language, you can substitute 'X'. > >So I refute your claim that somebody can't make a comparison or express >a preference without such indepth knowledge. You can complain about it all you want: the secret C police are not going to show up at your door in the middle of the night and take you away in your bathrobe. However, if you want others to take your critique seriously, then you need to actually _understand the language as it is_. You have repeatedly shown that you do not understand the language, and are not interested in understanding it. That, too, is fine; no one is forcing you to study something you don't want to study. But because of that, few are going to take your critique particularly seriously, either. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-09 17:16 +0100 |
| Message-ID | <10tnmk6$3os5b$1@dont-email.me> |
| In reply to | #398590 |
On 09/05/2026 16:18, Dan Cross wrote:
> In article <10tn3so$3j8hc$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>> When I tried it about a decade ago, it appeared to use a C backend from
>> what I can remember. The same with Nim, or GHC. Or languages like
>> Euphoria or Seed7 which are interpreted, but can lower to C as an option.
>
> That's not true for GHC, either. It does use an intermediate
> representation language called "Cmm" that is described as a,
> "simple, C like language". But that is not C, and the compiler
> either generates native code or LLVM IR.
That first download I did of it was 1800MB. 300MB of that was bundled
gcc installation. That may have changed.
> I don't know about Nim. A cursory glance indicates that it has
> backends targeting a number of languages in the C family (C,
> C++, Objective-C) and JavaScript. The C backend seems to be the
> default.
>
>> But it is also possible I mixed it up with FreeBasic (I tried both).
>
> FreeBASIC appears to generate native code.
FBC seems to include a working gcc.exe program.
If I do 'fib64 -R hello.bas' then it produces the C file below.
(You can also see from this that /nobody/ likes stdint.h types, even
though standardised from C99 which also introduced 'long long' used
here. That is another bugbear. Oh, I forgot, my criticism is not not valid.)
>> Programs however move on. If I download it now, then it does bundle
>> something called 'gcc.exe', but it is a stub: it can load C files, but
>> it is missing 'cc1'.
>
> This doesn't seem particularly relevant to anything.
We're drifting from my point, which is that C is in that small category,
of a deceptively simple and malleable language that would be a good fit
for a target language.
I'm saying mine would be in that group, which is my I'm doing
comparisons with Pascal or Ada which have been brought up.
> However,
> you may be confused because I'm some of these tools may invoke
> `gcc` (or similar) as a command driver to invoke the platform
> assembler and/or linker.
Probably. But I don't know what FPC looked like when I first tried it.
> Why would it? C compilers are ubiquitous.
For the major platforms, so are compilers for dozens of languages.
> You don't care about C _as it is defined_. You only care about
> how _you think it should work based on your intuition_. Your
> incredulity at its definition not matching your expectations has
> no bearing on anything at all.
If you disagree with an opinion of mine, would be make it any difference
if I knew the C standard inside out? You are hardly going to change your
mind.
Suppose I proposed for example that C should deprecate, then ban, the
ability to write:
A[i]
B[i][j]
respectively as:
i[A]
j[i[A]]
(The last one is a little mind-blowing, as it turns one 2D array access
- two consecutive 1D accesses) into two /nested/ 1D accesses.)
Basically, it would mean addition between pointers and integers would
not be commutative: P + i, but not i + P.
You will either agree with this or not. But I can't see that it requires
any deep knowledge of the standard to make such a proposal, or why
somebody would require that of me in order to even consider it.
>> There are reasonable adjustments you need to make to switch languages,
>> and there are unreasonables ones, such as needing to become a guru in
>> the new language.
>
> It strikes me that you need to know the language if you want to
> use and discuss it.
You want EVERYBODY who uses C to know the standard in as much depth as
KT, JK and TR? (Maybe a few others too but they don't seem that bothered
about it.)
(I've just tried the above proposal in my C compiler. It took half a
minute to find where I had to comment out 4 lines to make it work.
As it happens, because this ability has been there a long time, some
programs use it, for example from sqlite:
nPage = nPageHeader = get4byte(28+(u8*)pPage1->aData);
So this change is not going to happen, and people will continue writing
quirky things like 3["ABCDEF"] just for the hell of it.
This is the story of C.)
Output from fbc64 -R hello.bas:
-----------------------------
typedef signed char int8;
typedef unsigned char uint8;
typedef signed short int16;
typedef unsigned short uint16;
typedef signed int int32;
typedef unsigned int uint32;
typedef signed long long int64;
typedef unsigned long long uint64;
typedef struct { char *data; int64 len; int64 size; } FBSTRING;
typedef int8 boolean;
void fb_PrintString( int32, FBSTRING*, int32 );
FBSTRING* fb_StrAllocTempDescZEx( char*, int64 );
void fb_Init( int32, char**, int32 );
void fb_End( int32 );
void fb_Sleep( int32 );
int32 main( int32 __FB_ARGC__$0, char** __FB_ARGV__$0 )
{
int32 fb$result$0;
__builtin_memset( &fb$result$0, 0, 4ll );
fb_Init( __FB_ARGC__$0, (char**)__FB_ARGV__$0, 0 );
label$0:;
FBSTRING* vr$1 = fb_StrAllocTempDescZEx( (char*)"Hello from
FreeBASIC!", 21ll );
fb_PrintString( 0, (FBSTRING*)vr$1, 1 );
FBSTRING* vr$2 = fb_StrAllocTempDescZEx( (char*)"Press any key to
continue...", 28ll );
fb_PrintString( 0, (FBSTRING*)vr$2, 1 );
fb_Sleep( -1 );
label$1:;
fb_End( 0 );
return fb$result$0;
}
-----------------------------
Looks like C to me!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-09 18:38 +0200 |
| Message-ID | <10tnnv1$3o0n8$2@dont-email.me> |
| In reply to | #398594 |
On 09/05/2026 18:16, Bart wrote: > On 09/05/2026 16:18, Dan Cross wrote: >> In article <10tn3so$3j8hc$1@dont-email.me>, Bart <bc@freeuk.com> wrote: > > (You can also see from this that /nobody/ likes stdint.h types, even > though standardised from C99 which also introduced 'long long' used > here. That is another bugbear. Oh, I forgot, my criticism is not not > valid.) > Don't you realise that when you write things like that, you are only demonstrating why so many people do not take you seriously? Have you checked with every C programmer, and every person writing systems that generate C code, and checked that none of them like the <stdint.h> types? No? I thought not. Some people use them extensively. Some people have little use for size-specific types. Some people want size-specific types, but for some reason (good or bad) want to use C90 rather than C99. Some people like the <stdint.h> types but for some reason (good or bad) are unable to use them in certain cases. Some people dislike the <stdint.h> types, but use them anyway. I like them. I use them a lot (the size-specific types). I like the names, which I think are clear. If I were programming in a language that used a different naming scheme for fixed-size types, I'd use the scheme from that language - whether or not I thought it was the best names they could have (that would depend on the rest of the language). I don't like the macros for printing them, but then I don't need printf much except for testing and debugging. But I can't tell you what anyone else does, or what anyone else likes. I can't see how you can claim to know that /nobody/ likes them. > >>> Programs however move on. If I download it now, then it does bundle >>> something called 'gcc.exe', but it is a stub: it can load C files, but >>> it is missing 'cc1'. >> >> This doesn't seem particularly relevant to anything. > > We're drifting from my point, which is that C is in that small category, > of a deceptively simple and malleable language that would be a good fit > for a target language. > Your language would not be a good fit, because it is a home-made personal language with no traction. If it were popular (it does not need to be massively popular), with multiple developers, a group who discuss the language design decisions, proper documentation, and a reasonable user base, /then/ maybe it would be a possible fit for such use. The suitability of a language for a particular purpose cannot be determined from one single user's personal preferences. > I'm saying mine would be in that group, which is my I'm doing > comparisons with Pascal or Ada which have been brought up. > >> However, >> you may be confused because I'm some of these tools may invoke >> `gcc` (or similar) as a command driver to invoke the platform >> assembler and/or linker. > > Probably. But I don't know what FPC looked like when I first tried it. > >> Why would it? C compilers are ubiquitous. > > For the major platforms, so are compilers for dozens of languages. > Almost invariably, C is the first language to be targeted for compilers for a platform. It does not matter whether you like that or not, it is a fact. > >> You don't care about C _as it is defined_. You only care about >> how _you think it should work based on your intuition_. Your >> incredulity at its definition not matching your expectations has >> no bearing on anything at all. > > If you disagree with an opinion of mine, would be make it any difference > if I knew the C standard inside out? You are hardly going to change your > mind. > > Suppose I proposed for example that C should deprecate, then ban, the > ability to write: > > A[i] > B[i][j] > > respectively as: > > i[A] > j[i[A]] > > (The last one is a little mind-blowing, as it turns one 2D array access > - two consecutive 1D accesses) into two /nested/ 1D accesses.) I am happy to agree that this is an odd effect of the way these operators are defined in C. I agree that code which is written this way would seem unnecessarily confusing. On the face of it, I'd agree that making the change you suggest would reduce the ability of people to write odd code. I am fairly confident that none of the C committee think it is a good idea to write "i[A]" or "j[i[B]]" rather than "A[i]" or "B[i][j]". But does that mean it would be a good idea to make the change to the C standards? Changes to the standards are not free. There may be good reasons to keep addition commutative here (I don't know what these might be). Or it may simply be that it's not worth the effort. Trying to lock down a language so that people can't write strange things is a fool's errand. > > Basically, it would mean addition between pointers and integers would > not be commutative: P + i, but not i + P. > > You will either agree with this or not. But I can't see that it requires > any deep knowledge of the standard to make such a proposal, or why > somebody would require that of me in order to even consider it. > An opinion about preferences for a particular piece of syntax does not need deep knowledge beyond that bit of code. An opinion on whether it would be a good idea to change the standard to fit that preference, or on what other peoples' preferences might be, or any unexpected consequences or impacts of such a change - /that/ requires a deep knowledge.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-09 19:20 +0100 |
| Message-ID | <10tntu0$3r6q3$1@dont-email.me> |
| In reply to | #398595 |
On 09/05/2026 17:38, David Brown wrote: > On 09/05/2026 18:16, Bart wrote: >> (You can also see from this that /nobody/ likes stdint.h types, even >> though standardised from C99 which also introduced 'long long' used >> here. That is another bugbear. Oh, I forgot, my criticism is not not >> valid.) > > Don't you realise that when you write things like that, you are only > demonstrating why so many people do not take you seriously? Have you > checked with every C programmer, and every person writing systems that > generate C code, and checked that none of them like the <stdint.h> > types? No? I thought not. So, what's the figure? I see this pattern frequently (sometimes every other project seemingly) so they are unpopular for some. And we don't know if people using uint8_t etc are doing so because they genuinely like it or feel obliged to use it. (Tim Rentsch also seems to avoid it here.) Perhaps try asking why somebody would invent a new type name for uint8_t at all. > Some people use them extensively. Some people have little use for size- > specific types. Some people want size-specific types, but for some > reason (good or bad) want to use C90 rather than C99. Some people like > the <stdint.h> types but for some reason (good or bad) are unable to use > them in certain cases. Some people dislike the <stdint.h> types, but > use them anyway. So they can be problematic. And they are optional which is another matter. > Your language would not be a good fit, because it is a home-made > personal language with no traction. I'm not suggesting take up of it. The point is that it is in that same category. >>> Why would it? C compilers are ubiquitous. >> >> For the major platforms, so are compilers for dozens of languages. >> > > Almost invariably, C is the first language to be targeted for compilers > for a platform. It does not matter whether you like that or not, it is > a fact. If are looking for a HLL language to target for a new language, this is not going to be a brand-new platform. It will be an established one with lots of choices. >> Basically, it would mean addition between pointers and integers would >> not be commutative: P + i, but not i + P. >> >> You will either agree with this or not. But I can't see that it >> requires any deep knowledge of the standard to make such a proposal, >> or why somebody would require that of me in order to even consider it. >> > > An opinion about preferences for a particular piece of syntax does not > need deep knowledge beyond that bit of code. An opinion on whether it > would be a good idea to change the standard to fit that preference, or > on what other peoples' preferences might be, or any unexpected > consequences or impacts of such a change - /that/ requires a deep > knowledge. Well I made that change and the first app I tried failed because relied on 'i + P', if not 'A[i]', but C doesn't allow you to separate those. The next two were OK, but the fourth also used it: add32le(p + 2, x + s1->plt->data - p); (From Tiny C sources.) So it looks use 'i + P' is already too widespread even to deprecate it. It would have needed to be banned from the start. Then that line would simply have been written as: add32le(p + 2, s1->plt->data - p + x); At least, I made the change and tested it on real programs.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-10 04:15 +0000 |
| Message-ID | <10tp0ob$rpp$1@reader1.panix.com> |
| In reply to | #398599 |
In article <10tntu0$3r6q3$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 09/05/2026 17:38, David Brown wrote: >> On 09/05/2026 18:16, Bart wrote: > >>> (You can also see from this that /nobody/ likes stdint.h types, even >>> though standardised from C99 which also introduced 'long long' used >>> here. That is another bugbear. Oh, I forgot, my criticism is not not >>> valid.) >> >> Don't you realise that when you write things like that, you are only >> demonstrating why so many people do not take you seriously? Have you >> checked with every C programmer, and every person writing systems that >> generate C code, and checked that none of them like the <stdint.h> >> types? No? I thought not. > >So, what's the figure? What does it matter? >I see this pattern frequently (sometimes every other project seemingly) >so they are unpopular for some. And we don't know if people using >uint8_t etc are doing so because they genuinely like it or feel obliged >to use it. ...so? >(Tim Rentsch also seems to avoid it here.) ...and? That is one person. He has his own preferences. I don't know whether or not he likes <stdint.h>, but what bearing does that have on anything? Actually, come to think of it, I've never seen Tim Rentsch post about hampsters here, either. Clearly, that must mean that no one in the world likes those absurdly cute little rodents. >Perhaps try asking why somebody would invent a new type name for uint8_t >at all. I can think of a few reasons why someone might do that. Most of them come down to subjective preference. So what? >> Some people use them extensively. Some people have little use for size- >> specific types. Some people want size-specific types, but for some >> reason (good or bad) want to use C90 rather than C99. Some people like >> the <stdint.h> types but for some reason (good or bad) are unable to use >> them in certain cases. Some people dislike the <stdint.h> types, but >> use them anyway. > >So they can be problematic. And they are optional which is another matter. *sigh* >> Your language would not be a good fit, because it is a home-made >> personal language with no traction. > >I'm not suggesting take up of it. The point is that it is in that same >category. > >>>> Why would it? C compilers are ubiquitous. >>> >>> For the major platforms, so are compilers for dozens of languages. >> >> Almost invariably, C is the first language to be targeted for compilers >> for a platform. It does not matter whether you like that or not, it is >> a fact. > >If are looking for a HLL language to target for a new language, this is >not going to be a brand-new platform. > >It will be an established one with lots of choices. I am struggling to see a point to those whole line of discussion. Earlier it seemed like you were somehow trying to say that this notion that one can target any number of languages as (effectively) an IR for the output of a compiler somehow had something to do with C, particularly as one seldom sees C target another language in a similar manner. Now it just seems like you're just ... saying words. Though for what reason, I cannot fathom. >>> Basically, it would mean addition between pointers and integers would >>> not be commutative: P + i, but not i + P. >>> >>> You will either agree with this or not. But I can't see that it >>> requires any deep knowledge of the standard to make such a proposal, >>> or why somebody would require that of me in order to even consider it. >> >> An opinion about preferences for a particular piece of syntax does not >> need deep knowledge beyond that bit of code. An opinion on whether it >> would be a good idea to change the standard to fit that preference, or >> on what other peoples' preferences might be, or any unexpected >> consequences or impacts of such a change - /that/ requires a deep >> knowledge. > >Well I made that change and the first app I tried failed because relied >on 'i + P', if not 'A[i]', but C doesn't allow you to separate those. This is getting silly. You're talking about a hypothetical change to C in which the abstruse quirk that allows one to write A[i] as i[A] is removed. Ok; as a thought experiment, one can conceive of such a change. But now you are asserting that this change must necessarily break the existing commutative properties on pointer arithmetic, justified by saying, "C doesn't allow you to separate those." But what you are describing is an imagined change to the rules of C; that is, of what C allows. If one wants to entertain the idea of changing *that* language rule, then I see no reason why one can not entertain simultaneously changing things so that commutativity of pointer arithmetic is preserved. That that is not done now is fine; we're talking about changing how things are done right now anyway. >The next two were OK, but the fourth also used it: > > add32le(p + 2, x + s1->plt->data - p); > >(From Tiny C sources.) So it looks use 'i + P' is already too widespread >even to deprecate it. I see no reason why you have to deprecate that. True, it is not how the language is defined today, but you're talking about a hypothetical. >It would have needed to be banned from the start. Then that line would >simply have been written as: > > add32le(p + 2, s1->plt->data - p + x); > >At least, I made the change and tested it on real programs. You made _a_ change. If anything, the issues you uncovered perhaps highlight that changing the language can have unintended consequences, and should be done with care, from a place of deep understanding of the language. Indeed, that understanding is a prerequisite for not making a complete hash of things. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-10 11:29 +0200 |
| Message-ID | <10tpj5s$98ol$1@dont-email.me> |
| In reply to | #398599 |
On 09/05/2026 20:20, Bart wrote: > On 09/05/2026 17:38, David Brown wrote: >> On 09/05/2026 18:16, Bart wrote: > >>> (You can also see from this that /nobody/ likes stdint.h types, even >>> though standardised from C99 which also introduced 'long long' used >>> here. That is another bugbear. Oh, I forgot, my criticism is not not >>> valid.) >> >> Don't you realise that when you write things like that, you are only >> demonstrating why so many people do not take you seriously? Have you >> checked with every C programmer, and every person writing systems that >> generate C code, and checked that none of them like the <stdint.h> >> types? No? I thought not. > > So, what's the figure? I am not claiming figures - I /know/ I don't know. The point is, I also know that /you/ don't know. > > I see this pattern frequently (sometimes every other project seemingly) > so they are unpopular for some. And we don't know if people using > uint8_t etc are doing so because they genuinely like it or feel obliged > to use it. We all know that some people don't use them - even in situations where they could be useful. C90 did not have <stdint.h>. So projects that were started before widespread support for C99 would necessarily have a different solution for size-specific integer types (assuming such types were useful for the project). Future versions of these projects and other code that uses such projects would be likely to continue usage of the non-standard size-specific integer types for compatibility and consistency. This tells us /nothing/ about whether or not anyone involved likes or dislikes <stdint.h> types. Outside of that, what do we actually know? I know that lots of people use <stdint.h> types. I know that lots of people do not. I have no idea of the likes or dislikes of any of them. In fact, I'd say that the only data we can be sure about is that /you/ don't like them, and /I/ do like them. So based on currently available survey data, 50% of C programmers like <stdint.h> types. Or, since you don't actually do C programming, 100% of surveyed C programmers who expressed an opinion like <stdint.h> types. Feel free to provide more comprehensive data and statistics, if you can back them up. > > (Tim Rentsch also seems to avoid it here.) Tim has his own opinions and preferences on many things. He may also have reasons for writing code in a way that does not represent those preferences. I've seen him post code using <stdint.h> types, and code that does not use those types (I can't remember ever seeing him use a size-specific type that was not a standard one, but I cannot rule out that posssibility). So I cannot see how you can conclude anything about Tim's preferences on the matter - or why you could possibly think the opinions of a single person are relevant to your claims. > > Perhaps try asking why somebody would invent a new type name for uint8_t > at all. > I am not the one making unsubstantiated and wildly exaggerated claims. > >> Some people use them extensively. Some people have little use for >> size- specific types. Some people want size-specific types, but for >> some reason (good or bad) want to use C90 rather than C99. Some >> people like the <stdint.h> types but for some reason (good or bad) are >> unable to use them in certain cases. Some people dislike the >> <stdint.h> types, but use them anyway. > > So they can be problematic. And they are optional which is another matter. > I don't see why you think they are "problematic" - certainly that is not something I said or implied. The commonly used <stdint.h> types are not optional. An implementation is required to provide types like int8_t and uint32_t for all bit sizes for which it supports an appropriate standard or extended integer type. Thus if an implementation has, for example, a 16-bit short int, then it must provide int16_t and uint16_t. If it has a 24-bit int type, then it must provide int24_t. And so on. The "least" and "fast" types of size 8, 16, 32 and 64 are not optional. Other sizes there /are/ optional - otherwise the <stdint.h> header would be infinite in length and implementations would have to support integers of every size conceivable. >> Your language would not be a good fit, because it is a home-made >> personal language with no traction. > > I'm not suggesting take up of it. The point is that it is in that same > category. No, it is not. Being a simple relatively low-level language (assuming that is correct) is not sufficient for the purpose. > >>>> Why would it? C compilers are ubiquitous. >>> >>> For the major platforms, so are compilers for dozens of languages. >>> >> >> Almost invariably, C is the first language to be targeted for >> compilers for a platform. It does not matter whether you like that or >> not, it is a fact. > > If are looking for a HLL language to target for a new language, this is > not going to be a brand-new platform. > > It will be an established one with lots of choices. You are arguing about hypotheticals. When new languages are made that use an existing high-level language as a transpiler backend, that HLL is most commonly C. While some effort has been made to establish re-usable alternatives for the task (such as "C--"), no such effort has gained significant traction. So despite its flaws for this purpose (real or imagined), C is good enough that it is not worth the effort creating an alternative, and other existing languages have more disadvantages. > >>> Basically, it would mean addition between pointers and integers would >>> not be commutative: P + i, but not i + P. >>> >>> You will either agree with this or not. But I can't see that it >>> requires any deep knowledge of the standard to make such a proposal, >>> or why somebody would require that of me in order to even consider it. >>> >> >> An opinion about preferences for a particular piece of syntax does not >> need deep knowledge beyond that bit of code. An opinion on whether it >> would be a good idea to change the standard to fit that preference, or >> on what other peoples' preferences might be, or any unexpected >> consequences or impacts of such a change - /that/ requires a deep >> knowledge. > > Well I made that change and the first app I tried failed because relied > on 'i + P', if not 'A[i]', but C doesn't allow you to separate those. > > The next two were OK, but the fourth also used it: > > add32le(p + 2, x + s1->plt->data - p); > > (From Tiny C sources.) So it looks use 'i + P' is already too widespread > even to deprecate it. > > It would have needed to be banned from the start. Then that line would > simply have been written as: > > add32le(p + 2, s1->plt->data - p + x); > > At least, I made the change and tested it on real programs. So you discovered that your knowledge was too superficial to give an informed opinion, and after learning more, you discovered that something you thought should "obviously" be changed in C, cannot be changed. I guess that's progress!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-10 03:25 -0700 |
| Message-ID | <10tpme7$a1ls$1@kst.eternal-september.org> |
| In reply to | #398630 |
David Brown <david.brown@hesbynett.no> writes:
> On 09/05/2026 20:20, Bart wrote:
[...]
>> Well I made that change and the first app I tried failed because
>> relied on 'i + P', if not 'A[i]', but C doesn't allow you to
>> separate those.
>> The next two were OK, but the fourth also used it:
>> add32le(p + 2, x + s1->plt->data - p);
>> (From Tiny C sources.) So it looks use 'i + P' is already too
>> widespread even to deprecate it.
>> It would have needed to be banned from the start. Then that line
>> would simply have been written as:
>> add32le(p + 2, s1->plt->data - p + x);
>> At least, I made the change and tested it on real programs.
>
> So you discovered that your knowledge was too superficial to give an
> informed opinion, and after learning more, you discovered that
> something you thought should "obviously" be changed in C, cannot be
> changed. I guess that's progress!
No, made a change in his own compiler to forbid index[array]
and mistakenly thought that it should also forbid index+pointer.
Again, see the C2y draft that makes index[array] obsolescent without
touching pointer arithmetic.
--
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-10 12:29 +0100 |
| Message-ID | <10tpq7e$a6kp$3@dont-email.me> |
| In reply to | #398630 |
On 10/05/2026 10:29, David Brown wrote: > On 09/05/2026 20:20, Bart wrote: >> Well I made that change and the first app I tried failed because >> relied on 'i + P', if not 'A[i]', but C doesn't allow you to separate >> those. >> >> The next two were OK, but the fourth also used it: >> >> add32le(p + 2, x + s1->plt->data - p); >> >> (From Tiny C sources.) So it looks use 'i + P' is already too >> widespread even to deprecate it. >> >> It would have needed to be banned from the start. Then that line would >> simply have been written as: >> >> add32le(p + 2, s1->plt->data - p + x); >> >> At least, I made the change and tested it on real programs. > > So you discovered that your knowledge was too superficial to give an > informed opinion, So, what did I miss? And about what; the prevalance of i+P arithmetic in C codebases? I suspect you didn't know that either. > and after learning more, you discovered that something > you thought should "obviously" be changed in C, cannot be changed. I > guess that's progress! Well it /can/ be changed, but it would be too draconian when dealing with legacy code. It requires constructs like i[A] to be deprecated, while still allowing i + A. That is also possible, but is not as simple a change, since C currently requires them to be interchangeable, and that is baked in to my compiler.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-10 12:39 +0000 |
| Message-ID | <10tpuam$cd$2@reader1.panix.com> |
| In reply to | #398635 |
In article <10tpq7e$a6kp$3@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 10/05/2026 10:29, David Brown wrote: >> On 09/05/2026 20:20, Bart wrote: >>> Well I made that change and the first app I tried failed because >>> relied on 'i + P', if not 'A[i]', but C doesn't allow you to separate >>> those. >>> >>> The next two were OK, but the fourth also used it: >>> >>> add32le(p + 2, x + s1->plt->data - p); >>> >>> (From Tiny C sources.) So it looks use 'i + P' is already too >>> widespread even to deprecate it. >>> >>> It would have needed to be banned from the start. Then that line would >>> simply have been written as: >>> >>> add32le(p + 2, s1->plt->data - p + x); >>> >>> At least, I made the change and tested it on real programs. >> >> So you discovered that your knowledge was too superficial to give an >> informed opinion, > >So, what did I miss? And about what; the prevalance of i+P arithmetic in >C codebases? I suspect you didn't know that either. Apparently, you missed the changes afoot in the committee to do exactly what everyone has been telling you: deprecate `i[A]` but preserve `i + A`. >> and after learning more, you discovered that something >> you thought should "obviously" be changed in C, cannot be changed. I >> guess that's progress! > >Well it /can/ be changed, but it would be too draconian when dealing >with legacy code. > >It requires constructs like i[A] to be deprecated, while still allowing >i + A. How is that draconian? >That is also possible, but is not as simple a change, since C currently >requires them to be interchangeable, and that is baked in to my compiler. Sounds like a problem for you and your compiler. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-10 14:51 +0100 |
| Message-ID | <10tq2he$d08i$2@dont-email.me> |
| In reply to | #398639 |
On 10/05/2026 13:39, Dan Cross wrote: > In article <10tpq7e$a6kp$3@dont-email.me>, Bart <bc@freeuk.com> wrote: >> On 10/05/2026 10:29, David Brown wrote: >>> On 09/05/2026 20:20, Bart wrote: >>>> Well I made that change and the first app I tried failed because >>>> relied on 'i + P', if not 'A[i]', but C doesn't allow you to separate >>>> those. >>>> >>>> The next two were OK, but the fourth also used it: >>>> >>>> add32le(p + 2, x + s1->plt->data - p); >>>> >>>> (From Tiny C sources.) So it looks use 'i + P' is already too >>>> widespread even to deprecate it. >>>> >>>> It would have needed to be banned from the start. Then that line would >>>> simply have been written as: >>>> >>>> add32le(p + 2, s1->plt->data - p + x); >>>> >>>> At least, I made the change and tested it on real programs. >>> >>> So you discovered that your knowledge was too superficial to give an >>> informed opinion, >> >> So, what did I miss? And about what; the prevalance of i+P arithmetic in >> C codebases? I suspect you didn't know that either. > > Apparently, you missed the changes afoot in the committee to do > exactly what everyone has been telling you: deprecate `i[A]` but > preserve `i + A`. The current standard says that those have to be tied together: 6.5.2.1p2. However, I also, independently (and off the top of my head), came up with a proposal that is being actually considered. Well, done, Bart! Oh, hang on, EVERY SINGLE THING I SAY AND DO HERE IS WRONG. I forgot that part. >>> and after learning more, you discovered that something >>> you thought should "obviously" be changed in C, cannot be changed. I >>> guess that's progress! >> >> Well it /can/ be changed, but it would be too draconian when dealing >> with legacy code. >> >> It requires constructs like i[A] to be deprecated, while still allowing >> i + A. > > How is that draconian? If implemented by removing pointer+int commutativity, too many programs would fail. My first attempt did that since I wanted to honour 6.5.2.1p. If I broke 6.5.2.1p2, then it was more successful. Programs using i[A] are much rarer than those using i+P. >> That is also possible, but is not as simple a change, since C currently >> requires them to be interchangeable, and that is baked in to my compiler. > > Sounds like a problem for you and your compiler. Always with the positives! You just have to keep bullying don't you. It turns out that disallowing i[A] while keeping i+P was even simpler because of the way my compiler works.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-10 16:28 +0000 |
| Message-ID | <10tqbno$6hn$2@reader1.panix.com> |
| In reply to | #398645 |
In article <10tq2he$d08i$2@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 10/05/2026 13:39, Dan Cross wrote: >> In article <10tpq7e$a6kp$3@dont-email.me>, Bart <bc@freeuk.com> wrote: >>> On 10/05/2026 10:29, David Brown wrote: >>>> On 09/05/2026 20:20, Bart wrote: >>>>> Well I made that change and the first app I tried failed because >>>>> relied on 'i + P', if not 'A[i]', but C doesn't allow you to separate >>>>> those. >>>>> >>>>> The next two were OK, but the fourth also used it: >>>>> >>>>> add32le(p + 2, x + s1->plt->data - p); >>>>> >>>>> (From Tiny C sources.) So it looks use 'i + P' is already too >>>>> widespread even to deprecate it. >>>>> >>>>> It would have needed to be banned from the start. Then that line would >>>>> simply have been written as: >>>>> >>>>> add32le(p + 2, s1->plt->data - p + x); >>>>> >>>>> At least, I made the change and tested it on real programs. >>>> >>>> So you discovered that your knowledge was too superficial to give an >>>> informed opinion, >>> >>> So, what did I miss? And about what; the prevalance of i+P arithmetic in >>> C codebases? I suspect you didn't know that either. >> >> Apparently, you missed the changes afoot in the committee to do >> exactly what everyone has been telling you: deprecate `i[A]` but >> preserve `i + A`. > >The current standard says that those have to be tied together: 6.5.2.1p2. Yes. But you're hypothesizing a change to the language. In that context, binding yourself to that doesn't make a lot of sense. Suggesting the subscript part of the change and then pointing to this as an impediment, and then using that to make some kind of statement about C (which is, I gather, what you're doing) is specious. >However, I also, independently (and off the top of my head), came up >with a proposal that is being actually considered. Ok. >Well, done, Bart! Sure. You've come up with something that most folks seem to be in agreement about. Good on you. >Oh, hang on, EVERY SINGLE THING I SAY AND DO HERE IS WRONG. I forgot >that part. Now that is just dramatic. >>>> and after learning more, you discovered that something >>>> you thought should "obviously" be changed in C, cannot be changed. I >>>> guess that's progress! >>> >>> Well it /can/ be changed, but it would be too draconian when dealing >>> with legacy code. >>> >>> It requires constructs like i[A] to be deprecated, while still allowing >>> i + A. >> >> How is that draconian? > >If implemented by removing pointer+int commutativity, too many programs >would fail. My first attempt did that since I wanted to honour 6.5.2.1p. So don't do that. >If I broke 6.5.2.1p2, then it was more successful. Programs using i[A] >are much rarer than those using i+P. Amazing. >>> That is also possible, but is not as simple a change, since C currently >>> requires them to be interchangeable, and that is baked in to my compiler. >> >> Sounds like a problem for you and your compiler. > >Always with the positives! You just have to keep bullying don't you. You made a general statement about the language based on what you perceived as a difficult implementing a change in your compiler. That doesn't follow. I made a statement of fact: the issue you saw was a problem for you to address in your compiler: it had little to do with the language itself. That's not bullying. >It turns out that disallowing i[A] while keeping i+P was even simpler >because of the way my compiler works. Ok. - Dan C.
[toc] | [prev] | [next] | [standalone]
Page 18 of 37 — ← Prev page 1 … 16 17 [18] 19 20 … 37 Next page →
Back to top | Article view | comp.lang.c
csiph-web