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 7 of 37 — ← Prev page 1 … 5 6 [7] 8 9 … 37 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-05 13:02 +0000 |
| Message-ID | <10tcppe$4ll$1@reader1.panix.com> |
| In reply to | #398336 |
In article <10tbh2v$3khv$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>On 05/05/2026 01:48, Dan Cross wrote:
>> In article <10tb2pv$3v9t1$2@dont-email.me>, Bart <bc@freeuk.com> wrote:
>>> On 04/05/2026 22:14, Chris M. Thomasson wrote:
>>>> On 5/3/2026 9:39 AM, Bart wrote:
>>>> [...]
>>>>
>>>> A compiler vendor can take an UB and say, well, lets define it for fun,
>>>> or whatever. It can say, if you do 1.0 / 0.0, we can make it 1.0 /
>>>> 0.00000042 for shits and giggles. If you want pure std C, use this
>>>> setting... If not, well, your UB will ride the train into the universe
>>>> and beyond... ;^)
>>>
>>> I don't now about UB for floating point.
>>>
>>> For the one under discussion which is arithmetic between integers,
>>> suppose there was a choice of just two compilers:
>>>
>>> (1) On overflow, it just loses the top significant bits of the result
>>>
>>> (2) On overflow, it will set your computer on fire and burn your house down
>>>
>>> There are no options to change that behaviour.
>>
>> This is silly and reductive.
>>
>> The point about saying that something is "UB" originally came
>> from different machines doing things differently; C chose to
>> kick that can down the road by simply declaring that the result
>> was "undefined." "Nasal demons" were never anything more than a
>> euphamism.
>>
>> The computing world is, in so many ways, simpler now than it was
>> then: we've got 2's complement machines everywhere, bytes are
>> pretty much uniformly sized at 8 bits, multi-byte values have
>> power of two widths, and so on.
>
>That was happening at about the time I came in, around the late 70s,
>after starting off on word-based mainframes. C however has taken decades
>to adapt, and it still hasn't fully.
Because, as I said, the incentives changed. They went from, "oh
gee, all these machines are different; we can't possibly define
what this means" to, "oh gee, we can use the undefined nature of
$X to make code faster." They'd probably argue that they've
adapted just fine; just not in the direction they wanted you to.
>> So now, "UB" has come to mean
>> that a compiler can make assumptions about code to introduce
>> aggressive optimizations: if it is undefined what happens when
>> signed integer arithmetic overflows, then the the compiler can
>> choose to use a saturating instruction instead of a regular
>> arithmetic instruction that wraps; or it can trap; or elide the
>> instruction entirely.
>>
>> All of those options are correct, because as far as the language
>> is concerned, what the compiler does is undefined, so anything
>> it does is thus definitionally "correct."
>
>This is where I get lost. The language could easily have narrowed down
>the possibilities.
See above.
>> This differs from "implementation defined" in that IB _is_ well
>> defined; it's just that the actual behavior depends on the
>> implementation. For example, the integer value of the code
>> point corresponding to the character constant 'A' is IB: in
>> ASCII is 65 dec, but in EBCDIC it is 193. It is perfectly
>> well-defined to assign that to an `int`, but the actual value
>> depends on the implementation.
>>
>>> Which would you choose? Personally, I would shoot the person who
>>> mandated random, unchecked behaviour in the first place.
>>
>> No, you wouldn't. You are not going to shoot anybody. It is
>> weird when people say things like this.
>>
>>> And then choose (1).
>>
>> Why that and not saturating arithmetic?
>
>Because nearly all hardware, many languages using machines types, even
>most C implementations by default, and all my own stuff, has wraparound
>behaviour.
Don't care about your stuff. It's not relevant.
The question was about what instruction a compiler emits for a
given operation. The point is that, in the face of UB, compiler
authors have greater lattitude here than they otherwise might if
the behavior was well-defined.
Consider ARM, which has the `QADD` instruction, that saturates.
Now consider, `int foo(int a) { return a + 1; }` compiled with a
compiler following the eabi. Since signed integer overflow is
UB, and in that environment `int` is 32-bits wide, the compiler
is perfectly free to implement this using `QADD`, so that
`foo(INT_MAX)` returns `INT_MAX`.
Your objection seems to be, basically, "why would anyone every
do that?" To which I answer, there could be any number of
reasons: perhaps they're targeting silicon where that's cheaper
than a normal `ADD`. Perhaps the compiler is doing whole-
program optimization, targeting a standalone environment, and
thus sees the entire call graph, and determines that `foo` is
always followed by a sequence that ensures saturating behavior,
so it's more efficient to elide that code and use `QADD`. I
don't know, but neither do you, and that's the point.
>Also, in C, matches the behaviour of unsigned arithmetic.
>
>It would be bizarre to go for something different /at this level of
>language/. At higher levels you can get more sophisticated, but you
>probably still wouldn't go for saturated.
See above.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-05 14:56 +0100 |
| Message-ID | <10tcsu4$e75o$2@dont-email.me> |
| In reply to | #398366 |
On 05/05/2026 14:02, Dan Cross wrote:
> In article <10tbh2v$3khv$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>> On 05/05/2026 01:48, Dan Cross wrote:
>>> In article <10tb2pv$3v9t1$2@dont-email.me>, Bart <bc@freeuk.com> wrote:
>>>> On 04/05/2026 22:14, Chris M. Thomasson wrote:
>>>>> On 5/3/2026 9:39 AM, Bart wrote:
>>>>> [...]
>>>>>
>>>>> A compiler vendor can take an UB and say, well, lets define it for fun,
>>>>> or whatever. It can say, if you do 1.0 / 0.0, we can make it 1.0 /
>>>>> 0.00000042 for shits and giggles. If you want pure std C, use this
>>>>> setting... If not, well, your UB will ride the train into the universe
>>>>> and beyond... ;^)
>>>>
>>>> I don't now about UB for floating point.
>>>>
>>>> For the one under discussion which is arithmetic between integers,
>>>> suppose there was a choice of just two compilers:
>>>>
>>>> (1) On overflow, it just loses the top significant bits of the result
>>>>
>>>> (2) On overflow, it will set your computer on fire and burn your house down
>>>>
>>>> There are no options to change that behaviour.
>>>
>>> This is silly and reductive.
>>>
>>> The point about saying that something is "UB" originally came
>>> from different machines doing things differently; C chose to
>>> kick that can down the road by simply declaring that the result
>>> was "undefined." "Nasal demons" were never anything more than a
>>> euphamism.
>>>
>>> The computing world is, in so many ways, simpler now than it was
>>> then: we've got 2's complement machines everywhere, bytes are
>>> pretty much uniformly sized at 8 bits, multi-byte values have
>>> power of two widths, and so on.
>>
>> That was happening at about the time I came in, around the late 70s,
>> after starting off on word-based mainframes. C however has taken decades
>> to adapt, and it still hasn't fully.
>
> Because, as I said, the incentives changed. They went from, "oh
> gee, all these machines are different; we can't possibly define
> what this means" to, "oh gee, we can use the undefined nature of
> $X to make code faster." They'd probably argue that they've
> adapted just fine; just not in the direction they wanted you to.
It took until C99 for types such as 'int64_t' to be standardised. Even
then, you can still write this:
typedef float int64_t;
int uint32_t;
Even if you manage to declare:
int64_t x;
you will have trouble printing x. I'd say it has adapted poorly, and slowly.
>> Because nearly all hardware, many languages using machines types, even
>> most C implementations by default, and all my own stuff, has wraparound
>> behaviour.
>
> Don't care about your stuff. It's not relevant.
OK, what about the other points?
> The question was about what instruction a compiler emits for a
> given operation. The point is that, in the face of UB, compiler
> authors have greater lattitude here than they otherwise might if
> the behavior was well-defined.
>
> Consider ARM, which has the `QADD` instruction, that saturates.
> Now consider, `int foo(int a) { return a + 1; }` compiled with a
> compiler following the eabi. Since signed integer overflow is
> UB, and in that environment `int` is 32-bits wide, the compiler
> is perfectly free to implement this using `QADD`, so that
> `foo(INT_MAX)` returns `INT_MAX`.
>
> Your objection seems to be, basically, "why would anyone every
> do that?" To which I answer, there could be any number of
> reasons: perhaps they're targeting silicon where that's cheaper
> than a normal `ADD`. Perhaps the compiler is doing whole-
> program optimization, targeting a standalone environment, and
> thus sees the entire call graph, and determines that `foo` is
> always followed by a sequence that ensures saturating behavior,
> so it's more efficient to elide that code and use `QADD`. I
> don't know, but neither do you, and that's the point.
Then implementation-defined was another option. That would allow saturation.
However, wraparound behaviour is still dominant; this is Fortran:
integer a
a = 2147483647
print *, a+1
It displays -2147483648. Java does the same. So does D. So does C#. So
does Go (when a starts from 9223372036854775807). Etc.
A few languages will do runtime checks and trap. Some higher level ones
will show 2147483647 or 9223372036854775808 as they are not constrained
by machine word sizes.
So to me this makes sense as a default behaviour that you can rely on,
without anyone needing to use special compiler options to create their
own dialect of C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-05 15:07 +0000 |
| Message-ID | <NInKR.903235$5GB4.850674@fx47.iad> |
| In reply to | #398371 |
Bart <bc@freeuk.com> writes: >On 05/05/2026 14:02, Dan Cross wrote: >> In article <10tbh2v$3khv$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >>> On 05/05/2026 01:48, Dan Cross wrote: >>>> In article <10tb2pv$3v9t1$2@dont-email.me>, Bart <bc@freeuk.com> wrote: >>>>> On 04/05/2026 22:14, Chris M. Thomasson wrote: >>>>>> On 5/3/2026 9:39 AM, Bart wrote: >>>>>> [...] >>>>>> >>>>>> A compiler vendor can take an UB and say, well, lets define it for fun, >>>>>> or whatever. It can say, if you do 1.0 / 0.0, we can make it 1.0 / >>>>>> 0.00000042 for shits and giggles. If you want pure std C, use this >>>>>> setting... If not, well, your UB will ride the train into the universe >>>>>> and beyond... ;^) >>>>> >>>>> I don't now about UB for floating point. >>>>> >>>>> For the one under discussion which is arithmetic between integers, >>>>> suppose there was a choice of just two compilers: >>>>> >>>>> (1) On overflow, it just loses the top significant bits of the result >>>>> >>>>> (2) On overflow, it will set your computer on fire and burn your house down >>>>> >>>>> There are no options to change that behaviour. >>>> >>>> This is silly and reductive. >>>> >>>> The point about saying that something is "UB" originally came >>>> from different machines doing things differently; C chose to >>>> kick that can down the road by simply declaring that the result >>>> was "undefined." "Nasal demons" were never anything more than a >>>> euphamism. >>>> >>>> The computing world is, in so many ways, simpler now than it was >>>> then: we've got 2's complement machines everywhere, bytes are >>>> pretty much uniformly sized at 8 bits, multi-byte values have >>>> power of two widths, and so on. >>> >>> That was happening at about the time I came in, around the late 70s, >>> after starting off on word-based mainframes. C however has taken decades >>> to adapt, and it still hasn't fully. >> >> Because, as I said, the incentives changed. They went from, "oh >> gee, all these machines are different; we can't possibly define >> what this means" to, "oh gee, we can use the undefined nature of >> $X to make code faster." They'd probably argue that they've >> adapted just fine; just not in the direction they wanted you to. > >It took until C99 for types such as 'int64_t' to be standardised. Even >then, you can still write this People were writing C code for a quarter century by then, and understood that each implementation defined a set of types that matched the available hardware characteristics. C didn't need to be standardized to be incredibly useful. Standarization led to portability.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-05 16:34 +0000 |
| Message-ID | <10td66f$cek$1@reader1.panix.com> |
| In reply to | #398371 |
In article <10tcsu4$e75o$2@dont-email.me>, Bart <bc@freeuk.com> wrote:
>On 05/05/2026 14:02, Dan Cross wrote:
>> In article <10tbh2v$3khv$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>>> On 05/05/2026 01:48, Dan Cross wrote:
>>>> In article <10tb2pv$3v9t1$2@dont-email.me>, Bart <bc@freeuk.com> wrote:
>>>>> On 04/05/2026 22:14, Chris M. Thomasson wrote:
>>>>>> On 5/3/2026 9:39 AM, Bart wrote:
>>>>>> [...]
>>>>>>
>>>>>> A compiler vendor can take an UB and say, well, lets define it for fun,
>>>>>> or whatever. It can say, if you do 1.0 / 0.0, we can make it 1.0 /
>>>>>> 0.00000042 for shits and giggles. If you want pure std C, use this
>>>>>> setting... If not, well, your UB will ride the train into the universe
>>>>>> and beyond... ;^)
>>>>>
>>>>> I don't now about UB for floating point.
>>>>>
>>>>> For the one under discussion which is arithmetic between integers,
>>>>> suppose there was a choice of just two compilers:
>>>>>
>>>>> (1) On overflow, it just loses the top significant bits of the result
>>>>>
>>>>> (2) On overflow, it will set your computer on fire and burn your house down
>>>>>
>>>>> There are no options to change that behaviour.
>>>>
>>>> This is silly and reductive.
>>>>
>>>> The point about saying that something is "UB" originally came
>>>> from different machines doing things differently; C chose to
>>>> kick that can down the road by simply declaring that the result
>>>> was "undefined." "Nasal demons" were never anything more than a
>>>> euphamism.
>>>>
>>>> The computing world is, in so many ways, simpler now than it was
>>>> then: we've got 2's complement machines everywhere, bytes are
>>>> pretty much uniformly sized at 8 bits, multi-byte values have
>>>> power of two widths, and so on.
>>>
>>> That was happening at about the time I came in, around the late 70s,
>>> after starting off on word-based mainframes. C however has taken decades
>>> to adapt, and it still hasn't fully.
>>
>> Because, as I said, the incentives changed. They went from, "oh
>> gee, all these machines are different; we can't possibly define
>> what this means" to, "oh gee, we can use the undefined nature of
>> $X to make code faster." They'd probably argue that they've
>> adapted just fine; just not in the direction they wanted you to.
>
>It took until C99 for types such as 'int64_t' to be standardised. Even
>then, you can still write this:
>
> typedef float int64_t;
> int uint32_t;
>
>Even if you manage to declare:
>
> int64_t x;
>
>you will have trouble printing x. I'd say it has adapted poorly, and slowly.
>
>>> Because nearly all hardware, many languages using machines types, even
>>> most C implementations by default, and all my own stuff, has wraparound
>>> behaviour.
>>
>> Don't care about your stuff. It's not relevant.
>
>OK, what about the other points?
>
>> The question was about what instruction a compiler emits for a
>> given operation. The point is that, in the face of UB, compiler
>> authors have greater lattitude here than they otherwise might if
>> the behavior was well-defined.
>>
>> Consider ARM, which has the `QADD` instruction, that saturates.
>> Now consider, `int foo(int a) { return a + 1; }` compiled with a
>> compiler following the eabi. Since signed integer overflow is
>> UB, and in that environment `int` is 32-bits wide, the compiler
>> is perfectly free to implement this using `QADD`, so that
>> `foo(INT_MAX)` returns `INT_MAX`.
>>
>> Your objection seems to be, basically, "why would anyone every
>> do that?" To which I answer, there could be any number of
>> reasons: perhaps they're targeting silicon where that's cheaper
>> than a normal `ADD`. Perhaps the compiler is doing whole-
>> program optimization, targeting a standalone environment, and
>> thus sees the entire call graph, and determines that `foo` is
>> always followed by a sequence that ensures saturating behavior,
>> so it's more efficient to elide that code and use `QADD`. I
>> don't know, but neither do you, and that's the point.
>
>Then implementation-defined was another option. That would allow saturation.
This has been covered in this newsgroup before, ad nauseum.
At the time of the initial C standard, there were machines that
were still 1's complement in relatively common use (Unisys had a
representative on the standards committee). Some other machines
trapped on overflow. Sometimes you couldn't tell what the
machine would do because it depended on the context that the
overflow happened in. In other words, there was no one common
definition as to what would happen across the set of machines
people cared about vis the origina standard; it was, if you
will, undefinable.
Bottom line, for better or worse, the decision was made to make
signed overflow UB.
By the time of the next standard revision, considerations around
those ancient machines _mostly_ didn't matter anymore, but by
then the die was cast, and the rest is history.
Are we all the poorer for it? Yes, I would argue that we are.
But your arguments to just "fix" the standard are simplistic and
lead me to question whether you actually understand the issues
well enough to have an informed opinion.
The more you post, the more evident it becomes that you have a
very strong sense about the "right" way to do things, and that
you are astonished that others do not share that opinion. What
you seem incapable of is appreciation for any sort of nuance
around these issues; your arguments utterly lack any suggestinon
of even an inkling of understanding the underlying motivation
behind _why_ things are the way they currently are.
And this is where things break down: it's not so much that
people _disagree_ with you per se about what the behavior
_should_ be, it's rather they've been trying to get you to
appreciate the context around why they are _not_ that way.
But you seem incapable of understanding, let alone appreciating,
that.
>However, wraparound behaviour is still dominant; this is Fortran:
>
> integer a
> a = 2147483647
> print *, a+1
Irrelevant. This is about C, not Fortran. Or any other language
that is not C.
>It displays -2147483648. Java does the same. So does D. So does C#. So
>does Go (when a starts from 9223372036854775807). Etc.
>
>A few languages will do runtime checks and trap. Some higher level ones
>will show 2147483647 or 9223372036854775808 as they are not constrained
>by machine word sizes.
I don't see how that's at all relevant. "Other languages do it
differently" is tautalogically true: other languages that are
not C are not C.
It seems that what you want is for C to specify signed integer
overflow, and specifically define it to use the wraparound
semantics of fixed width, 2's complement numbers. Ok, but C is
not currently specified to do that.
Furthermore, complaining about it in this newsgroup, where none
of the regular posters are members of the C standards committee
AFAIK, will not bring about your desired end state.
>So to me this makes sense as a default behaviour that you can rely on,
>without anyone needing to use special compiler options to create their
It may make sense to you, but I've seen no evidence that you
understand the matter particularly well. Indeed, I see quite a
bit of evidence for the opposite. Nevermind the larger context.
>own dialect of C.
That's precisely what large projects with long lifetimes do.
Consider Linux, which that idiot is always blathering on and on
about. It's kinda sorta written mostly in C, except that it
really isn't: it's written in "Linux C", which is the extended
subset of the language defined by their choice of supported
compiler(s), language extensions provided by those comilers,
compiler-specific options to define the semantics of specific
behaviors, and the ABI of the platforms they target.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-05 20:17 +0100 |
| Message-ID | <10tdfnn$lpil$1@dont-email.me> |
| In reply to | #398379 |
On 05/05/2026 17:34, Dan Cross wrote: > In article <10tcsu4$e75o$2@dont-email.me>, Bart <bc@freeuk.com> wrote: >> However, wraparound behaviour is still dominant; this is Fortran: >> >> integer a >> a = 2147483647 >> print *, a+1 > > Irrelevant. This is about C, not Fortran. Or any other language > that is not C. You're not getting my point. A number of other languages, somewhat higher level than C (including Fortran now), have more reliable behaviour when it comes to arithmetic between machine-oriented types. Yet C, the one more famous than any other for being 'close to the metal', is the one that you can't rely upon: this is UB, that is IB, this depends on your compiler and its options etc etc. > >> It displays -2147483648. Java does the same. So does D. So does C#. So >> does Go (when a starts from 9223372036854775807). Etc. >> >> A few languages will do runtime checks and trap. Some higher level ones >> will show 2147483647 or 9223372036854775808 as they are not constrained >> by machine word sizes. > > I don't see how that's at all relevant. "Other languages do it > differently" is tautalogically true: other languages that are > not C are not C. Is C higher level than them, or lower level? It seems to be getting above itself. C is also supposed to be famous for being as low level as you can get before you hit assembly. >> So to me this makes sense as a default behaviour that you can rely on, >> without anyone needing to use special compiler options to create their > > It may make sense to you, but I've seen no evidence that you > understand the matter particularly well. Indeed, I see quite a > bit of evidence for the opposite. Nevermind the larger context. I wrote my first compiler for a machine-oriented language in 1980. I've been developing a series of systems languages and their compilers since 1981. So that gives me an unusual perspective. Ideally, I wouldn't have anything to do with C (I had an opportunity to switch it to it in early 90s, but it didn't appeal and stuck with mine), but it's not possible to get away from it. Either most APIs of libraries I want to use are expressed in C, or sometimes I need to transpile to an existing lower-level HLL, and C is in the only practical choice. However its UBs and its numerous quirks are a big turn-off. I don't want an intermediate language that 'gets in the way', has a mind of its own, and is liable to give me unexpected surprises; just give me that fast code for that platform I can't yet support directly! So, yeah, you could say I have strong opinions about it. The end result is that I now avoid a C target as much as possible.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-05 21:08 +0000 |
| Message-ID | <10tdm8p$8q4$1@reader1.panix.com> |
| In reply to | #398386 |
In article <10tdfnn$lpil$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 05/05/2026 17:34, Dan Cross wrote: >> In article <10tcsu4$e75o$2@dont-email.me>, Bart <bc@freeuk.com> wrote: >>> However, wraparound behaviour is still dominant; this is Fortran: >>> >>> integer a >>> a = 2147483647 >>> print *, a+1 >> >> Irrelevant. This is about C, not Fortran. Or any other language >> that is not C. > >You're not getting my point. No, I get your point. What I'm saying is that your point is irrelevant, and you are not making a cogent argument for changing the language, because all evidence shows that you lack the requisite firm understanding of the language necessary to ground such an argument so that it is persuasive. >A number of other languages, somewhat >higher level than C (including Fortran now), have more reliable >behaviour when it comes to arithmetic between machine-oriented types. Ok. >Yet C, the one more famous than any other for being 'close to the >metal', is the one that you can't rely upon: this is UB, that is IB, >this depends on your compiler and its options etc etc. Yes. Welcome to the real world. >>> It displays -2147483648. Java does the same. So does D. So does C#. So >>> does Go (when a starts from 9223372036854775807). Etc. >>> >>> A few languages will do runtime checks and trap. Some higher level ones >>> will show 2147483647 or 9223372036854775808 as they are not constrained >>> by machine word sizes. >> >> I don't see how that's at all relevant. "Other languages do it >> differently" is tautalogically true: other languages that are >> not C are not C. > >Is C higher level than them, or lower level? It seems to be getting >above itself. C is also supposed to be famous for being as low level as >you can get before you hit assembly. C is not a low-level language: https://queue.acm.org/detail.cfm?id=3212479 C's evolution over time has seen it increasingly move away from a "low-level, close to the machine" language and to something that is a de-facto high-level language, just without all the nice features of languages that have been defined subsequently. This does not reflect well on C. Other than that, your question is not relevant, and is poorly worded: objective criteria by which one might say whether a language is "higher-level" or "lower-level" than "them" is vague at best. >>> So to me this makes sense as a default behaviour that you can rely on, >>> without anyone needing to use special compiler options to create their >> >> It may make sense to you, but I've seen no evidence that you >> understand the matter particularly well. Indeed, I see quite a >> bit of evidence for the opposite. Nevermind the larger context. > >I wrote my first compiler for a machine-oriented language in 1980. I've >been developing a series of systems languages and their compilers since >1981. Frankly, I don't care. Appeals to authority, or even worse, appeals to length of experience, do not work on me and usually have the opposite effect. >So that gives me an unusual perspective. Lots of people write toy compilers and design simple derivative langauges for fun; that does not make them experts. Outside of this news group, I've never heard of you, never heard of any of those languages, and never seen any of your compilers. I think it is fair to say that you have had no measurable impact on the field. So your perspective is no more "unusual", and certainly not more relevant, than any other relatively long-time programmer's. On the other hand, you've shown an inability to understand the topic at hand, which suggests that your perspective is probably _less_ relevant than that of other programmers. >Ideally, I wouldn't have anything to do with C (I had an opportunity to >switch it to it in early 90s, but it didn't appeal and stuck with mine), >but it's not possible to get away from it. > >Either most APIs of libraries I want to use are expressed in C, or >sometimes I need to transpile to an existing lower-level HLL, and C is >in the only practical choice. > >However its UBs and its numerous quirks are a big turn-off. I don't want >an intermediate language that 'gets in the way', has a mind of its own, >and is liable to give me unexpected surprises; just give me that fast >code for that platform I can't yet support directly! Case in point: If you, as a self-professed compiler implementer and language designer, cannot even negotiate understanding what the term, "Undefined Behavior" means in the context of C, then I do not think you are competent to build a professional-quality compiler or serious programming language. There are valid objections to the prevelance of UB in C, but this is not one of them. >So, yeah, you could say I have strong opinions about it. The end result >is that I now avoid a C target as much as possible. Ok. I don't think anyone other than you really cares about what you target with a toy compiler, and there is no reason why your opinion should be valued over anyone else's: rather the opposite in fact. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-05 23:30 +0100 |
| Message-ID | <10tdr18$p73j$1@dont-email.me> |
| In reply to | #398393 |
On 05/05/2026 22:08, Dan Cross wrote:
> In article <10tdfnn$lpil$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>> On 05/05/2026 17:34, Dan Cross wrote:
>> Is C higher level than them, or lower level? It seems to be getting
>> above itself. C is also supposed to be famous for being as low level as
>> you can get before you hit assembly.
>
> C is not a low-level language:
> https://queue.acm.org/detail.cfm?id=3212479
>
> C's evolution over time has seen it increasingly move away from
> a "low-level, close to the machine" language and to something
> that is a de-facto high-level language, just without all the
> nice features of languages that have been defined subsequently.
> This does not reflect well on C.
So which HLL is lower level than C now?
> Other than that, your question is not relevant, and is poorly
> worded: objective criteria by which one might say whether a
> language is "higher-level" or "lower-level" than "them" is vague
> at best.
>
>>>> So to me this makes sense as a default behaviour that you can rely on,
>>>> without anyone needing to use special compiler options to create their
>>>
>>> It may make sense to you, but I've seen no evidence that you
>>> understand the matter particularly well. Indeed, I see quite a
>>> bit of evidence for the opposite. Nevermind the larger context.
>>
>> I wrote my first compiler for a machine-oriented language in 1980. I've
>> been developing a series of systems languages and their compilers since
>> 1981.
>
> Frankly, I don't care. Appeals to authority, or even worse,
> appeals to length of experience, do not work on me and usually
> have the opposite effect.
>> So that gives me an unusual perspective.
>
> Lots of people write toy compilers and design simple derivative
> langauges for fun; that does not make them experts.
I've done it over decades and used them to write commercial
applications. The languages were in-house and now are personal ones. You
won't know of them unless you were a user of my applications.
As I said, I tried switching to C at one point, but decided it was
rubbish and persevered with mine.
> Outside of this news group, I've never heard of you, never heard
> of any of those languages, and never seen any of your compilers.
OK, I've never heard of you either.
And since we're being frank, I've seriously considered whether the C
language was a joke that couple of stoned students submitted as an
assignment. If it was, then nobody has let on yet.
> I think it is fair to say that you have had no measurable impact
> on the field.
OK. And it is fair to say that C remains a crappy language, no matter
how successful. Example:
int main() {
main(1, 2.0, "three", main, main());
}
int F(){}
These pass without comment. To get a compiler to complain, you have to
tell it how to do its job. Another:
int (*A)[10]; // pointer to array
int i;
(*A)[i]; // dereference pointer than index
OK so far, but suppose you get the last bit wrong:
*A[i]; // index then dereference
It ... still works (until it crashes). Another:
struct {int x, y;} p;
p.y;
Again fine. But now somebody defines this at module scope
#define y 123
This maps all instances of 'y' that follow to '123', not just top-level
names, but those that follow "." or "->" which are supposed to be
protected within their own name-space.
I could go on all day with more jaw-dropping stuff. Funnily enough, none
of this is possible in my systems language, you know, the amateur one
that is nowhere near as good as the 'professional' C language that
underpins most computer systems (how scary is that!).
> So your perspective is no more "unusual", and certainly not more
> relevant, than any other relatively long-time programmer's.
I disagree. Very few programmers devise their own languages, implement
them, and use them almost exclusively throughout the careers. And
probably even fewer who also designed and built their own hardware.
>> However its UBs and its numerous quirks are a big turn-off. I don't want
>> an intermediate language that 'gets in the way', has a mind of its own,
>> and is liable to give me unexpected surprises; just give me that fast
>> code for that platform I can't yet support directly!
>
> Case in point: If you, as a self-professed compiler implementer
> and language designer, cannot even negotiate understanding what
> the term, "Undefined Behavior" means in the context of C,
I simply don't agree with it in the context being discussed. It is an
unnecessary complication that I don't want to bother my head about.
> then I
> do not think you are competent to build a professional-quality
> compiler or serious programming language.
My language worked well enough for me to retire in 1999.
> There are valid objections to the prevelance of UB in C, but
> this is not one of them.
I think it is. I haven't had it in any of my languages since 1981; what
have I missed? (That is, UB for things that are well-defined in my
languages and their targets.)
>> So, yeah, you could say I have strong opinions about it. The end result
>> is that I now avoid a C target as much as possible.
>
> Ok. I don't think anyone other than you really cares about what
> you target with a toy compiler, and there is no reason why your
> opinion should be valued over anyone else's: rather the opposite
> in fact.
Well, OK. I didn't actually expect C to change right now because of a
thread on an obscure, dying forum.
That's fine, I will just continue avoiding C and enjoying my superior
product.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-05 23:06 +0000 |
| Message-ID | <10tdt61$65u$1@reader1.panix.com> |
| In reply to | #398397 |
In article <10tdr18$p73j$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 05/05/2026 22:08, Dan Cross wrote: >> In article <10tdfnn$lpil$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >>> On 05/05/2026 17:34, Dan Cross wrote: > >>> Is C higher level than them, or lower level? It seems to be getting >>> above itself. C is also supposed to be famous for being as low level as >>> you can get before you hit assembly. >> >> C is not a low-level language: >> https://queue.acm.org/detail.cfm?id=3212479 >> >> C's evolution over time has seen it increasingly move away from >> a "low-level, close to the machine" language and to something >> that is a de-facto high-level language, just without all the >> nice features of languages that have been defined subsequently. >> This does not reflect well on C. > >So which HLL is lower level than C now? Did you not read the following paragraph, that you also quoted? >> Other than that, your question is not relevant, and is poorly >> worded: objective criteria by which one might say whether a >> language is "higher-level" or "lower-level" than "them" is vague >> at best. ^^^ See here. >>>>> So to me this makes sense as a default behaviour that you can rely on, >>>>> without anyone needing to use special compiler options to create their >>>> >>>> It may make sense to you, but I've seen no evidence that you >>>> understand the matter particularly well. Indeed, I see quite a >>>> bit of evidence for the opposite. Nevermind the larger context. >>> >>> I wrote my first compiler for a machine-oriented language in 1980. I've >>> been developing a series of systems languages and their compilers since >>> 1981. >> >> Frankly, I don't care. Appeals to authority, or even worse, >> appeals to length of experience, do not work on me and usually >> have the opposite effect. > > >>> So that gives me an unusual perspective. >> >> Lots of people write toy compilers and design simple derivative >> langauges for fun; that does not make them experts. > >I've done it over decades and used them to write commercial >applications. The languages were in-house and now are personal ones. You >won't know of them unless you were a user of my applications. Ah, so in other words, you wrote a compiler for a language that you used to write applications that you then sold, all by yourself. Congratulations on being able to earn a living that way, and I mean that sincerely. But that in no way makes you an expert on programming languages or compiler design.. >As I said, I tried switching to C at one point, but decided it was >rubbish and persevered with mine. That's cute, but given that you're not an expert, you're not really in a position to judge. >> Outside of this news group, I've never heard of you, never heard >> of any of those languages, and never seen any of your compilers. > >OK, I've never heard of you either. The vast majority of people in this world have not, either. >And since we're being frank, I've seriously considered whether the C >language was a joke that couple of stoned students submitted as an >assignment. If it was, then nobody has let on yet. Then you've admitted that your opinion is not at all valuable, as you clearly don't know anything about the history of the language, or the people involved, or their qualifications, as demonstrated by their track records and the publicly inspectible artifacts that they produced. So why, again, should anyone care what you have to say about the matter? >> I think it is fair to say that you have had no measurable impact >> on the field. > >OK. And it is fair to say that C remains a crappy language, no matter >how successful. Did I say it was a great language? Why are you trying to convince me? >Example: > >[tl;dr: bad code that demonstrates lack of understanding] > >I could go on all day with more jaw-dropping stuff. Funnily enough, none >of this is possible in my systems language, you know, the amateur one >that is nowhere near as good as the 'professional' C language that >underpins most computer systems (how scary is that!). That's nice. Too bad no one other than you has ever heard of your "systems language". >> So your perspective is no more "unusual", and certainly not more >> relevant, than any other relatively long-time programmer's. > >I disagree. I'm sure you do disagree. That doesn't really change reality, though. Your demonstrated lack of understanding of even the most basic aspects of the topics at hand show that your opinion is not worth consideration. >Very few programmers devise their own languages, implement >them, Actually, lots do. >and use them almost exclusively throughout the careers. This is true, but it is not the flex that you think that it is. Hint: most programmers grow up and come to their senses. >And >probably even fewer who also designed and built their own hardware. LOL. Ok. >>> However its UBs and its numerous quirks are a big turn-off. I don't want >>> an intermediate language that 'gets in the way', has a mind of its own, >>> and is liable to give me unexpected surprises; just give me that fast >>> code for that platform I can't yet support directly! >> >> Case in point: If you, as a self-professed compiler implementer >> and language designer, cannot even negotiate understanding what >> the term, "Undefined Behavior" means in the context of C, > >I simply don't agree with it in the context being discussed. It is an >unnecessary complication that I don't want to bother my head about. See the previous point. >> then I >> do not think you are competent to build a professional-quality >> compiler or serious programming language. > >My language worked well enough for me to retire in 1999. ...and? >> There are valid objections to the prevelance of UB in C, but >> this is not one of them. > >I think it is. I haven't had it in any of my languages since 1981; what >have I missed? (That is, UB for things that are well-defined in my >languages and their targets.) You don't even have a good handle on what UB _is_. Maybe you should work on that before commenting about what you "think". >>> So, yeah, you could say I have strong opinions about it. The end result >>> is that I now avoid a C target as much as possible. >> >> Ok. I don't think anyone other than you really cares about what >> you target with a toy compiler, and there is no reason why your >> opinion should be valued over anyone else's: rather the opposite >> in fact. > >Well, OK. I didn't actually expect C to change right now because of a >thread on an obscure, dying forum. > >That's fine, I will just continue avoiding C and enjoying my superior >product. Great. Enjoy. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-06 02:23 +0100 |
| Message-ID | <10te56b$rpfu$1@dont-email.me> |
| In reply to | #398399 |
On 06/05/2026 00:06, Dan Cross wrote: > In article <10tdr18$p73j$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >> On 05/05/2026 22:08, Dan Cross wrote: > Ah, so in other words, you wrote a compiler for a language that > you used to write applications that you then sold, all by > yourself. My company did to start with then I took that over. > Congratulations on being able to earn a living that way, and I > mean that sincerely. But that in no way makes you an expert on > programming languages or compiler design.. I know what is useful in lower-level languages and what is easy and worthwhile to implement, and what is hard, or out of place at this level. The last few years I've worked on various projects trying out ideas involving compilers, assemblers, linkers, interpreters and emulators. I know this area very well, all my products are small, self-contained executables that are highly performant. One of them is even a C compiler. >> As I said, I tried switching to C at one point, but decided it was >> rubbish and persevered with mine. > > That's cute, but given that you're not an expert, you're not > really in a position to judge. An expert in what? This was my subjective opinion; I simply didn't like the language and disliked the syntax immensely. I could be far more productive with my product, and that was a choice I made, even though I would have to spend time creating new compilers for each platform switch. > >>> Outside of this news group, I've never heard of you, never heard >>> of any of those languages, and never seen any of your compilers. >> >> OK, I've never heard of you either. > > The vast majority of people in this world have not, either. You might notice I try to not get personal, not insult people, and not question their credentials. I haven't said, for example, that your opinions are worthless because you are not a language designer or implementor (you might well be, but I don't care). >> And since we're being frank, I've seriously considered whether the C >> language was a joke that couple of stoned students submitted as an >> assignment. If it was, then nobody has let on yet. > > Then you've admitted that your opinion is not at all valuable, > as you clearly don't know anything about the history of the > language, or the people involved, or their qualifications, as > demonstrated by their track records and the publicly inspectible > artifacts that they produced. I know about the history of the language. Let's say then that the language /looks/ like it was created by a couple of drunken students. (I mean, was there a shortage of keywords in 1972 that they had to use 'break' for two different things?) > So why, again, should anyone care what you have to say about the > matter? So who do you think should be allowed to discuss language design? Academics with PhDs in PLT? Or just you lot? As I said, I've created practical languages for practical use and done so, in hindsight, incredibly successfully. >>> I think it is fair to say that you have had no measurable impact >>> on the field. >> >> OK. And it is fair to say that C remains a crappy language, no matter >> how successful. > > Did I say it was a great language? Why are you trying to > convince me? > >> Example: >> >> [tl;dr: bad code that demonstrates lack of understanding] Appalling code which the language, unbelievably, allows, and where you have to twist the compilers aim to get it to fail it, which is not always possible. BTW I understand exactly what's going on. I did implement C at one time. >> I could go on all day with more jaw-dropping stuff. Funnily enough, none >> of this is possible in my systems language, you know, the amateur one >> that is nowhere near as good as the 'professional' C language that >> underpins most computer systems (how scary is that!). > > That's nice. Too bad no one other than you has ever heard of > your "systems language". Yes, it is. But I would much have prefered that someone else had created one that I found usable. >>> So your perspective is no more "unusual", and certainly not more >>> relevant, than any other relatively long-time programmer's. >> >> I disagree. > > I'm sure you do disagree. That doesn't really change reality, > though. Your demonstrated lack of understanding of even the > most basic aspects of the topics at hand show that your opinion > is not worth consideration. You do understand that making a language simple and easy to understand and explain is part of the process? >> probably even fewer who also designed and built their own hardware. > > LOL. Ok. Why is that funny? That's exactly what I did, as it was my job. >>> then I >>> do not think you are competent to build a professional-quality >>> compiler or serious programming language. >> >> My language worked well enough for me to retire in 1999. > > ...and? Let me put it another way; what difference would it have been if I'd written my stuff in C and used a 'professional' compiler? Other than it would have taken longer, been more frustrating, and may have given up. This is not building a rocket to the moon; making custom tools (which was all it was and what programmers do) can be done by an individual and at any scale.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-06 12:37 +0000 |
| Message-ID | <10tfclh$7vb$1@reader1.panix.com> |
| In reply to | #398403 |
In article <10te56b$rpfu$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 06/05/2026 00:06, Dan Cross wrote: >> [snip] >> Congratulations on being able to earn a living that way, and I >> mean that sincerely. But that in no way makes you an expert on >> programming languages or compiler design.. > >I know what is useful in lower-level languages and what is easy and >worthwhile to implement, and what is hard, or out of place at this level. I am sure you believe that. Your public statements are evidence of the opposite. >The last few years I've worked on various projects trying out ideas >involving compilers, assemblers, linkers, interpreters and emulators. Ok. >I know this area very well, all my products are small, self-contained >executables that are highly performant. One of them is even a C compiler. So...you've never worked on a project of appreciable size. Ok. >>> As I said, I tried switching to C at one point, but decided it was >>> rubbish and persevered with mine. >> >> That's cute, but given that you're not an expert, you're not >> really in a position to judge. > >An expert in what? Programming languages, compilers, etc. >This was my subjective opinion; I simply didn't like >the language and disliked the syntax immensely. Ok. >I could be far more >productive with my product, and that was a choice I made, even though I >would have to spend time creating new compilers for each platform switch. Ok. >>>> Outside of this news group, I've never heard of you, never heard >>>> of any of those languages, and never seen any of your compilers. >>> >>> OK, I've never heard of you either. >> >> The vast majority of people in this world have not, either. > >You might notice I try to not get personal, not insult people, and not >question their credentials. I haven't said, for example, that your >opinions are worthless because you are not a language designer or >implementor (you might well be, but I don't care). And yet, you point to your self-professed long history of working on languages, compilers, assemblers, and so on, to support your assertions about how C (as just one example) should be and why it is bad. In doing so, you claim a level of authority that suggests that others should listen to you. This is an example of the "appeal to authority" logical fallacy. In this case, you are purporting that you, yourself, are the authority figure. But, the substance of what you say suggests the opposite: you do not actually seem to have a good handle on the subtleties of e.g. C, and there's no evidence available to support your claims to expertise. Therefore, there's no reason to take your statements about C particularly seriously. There's certainly no reason to believe that you are more of an expert than any other random programmer. >>> And since we're being frank, I've seriously considered whether the C >>> language was a joke that couple of stoned students submitted as an >>> assignment. If it was, then nobody has let on yet. >> >> Then you've admitted that your opinion is not at all valuable, >> as you clearly don't know anything about the history of the >> language, or the people involved, or their qualifications, as >> demonstrated by their track records and the publicly inspectible >> artifacts that they produced. > >I know about the history of the language. Let's say then that the >language /looks/ like it was created by a couple of drunken students. (I >mean, was there a shortage of keywords in 1972 that they had to use >'break' for two different things?) You've already ruined your own credibility, so your quip about drunk students just adds to that. Your indignation that `break` is used in two different contexts really doesn't show anything; it is purely a statement of opinion. But again, why should I take your opinion any more seriously than anyone else's? Lots of people didn't (and still do not) like curly braces, preventing "begin" and "end". That's fine; people are entitled to their opinions, but absent any sort of compelling supporting evidence (e.g., a rigorous study showing increased defect rates due to curly braces or something) that cannot really be considered a serious criticism of the langauge. >> So why, again, should anyone care what you have to say about the >> matter? > >So who do you think should be allowed to discuss language design? >Academics with PhDs in PLT? Or just you lot? Again, a logical fallacy. The statement was that you are not qualified to have an opinion that should be considered seriously when it comes to C (or any other programming language). Despite your self-professed expertise, there is no evidence suggesting you have any special position to argue from, and indeed, there is evidence demonstrating that your opinion should is ill informed, at best. That does not say anything about group, the members of which's opinions should be elevated above others. >As I said, I've created practical languages for practical use and done >so, in hindsight, incredibly successfully. So you say. But earlier you suggested that your definition of "successfully" was measured by your being able to retire in 1999 (one presumes thanks in large part to these languages). Are you sure you want to go by that metric, though? Because when compared to the total number of people who used C to write software that enabled _then_ to retire early and your language does not fare particularly well. >>>> I think it is fair to say that you have had no measurable impact >>>> on the field. >>> >>> OK. And it is fair to say that C remains a crappy language, no matter >>> how successful. >> >> Did I say it was a great language? Why are you trying to >> convince me? >> >>> Example: >>> >>> [tl;dr: bad code that demonstrates lack of understanding] > >Appalling code which the language, unbelievably, allows, and where you >have to twist the compilers aim to get it to fail it, which is not >always possible. "OMG...programming language lets programmer write bad software. City on fire; film at 11."" >BTW I understand exactly what's going on. All available evidence suggests otherwise. >I did implement C at one time. Given that you don't seem to know how C is defined, I find it probable that you implemented your conception of C; whether it was actually C or not is a separate matter. >>> I could go on all day with more jaw-dropping stuff. Funnily enough, none >>> of this is possible in my systems language, you know, the amateur one >>> that is nowhere near as good as the 'professional' C language that >>> underpins most computer systems (how scary is that!). >> >> That's nice. Too bad no one other than you has ever heard of >> your "systems language". > >Yes, it is. But I would much have prefered that someone else had created >one that I found usable. Non sequitur. 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. >>>> So your perspective is no more "unusual", and certainly not more >>>> relevant, than any other relatively long-time programmer's. >>> >>> I disagree. >> >> I'm sure you do disagree. That doesn't really change reality, >> though. Your demonstrated lack of understanding of even the >> most basic aspects of the topics at hand show that your opinion >> is not worth consideration. > >You do understand that making a language simple and easy to understand >and explain is part of the process? a) There is no evidence that you actually did that successfully, other than your own assertions. b) Even if you did, it is irrelevant. The topic at hand is C, and your repeated statements show that do not understand even the most fundamental phrases in the C language standard; your "understanding" of C seems to be based almost entirely on subjective opinion and misconceptions about C's design, history, and specification. Thus, your opinion about C is undeserving of consideration. >>> probably even fewer who also designed and built their own hardware. >> >> LOL. Ok. > >Why is that funny? That's exactly what I did, as it was my job. Because "designed and built their own hardware" is a) something that lots of people do, and b) varies incredibly. There's a big difference between blinking an LED, building an simple board with a few sensors and an embedded microcontroller, and building a full-on server-scale machine or end-user device. You didn't specify which (nor do I care). It's also utterly irrelevant to programming languages, unless one is discussing HDLs, but this is comp.lang.c, not comp.lang.vhdl or a forum devoted to System Verilog, Bluespec Classic, Chisel, etc. So yes: "I built my own hardware!" as a claim of deep expertise in programming languages strikes me as desparate, and laughable. >>>> then I >>>> do not think you are competent to build a professional-quality >>>> compiler or serious programming language. >>> >>> My language worked well enough for me to retire in 1999. >> >> ...and? > >Let me put it another way; what difference would it have been if I'd >written my stuff in C and used a 'professional' compiler? Probably other people elsewhere in the world would be able to maintain it. But I suspect it's not really important enough for that. >Other than it would have taken longer, been more frustrating, and may >have given up. That says more about you than it does about C. >This is not building a rocket to the moon; making custom tools (which >was all it was and what programmers do) can be done by an individual and >at any scale. Fine. But that really doesn't qualify you to have an opinion on a language you evidently do not understand. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-06 16:09 +0100 |
| Message-ID | <10tflij$19d6u$1@dont-email.me> |
| In reply to | #398416 |
On 06/05/2026 13:37, Dan Cross wrote:
> In article <10te56b$rpfu$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>> You might notice I try to not get personal, not insult people, and not
>> question their credentials. I haven't said, for example, that your
>> opinions are worthless because you are not a language designer or
>> implementor (you might well be, but I don't care).
>
> And yet, you point to your self-professed long history of
> working on languages, compilers, assemblers, and so on, to
> support your assertions about how C (as just one example) should
> be and why it is bad. In doing so, you claim a level of
> authority that suggests that others should listen to you. This
> is an example of the "appeal to authority" logical fallacy.
So what's /your/ level of authority?
Why is it that /you/ get to trash me, my work and my experience, and get
to decide that /my/ opinions are worthless, while I have to take yours
at face value?
Everything I say about my experience or my work, you are intent on
trivialising and dismissing:
"So you've never worked on a project of any size"
You just HAD to find something negative about it! Small, compact
programs are usually more desirable.
According to you, I'm not even allowed to choose between language A and
B: "that's cute, but given that you're not an expert, you're not really
in a position to judge."
> In this case, you are purporting that you, yourself, are the
> authority figure.
So 47 years of being involved in implementing lower-level languages
counts for absolutely nothing. But then, I first come across C in 1982
and disliked it then; I didn't need 45 extra years of experience to
confirm it!
> But, the substance of what you say suggests
> the opposite: you do not actually seem to have a good handle on
> the subtleties of e.g. C, and there's no evidence available to
> support your claims to expertise.
I'm not an expert on the details of C, no, not like the
'standards-heads' here who like nothing better than to discuss its
minutiae ad nauseam.
I don't have the patience for it; C is just a means to an end when it
comes up, and then, yes, I have opinions on how it ought to be, and like
to cut through the crap.
> Therefore, there's no reason to take your statements about C
> particularly seriously. There's certainly no reason to believe
> that you are more of an expert than any other random programmer.
I can say exactly the same about you.
> You've already ruined your own credibility, so your quip about
> drunk students just adds to that.
I bet I'm not the only one who's thought it.
> Your indignation that `break` is used in two different contexts
> really doesn't show anything; it is purely a statement of
> opinion.
Different contexts that can overlap.
> But again, why should I take your opinion any more
> seriously than anyone else's? Lots of people didn't (and still
> do not) like curly braces, preventing "begin" and "end". That's
> fine; people are entitled to their opinions, but absent any sort
> of compelling supporting evidence (e.g., a rigorous study
> showing increased defect rates due to curly braces or something)
> that cannot really be considered a serious criticism of the
> langauge
C's use of curly braces do have a number of problems:
if (c)
x;
y;
if (c1)
x;
if (c2);
y;
else
z;
What's happened with C is that a thousand times as much effort has gone
into compilers that try to detect and mitigate all its issues, as would
have taken to just fix the language in the first place.
> Again, a logical fallacy. The statement was that you are not
> qualified to have an opinion that should be considered seriously
> when it comes to C (or any other programming language). Despite
> your self-professed expertise, there is no evidence suggesting
> you have any special position to argue from, and indeed, there
> is evidence demonstrating that your opinion should is ill
> informed, at best.
Which opinion of mine are you disagreeing with?
> So you say. But earlier you suggested that your definition of
> "successfully" was measured by your being able to retire in
> 1999 (one presumes thanks in large part to these languages).
>
> Are you sure you want to go by that metric, though? Because
> when compared to the total number of people who used C to write
> software that enabled _then_ to retire early and your language
> does not fare particularly well.
Those people did not invent their own languages and implementations. The
point was brought up because you were dismissing my efforts as worthless
toys.
People invent custom DSLs all the time; those must all be toys too
because you haven't heard of them!
>> Appalling code which the language, unbelievably, allows, and where you
>> have to twist the compilers aim to get it to fail it, which is not
>> always possible.
>
> "OMG...programming language lets programmer write bad software.
> City on fire; film at 11.""
Those examples are in a class of their own, and are utterly crass.
They should be impossible to write in any HLL.
>> BTW I understand exactly what's going on.
>
> All available evidence suggests otherwise.
>
>> I did implement C at one time.
>
> Given that you don't seem to know how C is defined, I find it
> probable that you implemented your conception of C; whether it
> was actually C or not is a separate matter.
It is a non-conforming C subset somewhere between C90 and C99. It can
just about run SQLite:
c:\cx>bcc -r sql
Compiling sql.c to sql.(run)
SQLite version 3.25.3/MCC 2018-11-05 20:37:38
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite>
c:\cx>bcc -i sql
Compiling sql.c to sql.(int)
SQLite version 3.25.3/MCC 2018-11-05 20:37:38
...
The -r invocation runs it in-memeory as native code (compile time is
0.25s); The -i one interprets the IL (compile time is 0.15s).
> 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.
You don't need evidence, since it is clear enough!
While my 2026 language is old-fashioned compared with modern languages,
it runs rings around C. Here are some highlights:
- Case-insensitive
- Non-brace syntax
- Expression-based
- N-based, defaults to 1-based
- 64-bit default types
- Module scheme including circular references
- Namespaces
- Can import or export functions, variables, named constants,
enumerations, records, types and macros
- Entities need only their definitions; no separate declarations are
necessary
- Out-of-order definitions allowed throughout
- Functions have pass-by-reference, keyword arguments and default values
- Whole-program compilation
- Single-file, self-contained compiler, fast enough to run direct from
source (see example above)
>> You do understand that making a language simple and easy to understand
>> and explain is part of the process?
>
> a) There is no evidence that you actually did that successfully,
> other than your own assertions.
I have a feeling that no amount of 'evidence' will convince you. Or that
even if it did, it wouldn't cut any ice.
You are determined to belittle any of my achievements.
>
> b) Even if you did, it is irrelevant. The topic at hand is C,
> and your repeated statements show that do not understand even
> the most fundamental phrases in the C language standard; your
> "understanding" of C seems to be based almost entirely on
> subjective opinion and misconceptions about C's design,
> history, and specification.
>
> Thus, your opinion about C is undeserving of consideration.
EVERY user of C is entitled to their opinion. They don't need to be an
expert in languages or compilers either.
>>>> probably even fewer who also designed and built their own hardware.
>>>
>>> LOL. Ok.
>>
>> Why is that funny? That's exactly what I did, as it was my job.
>
> Because "designed and built their own hardware" is a) something
> that lots of people do, and b) varies incredibly. There's a big
> difference between blinking an LED, building an simple board
> with a few sensors and an embedded microcontroller, and building
> a full-on server-scale machine or end-user device. You didn't
> specify which (nor do I care).
You are determined not to care aren't you?!
In fact, there is NO amount of experience I can offer that will make
your repect my entitlement to my opinions.
However lots of people do believe that working directly on hardware
gives you valuable insights.
> It's also utterly irrelevant to programming languages,
It is 100% relevant since PLs have to be implemented on real hardware.
> So yes: "I built my own hardware!" as a claim of deep expertise
> in programming languages strikes me as desparate, and laughable.
I don't think it's me who's desperate.
Yes, I HAD to make my own computer at one point because I had no job and
little money, but wanted to program.
Well, I built it, but there was zero software, which I had to create
from scratch, which meant coding in actual binary. I wrote a hex editor
in binary, then used that to write an assembler, and used that to write
my first, crude HLL. Then used that to control graphics circuitry I'd
also built.
That HLL evolved to what I have now, and I'm very proud of it.
The experience also landed me a job in a small computer company.
> Fine. But that really doesn't qualify you to have an opinion on
> a language you evidently do not understand.
So who /is/ entitled to an opinion on C?
What exactly does have anyone have to do in order for their opinion to
be respected? I mean, few C users read the C standard cover to cover.
And why doesn't any of that apply to you?
BTW are you a user or an implementer?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-06 15:21 +0000 |
| Message-ID | <W%IKR.940668$5GB4.662441@fx47.iad> |
| In reply to | #398418 |
Bart <bc@freeuk.com> writes: >On 06/05/2026 13:37, Dan Cross wrote: >> You've already ruined your own credibility, so your quip about >> drunk students just adds to that. > >I bet I'm not the only one who's thought it. I'll take that bet. You don't like C. Fine. Why are you here, then?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-06 18:02 +0100 |
| Message-ID | <10tfs70$1b808$1@dont-email.me> |
| In reply to | #398419 |
On 06/05/2026 16:21, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 06/05/2026 13:37, Dan Cross wrote: > >>> You've already ruined your own credibility, so your quip about >>> drunk students just adds to that. >> >> I bet I'm not the only one who's thought it. > > I'll take that bet. OK. But how do we know who's right? It mean, it is so open: you're claiming that nobody on the planet since 1972 ever thought that C looked it was devised by someone who was drunk or stoned, and I'm saying at least one person thought so. There is certainly a considerable amount of criticism about. > > You don't like C. Fine. Why are you here, then? In this thread? My first post was 2-May-26 14:18 (GMT+1), in reply to wij, and it snowballed from that. If you mean in the newsgroup, then I'm still involved in this world.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-06 19:35 +0000 |
| Message-ID | <10tg55j$kvp$1@reader1.panix.com> |
| In reply to | #398418 |
In article <10tflij$19d6u$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 06/05/2026 13:37, Dan Cross wrote: >> In article <10te56b$rpfu$1@dont-email.me>, Bart <bc@freeuk.com> wrote: > >>> You might notice I try to not get personal, not insult people, and not >>> question their credentials. I haven't said, for example, that your >>> opinions are worthless because you are not a language designer or >>> implementor (you might well be, but I don't care). >> >> And yet, you point to your self-professed long history of >> working on languages, compilers, assemblers, and so on, to >> support your assertions about how C (as just one example) should >> be and why it is bad. In doing so, you claim a level of >> authority that suggests that others should listen to you. This >> is an example of the "appeal to authority" logical fallacy. > >So what's /your/ level of authority? I'm not claiming any special authority in this regard. Again, you show a logical fallacy; just because I point out that you have no authority from which to speak of compilers and programming languages does not imply that I do. >Why is it that /you/ get to trash me, my work and my experience, and get >to decide that /my/ opinions are worthless, while I have to take yours >at face value? You don't have to take my opinions at any value. You are free to ignore me completely, if you like. I'll be honest: I'm am neither a compiler nor a PL person. However, I am capable of reading the C standard and getting a reasonable understanding of what it says. Vis UB you've shown you are unable to do that. Therefore, your opinion on UB is uninformed, and thus not worth significant consideration. That is all. >Everything I say about my experience or my work, you are intent on >trivialising and dismissing: I sincerely congratulated you being able to retire in 1999. Good on ya! >"So you've never worked on a project of any size" > >You just HAD to find something negative about it! Small, compact >programs are usually more desirable. Indeed. However, not all programs _can_ be small, compact, beautiful works of art. You don't appear to have any experience with those sorts of programs. >According to you, I'm not even allowed to choose between language A and >B: "that's cute, but given that you're not an expert, you're not really >in a position to judge." You can choose whatever you like. Some people like neon orange for home decorations. That does not mean that those people are experts on interior decorating. >> In this case, you are purporting that you, yourself, are the >> authority figure. > >So 47 years of being involved in implementing lower-level languages >counts for absolutely nothing. What they count for is an expression of minimal competency as a programmer, but nothing more, no. Just doing something for a long time doesn't qualify you as an expert in that thing. I've been shooting baskets most of my life, but I'll never be a point guard in the NBA. I'm cool with that. Much more meaningful are the actual artifacts you've produced as examples of expertise. You haven't produced that much, and your writing and statements betray a deep lack of understanding of the object of your criticism, in this case the C programming language. Put another way, there's no evidence to back up your claim that those years count for much at all. I am forced to conclude that you don't actually have much in the way of true expertise in the domain. >But then, I first come across C in 1982 >and disliked it then; I didn't need 45 extra years of experience to >confirm it! C now is not C from 1982. Void pointers hadn't even been invented then. Function prototypes weren't a thing yet. This statement amounts to you saying that you have ignored the last 44 years of development in that language because of an impression you formed when it was very different. So why should anyone care about that opinion, again? >> But, the substance of what you say suggests >> the opposite: you do not actually seem to have a good handle on >> the subtleties of e.g. C, and there's no evidence available to >> support your claims to expertise. > >I'm not an expert on the details of C, no, Finally! You admit it! Progress! >not like the >'standards-heads' here who like nothing better than to discuss its >minutiae ad nauseam. > >I don't have the patience for it; C is just a means to an end when it >comes up, and then, yes, I have opinions on how it ought to be, and like >to cut through the crap. So in other words, you have no especial expertise in the matter. I had a drill instructor in Marine Corps boot camp once who said rather colorfully, "excuses are like assholes; everybody's got one." Opinions are like that, too. >> Therefore, there's no reason to take your statements about C >> particularly seriously. There's certainly no reason to believe >> that you are more of an expert than any other random programmer. > >I can say exactly the same about you. > >> You've already ruined your own credibility, so your quip about >> drunk students just adds to that. > >I bet I'm not the only one who's thought it. Maybe not. But so what? A non-trivial number of people in the world think that the earth is flat. Are their opinions worth consideration? >> Your indignation that `break` is used in two different contexts >> really doesn't show anything; it is purely a statement of >> opinion. > >Different contexts that can overlap. Yes, yes? (See above.) >> But again, why should I take your opinion any more >> seriously than anyone else's? Lots of people didn't (and still >> do not) like curly braces, preventing "begin" and "end". That's >> fine; people are entitled to their opinions, but absent any sort >> of compelling supporting evidence (e.g., a rigorous study >> showing increased defect rates due to curly braces or something) >> that cannot really be considered a serious criticism of the >> langauge > >C's use of curly braces do have a number of problems: > > if (c) > x; > y; > > if (c1) > x; > if (c2); > y; > else > z; > >What's happened with C is that a thousand times as much effort has gone >into compilers that try to detect and mitigate all its issues, as would >have taken to just fix the language in the first place. This is exactly the sort of ill-informed argument that I'm talking about. Note that there is not a single curly brace in the example above. The statement I suspect you are _trying_ to make is that the grammar of the language matches code that a human might see as ambiguous, particularly if formatted in a misleading way. In particular, the `secondary-block` production allows the braces to be elided in a way that is _usually_ grammatically correct, but may not be what the programmer intended. Two things on that. First, Pascal uses, `begin` and `end` to delimit block, but those are often _also_ optional in a similar way, and arguably it suffers from the same problem. Second, consider both Go and Rust, which use matched braces as delimiters, but make them required (and provide pretty-printers to format code readably, so that the structure is evident). Neither suffers from the ambiguity problems of the above snippet despite using curly braces. I conclude that the actual tokens used to delimit block structure are purely incidental. Thus, you blaming this on the tokens suggests you do not understand the issue very well yourself: any argument you may have been trying to make is phrased so poorly that whatever point you had is obscured. >> Again, a logical fallacy. The statement was that you are not >> qualified to have an opinion that should be considered seriously >> when it comes to C (or any other programming language). Despite >> your self-professed expertise, there is no evidence suggesting >> you have any special position to argue from, and indeed, there >> is evidence demonstrating that your opinion should is ill >> informed, at best. > >Which opinion of mine are you disagreeing with? Well, that curly braces are a problem with the language, for one. See the previous example. >> So you say. But earlier you suggested that your definition of >> "successfully" was measured by your being able to retire in >> 1999 (one presumes thanks in large part to these languages). >> >> Are you sure you want to go by that metric, though? Because >> when compared to the total number of people who used C to write >> software that enabled _then_ to retire early and your language >> does not fare particularly well. > >Those people did not invent their own languages and implementations. Perhaps they did not; at least as far as you are aware of. But so what? How is that relevant? Your statement was that your language was "successful" because you were able to use it throughout your career and then retire in 1999 (one assumes that must be early, otherwise that detail wouldn't be worth mentioning). Ok. But by that metric, C is even _more_ successful because hundreds of thousands, if not millions, of people of people were able to use it throughout their entire careers, and tens or hundreds of thousands of them were able to retire relatively early. So if that's the metric you want to use, your language doesn't look that great in comparison. >The >point was brought up because you were dismissing my efforts as worthless >toys. Yes. What I suspect happened is that you stumbled onto a niche that is vanishingly small, with few or no other players, so you were able to dictate your own technology terms, but that paid well enough for you to support yourself and put away enough extra that you could retire relatively young. Good for you; few people are that fortunate. But that does not make you an expert in C, or qualify your opinions above those of others, and your public statements show a lack of understanding of the language itself. Furthermore, when people who _do_ demonstrate expertise in the language correct your misconceptions, you seem incapable of absorbing the corrections, preferring to argue itself. That in itself is enough to disqualify your opinion as one worthy of regard. >People invent custom DSLs all the time; those must all be toys too >because you haven't heard of them! I am sure that some of them are. I am also inclined to believe that, for most that are not, the creators don't feel the need to thump their chests about how they're now qualified to opine on things that they manifestly do not understand. >>> Appalling code which the language, unbelievably, allows, and where you >>> have to twist the compilers aim to get it to fail it, which is not >>> always possible. >> >> "OMG...programming language lets programmer write bad software. >> City on fire; film at 11."" > >Those examples are in a class of their own, and are utterly crass. > >They should be impossible to write in any HLL. Ok. >>> BTW I understand exactly what's going on. >> >> All available evidence suggests otherwise. >> >>> I did implement C at one time. >> >> Given that you don't seem to know how C is defined, I find it >> probable that you implemented your conception of C; whether it >> was actually C or not is a separate matter. > >It is a non-conforming C subset somewhere between C90 and C99. It can >just about run SQLite: >[snip] "Just about"? As in, not fully? Actually, don't answer that; I don't care. If you think that in itself is sufficient demonstration already tells me everything I need to know. >> 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. > >You don't need evidence, since it is clear enough! No, really. You do. >While my 2026 language is old-fashioned compared with modern languages, >it runs rings around C. Here are some highlights: > >[snip] 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". And moreover, even if it did, your language is not subject to any of the real-world constraints that C is vis installed base or backwards compatibility, or the need to run on anything other than a tiny set of machine architectures decided solely by you. You have it positively _easy_ compared to C. >>> You do understand that making a language simple and easy to understand >>> and explain is part of the process? >> >> a) There is no evidence that you actually did that successfully, >> other than your own assertions. > >I have a feeling that no amount of 'evidence' will convince you. Or that >even if it did, it wouldn't cut any ice. > >You are determined to belittle any of my achievements. Frankly, I don't care about your achievements one way or the other. They don't affect me in any material way. The point I'm making is that your attempts to use them as evidence for your own expertise are a logical fallacy; they simply do not matter for what you are claiming. And similarly, they are not, in any way, evidence for how awful you claim C is. That is not to say that C _is_ an awful language, just that you have not shown that, and pointing to your accomplishments does nothing for your argument, and in fact, weakens it. >> b) Even if you did, it is irrelevant. The topic at hand is C, >> and your repeated statements show that do not understand even >> the most fundamental phrases in the C language standard; your >> "understanding" of C seems to be based almost entirely on >> subjective opinion and misconceptions about C's design, >> history, and specification. >> >> Thus, your opinion about C is undeserving of consideration. > >EVERY user of C is entitled to their opinion. They don't need to be an >expert in languages or compilers either. Yes. You are absolutely entitled to your opinion. I did not say otherwise. I merely said that your opinion is ill-informed and not worthy of consideration. Further, you are claiming an above average level of expertise that you have not shown yourself to possess. >>>>> probably even fewer who also designed and built their own hardware. >>>> >>>> LOL. Ok. >>> >>> Why is that funny? That's exactly what I did, as it was my job. >> >> Because "designed and built their own hardware" is a) something >> that lots of people do, and b) varies incredibly. There's a big >> difference between blinking an LED, building an simple board >> with a few sensors and an embedded microcontroller, and building >> a full-on server-scale machine or end-user device. You didn't >> specify which (nor do I care). > >You are determined not to care aren't you?! Why should I? >In fact, there is NO amount of experience I can offer that will make >your repect my entitlement to my opinions. False. I respect your entitlement to your opinions. I just do respect the opinions themselves, because you have shown them to be poorly informed and poorly articulated. >However lots of people do believe that working directly on hardware >gives you valuable insights. Sure. Into hardware. Perhaps into architecture. Perhaps it leads to the realization that the real world is analog and the "digital" nature of computers is a bit of a parlor trick made from timing smoke and fuzzily defined ranges for "logic level" mirrors. But into the design of programming languages or compilers? No. >> It's also utterly irrelevant to programming languages, > >It is 100% relevant since PLs have to be implemented on real hardware. Actually, that's demonstrably not true. Consider bytecode interpreters, such as the JVM, or transpilation to other languages. One of the more famous early programming languages, Lisp, started out purely as a mathematical notation, with no intention to run on an actual machine. McCarthy actually scolded the grad student who implemented it on the 704. "Ho, ho, you're confusing theory with practice." >> So yes: "I built my own hardware!" as a claim of deep expertise >> in programming languages strikes me as desparate, and laughable. > >I don't think it's me who's desperate. Yes, it is. >Yes, I HAD to make my own computer at one point because I had no job and >little money, but wanted to program. > > [snip] > >That HLL evolved to what I have now, and I'm very proud of it. Clearly! You keep holding it up as an example of your expertise. >The experience also landed me a job in a small computer company. Congratulations. What, do you want a cookie or something? >> Fine. But that really doesn't qualify you to have an opinion on >> a language you evidently do not understand. > >So who /is/ entitled to an opinion on C? Anyone is _allowed_ to have one. That doesn't mean you are _qualified_ to have one, or that your opinion is _good_. >What exactly does have anyone have to do in order for their opinion to >be respected? I mean, few C users read the C standard cover to cover. Ah, see, you admit it. You don't just think that you are entitled to an opinion, _you believe that you are entitled to your opinion being respected_. That is the part that does not follow. >And why doesn't any of that apply to you? I never said that it does. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-06 23:38 +0100 |
| Message-ID | <10tgfs8$1i2g4$1@dont-email.me> |
| In reply to | #398422 |
On 06/05/2026 20:35, Dan Cross wrote:
> In article <10tflij$19d6u$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
> of what it says. Vis UB you've shown you are unable to do that.
> Therefore, your opinion on UB is uninformed, and thus not worth
> significant consideration.
As an implementer I've had to make decisions about what C calls 'UB'.
Those decisions have generally worked out.
Most people use off-the-shelf languages so, if they have an opinion
about it, it is either speculation, or they are comparing with some
other off-the-shelf language.
So on that basis, mine is somewhat more informed.
> You can choose whatever you like. Some people like neon orange
> for home decorations. That does not mean that those people are
> experts on interior decorating.
In the case of a tool I have to use, 10 hours a day every day, then I
choose. Here the homemade tool won out.
> Much more meaningful are the actual artifacts you've produced as
> examples of expertise. You haven't produced that much,
How do you know that exactly? And what artifacts do you have in mind?
I produce computer programs. You want to see binary? I can offer a link.
However nobody here, all the experts, have ever offered a link to any of
the work they do, not even privately. I've never seen examples of actual
programs except answers to fun challenges.
So, again, why am I expected to provide credentials?
(In 2005 I was invited to a concert at a very large arena in Europe, by
somebody who had designed the elaborate stage set. That was dominated by
a set of tall metal towers that were leaning outwards at a 15-degree angle.
Why 15 degrees? Because he'd used my 3D CAD software to help design it,
and that was the default 'snap' angle that he didn't bother changing.
I guess that was one concrete 'artifact', and that was one client. The
software was written in my language, with some add-ons written in its
scripting language that I has also created.)
> and your
> writing and statements betray a deep lack of understanding of
> the object of your criticism, in this case the C programming
> language.
Understanding it doesn't make the language much better! I learnt a lot
more about it when I implemented it in 2017, and my opinion of it
dropped several notches.
> Put another way, there's no evidence to back up your
> claim that those years count for much at all.
If it makes you happy, then carry on thinking that.
But suppose the same criticisms came from somebody whom you respected;
then what? I guess one of two things would happen:
(1) You'd change your mind and agree, and then you'd have to admit I
might have a point
(2) You still disagreed, in which case my background would not matter at
all.
However, if you knew more about the subject, then my opinions would
stand on their own: are they reasonable or not?
You want to consider that C is what it is because it has to work for any
whacko hardware past, present and future, so compromises have to be
made, and backward comnpatibility has to be taken into account.
Whereas my projects were always targeted at whatever machine I was using
(evolving from PDP10 to x64, with a brief stab at ARM64), and I could
afford to break compatibility.
Therefore I have an advantage in producing a tidier language with some
modern conveniences. You might want to admit that rather than just
trashing everything because you don't care for my attitude.
> I am forced to conclude that you don't actually have much in the
> way of true expertise in the domain.
What does true expertise look like? What are the characteristics of a
well-designed product?
I have my own set of criteria. A product LLVM, for example, fails on
just about every one.
>> But then, I first come across C in 1982
>> and disliked it then; I didn't need 45 extra years of experience to
>> confirm it!
>
> C now is not C from 1982. Void pointers hadn't even been
> invented then. Function prototypes weren't a thing yet.
My dislike then was superficial. I'd spent £12 on K&R1, but I found it
so disapppointing as a language (I was used to Fortran, Pascal and the
Algols, especially Algol68) that I sold it to a colleague for £2.
> So in other words, you have no especial expertise in the matter.
>
> I had a drill instructor in Marine Corps boot camp once who said
> rather colorfully, "excuses are like assholes; everybody's got
> one." Opinions are like that, too.
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'.
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.
You will also have a harder type discerning the parameter names, as
there are dominated by all those ugly types.
This is one tiny example of better ergonomics. Now you're going to tell
me the C version is better!
>> C's use of curly braces do have a number of problems:
>>
>> if (c)
>> x;
>> y;
>>
>> if (c1)
>> x; // [This line shouldn't be here]
>> if (c2);
>> y;
>> else
>> z;
>>
>> What's happened with C is that a thousand times as much effort has gone
>> into compilers that try to detect and mitigate all its issues, as would
>> have taken to just fix the language in the first place.
>
> This is exactly the sort of ill-informed argument that I'm
> talking about.
Yet it is true. C compilers do have to work harder to detect things in
C, which wouldn't be necessary with a more thoughtful design.
> Note that there is not a single curly brace in
> the example above.
You noticed! They being optional is the point.
> The statement I suspect you are _trying_ to make is that the
> grammar of the language matches code that a human might see as
> ambiguous, particularly if formatted in a misleading way. In
> particular, the `secondary-block` production allows the braces
> to be elided in a way that is _usually_ grammatically correct,
> but may not be what the programmer intended.
>
> Two things on that.
>
> First, Pascal uses, `begin` and `end` to delimit block, but
> those are often _also_ optional in a similar way, and arguably
> it suffers from the same problem.
Yes, Algol60 and Pascal had the same annoying problem, in giving rise to
examples like this:
if cond then begin ... end else begin ... end
And in C:
if (cond) { ... } else { ... }
with a dozen placement options. This is something that Algol68 solved
tidily (although it favoured 'fi' over 'end'):
if cond then ... else ... end
The first block is naturally delimited by 'else'; only the last needs
'end'. Unfortunately it doesn't work with braces:
if (cond) ... else ... }
> Second, consider both Go and Rust, which use matched braces as
> delimiters, but make them required (and provide pretty-printers
> to format code readably, so that the structure is evident).
> Neither suffers from the ambiguity problems of the above snippet
> despite using curly braces.
They either need 'elsif/elseif', or there is a special rule for 'if' so
that you can write 'else if ...' instead of 'else {if ...'.
> I conclude that the actual tokens used to delimit block
> structure are purely incidental.
The problems are partly {} being optional, which makes it error prone
(forget one brace, but it is balanced by an extra one elsewhere), and
also by the plethora of placement options, leading to lots of diverse
styles.
(There are fewer ways to arrange one token 'else', compared with the
three in '} else {'.)
I also dislike braces because I don't consider them substantial enough
for multi-line blocks. They're OK on one line, or for machine-generated
code.
> Well, that curly braces are a problem with the language, for
> one. See the previous example.
And see my new comments.
>> Those people did not invent their own languages and implementations.
>
> Perhaps they did not; at least as far as you are aware of. But
> so what? How is that relevant?
It shows my product was not a toy, which you were using to belittle my
arguments. If you were writing apps in the 1980s on machines like PCs,
then you were probably responsible for 99% of code running while your
app was active, including drivers and library vector and bitmap graphics.
The language used had some heavy lifting to do, and mine was also
self-hosted. It earned its keep.
>> The
>> point was brought up because you were dismissing my efforts as worthless
>> toys.
>
> Yes. What I suspect happened is that you stumbled onto a niche
> that is vanishingly small, with few or no other players, so you
> were able to dictate your own technology terms,
This is getting tedious. You can't seem to stand the fact that I may
have done something worthwhile, and have to find excuses. So maybe it
was all luck!
My product was low-end CAD. At one time I believe it was second to
AutoCAD in the Netherlands. Yes, it was a dull sector and not very sexy,
but why does that have to detract from what I managed to do?
For that matter, there were a few other players too.
> But that does not make you an expert in C, or qualify your
> opinions above those of others, and your public statements show
> a lack of understanding of the language itself.
I've suggested that signed overflow should be either well-defined by the
language, with wraparound semantics like unsigned, or be implementation
defined. See my post at 12:00 BST, today 6th.
You don't agree, OK (and it's never going to happen anyway).
But you decide to go on a long campaign to discredit me, and try to
destroy and belittle everything I've done ('it must have been a fluke!')
to the extent that I'm starting to have serious self-doubts.
I shouldn't be affected by the personal digs of a random guy on the
internet, but there we here. Last year I had to take a 6-month break
from this forum because it was becoming a toxic environment.
Maybe it's time to do the same.
> "Just about"? As in, not fully? Actually, don't answer that; I
> don't care. If you think that in itself is sufficient
> demonstration already tells me everything I need to know.
FFS. Not many people write C compilers, especially those that dislike
the language. Can't I have just one win?!
>> While my 2026 language is old-fashioned compared with modern languages,
>> it runs rings around C. Here are some highlights:
>>
>> [snip]
>
> 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:
* There are no C-style header files
* There are no separate declarations needed, neither in shared headers,
nor as prototypes
* If a module is imported by 50 others, it is processed exactly once
* Project info (modules etc) is present in only one module of a project.
(Most module schemes require import directives in every module)
* That means no external build system is needed.
Just that is HUGE.
> And moreover, even if it did, your language is not subject to
> any of the real-world constraints that C is vis installed base
> or backwards compatibility, or the need to run on anything other
> than a tiny set of machine architectures decided solely by you.
> You have it positively _easy_ compared to C.
Exactly! (I've probably mentioned it in this long post.)
For that very reason my language has the advantage, and that helps with
productivity.
> than a tiny set of machine architectures decided solely by you.
It will run on x64/Windows. It could also run on any other 64-bit
platform if I were to create a backend. (It will do that now if I deign
to use its C backend, but that only exists on an older compiler.)
A version of it, with a restricted front-end, targets 8-bit Z80 (but
won't run /on/ the Z80).
Look, C wouldn't run on much either if it weren't for an army of people
doing all the work! The language itself runs on NOTHING until somebody
implements it.
>> You are determined to belittle any of my achievements.
>
> Frankly, I don't care about your achievements one way or the
> other. They don't affect me in any material way.
They seem to annoy you.
> Further, you are claiming an above average level of expertise
> that you have not shown yourself to possess.
That's your opinion. But I am not sure you have the expertise in this
area to be able to judge.
>> However lots of people do believe that working directly on hardware
>> gives you valuable insights.
>
> Sure. Into hardware. Perhaps into architecture. Perhaps it
> leads to the realization that the real world is analog and the
> "digital" nature of computers is a bit of a parlor trick made
> from timing smoke and fuzzily defined ranges for "logic level"
> mirrors.
>
> But into the design of programming languages or compilers? No.
OK, now I am more sure, and so I won't take this line any further.
>> It is 100% relevant since PLs have to be implemented on real hardware.
>
> Actually, that's demonstrably not true. Consider bytecode
> interpreters, such as the JVM, or transpilation to other
> languages.
Bytecode interpreters have to be implemented on real hardware. Remember
I do both!
> Ah, see, you admit it. You don't just think that you are
> entitled to an opinion, _you believe that you are entitled to
> your opinion being respected_.
This is something I encounter a lot. Somebody ends up with 'X', a big
steaming pile of complexity, layer upon layer, full of ancient folklore,
that only a few gurus know completely (or nobody in the case of C++).
Then somebody comes along and questions that complexity. They want to
get quickly and easily from A to B but don't like dealing with X in the
middle which is causing problems.
However if they complain, they get told that they don't understand X and
they don't know what they're talking about.
Needing to understand X is the problem.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-07 03:02 +0000 |
| Message-ID | <10tgvcq$bt2$1@reader1.panix.com> |
| In reply to | #398425 |
In article <10tgfs8$1i2g4$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>On 06/05/2026 20:35, Dan Cross wrote:
>> In article <10tflij$19d6u$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>> of what it says. Vis UB you've shown you are unable to do that.
>> Therefore, your opinion on UB is uninformed, and thus not worth
>> significant consideration.
>
>As an implementer I've had to make decisions about what C calls 'UB'.
>Those decisions have generally worked out.
You don't even understand what UB is.
>Most people use off-the-shelf languages so, if they have an opinion
>about it, it is either speculation, or they are comparing with some
>other off-the-shelf language.
Huh? That doesn't follow. Other people have clearly read the
definition in the relevant standards documents and demonstrated
that they understand what it means. They've even explained it
to you. You just do not seem capable of understanding those
explanations, or the concept.
That's not "speculation" or "comparison" or whatever; it's just
reading understanding and figuring out what the words mean.
>So on that basis, mine is somewhat more informed.
Not how it works. To be informed you have to actually
understand the thing.
>> You can choose whatever you like. Some people like neon orange
>> for home decorations. That does not mean that those people are
>> experts on interior decorating.
>
>In the case of a tool I have to use, 10 hours a day every day, then I
>choose. Here the homemade tool won out.
Good for you.
>> Much more meaningful are the actual artifacts you've produced as
>> examples of expertise. You haven't produced that much,
>
>How do you know that exactly? And what artifacts do you have in mind?
I dunno, how about a written description of this language of
yours and its semantics? Have you ever written a paper about
it? An article? Ever presented at a conference? Or even just
given an informal presentation? Have you ever asked anyone else
to comment on your design?
>I produce computer programs.
Ok.
>You want to see binary?
No.
>I can offer a link.
To what, a binary? No thanks.
>However nobody here, all the experts, have ever offered a link to any of
>the work they do, not even privately. I've never seen examples of actual
>programs except answers to fun challenges.
Nonsense. Lots of people here have source code that is online;
many of us make open source contributions. Look them up if you
want.
>So, again, why am I expected to provide credentials?
Because you are claiming expertise, obviously.
>(In 2005 I was invited to a concert at a very large arena in Europe, by
>somebody who had designed the elaborate stage set. That was dominated by
>a set of tall metal towers that were leaning outwards at a 15-degree angle.
>
>Why 15 degrees? Because he'd used my 3D CAD software to help design it,
>and that was the default 'snap' angle that he didn't bother changing.
>
>I guess that was one concrete 'artifact', and that was one client. The
>software was written in my language, with some add-ons written in its
>scripting language that I has also created.)
You must be joking.
>> and your
>> writing and statements betray a deep lack of understanding of
>> the object of your criticism, in this case the C programming
>> language.
>
>Understanding it doesn't make the language much better! I learnt a lot
>more about it when I implemented it in 2017, and my opinion of it
>dropped several notches.
Understanding doesn't change the quality of a thing; that's kind
of obvious. But understanding a thing is a prerequisite for
offering relevant critique of the quality of that thing. Just
based on your statements here over the last few days, you
clearly do not even understand C. So how can you meaningfully
critique it?
>> Put another way, there's no evidence to back up your
>> claim that those years count for much at all.
>
>If it makes you happy, then carry on thinking that.
>
>But suppose the same criticisms came from somebody whom you respected;
>then what? I guess one of two things would happen:
>
>(1) You'd change your mind and agree, and then you'd have to admit I
>might have a point
>
>(2) You still disagreed, in which case my background would not matter at
>all.
Again, a logical fallacy. What I am saying is that you do not
seem to have any special qualifications that should privilege
your opinion of C over that of anyone else, and the evidence,
which is based on your own written statements, show that your
understanding of the C programming language is not very good.
That doesn't mean that all of your opinions about C is therefore
_wrong_. It just means that, when you are right, it is just as
likely (if not somewhat more so) that it is by accident than
otherwise.
>However, if you knew more about the subject, then my opinions would
>stand on their own: are they reasonable or not?
But _you don't_ know more about the subject. That's the point.
>You want to consider that C is what it is because it has to work for any
>whacko hardware past, present and future, so compromises have to be
>made, and backward comnpatibility has to be taken into account.
>
>Whereas my projects were always targeted at whatever machine I was using
> (evolving from PDP10 to x64, with a brief stab at ARM64), and I could
>afford to break compatibility.
>
>Therefore I have an advantage in producing a tidier language with some
>modern conveniences. You might want to admit that rather than just
>trashing everything because you don't care for my attitude.
This is actually evidence of exactly what I've been saying all
along. You claim you have a "tidier language" but a) that's
subjective and b) irrelevant (no one here besides you cares
about your language) and c) doesn't mean anything with respect
to whether or not you understand C.
On the other hand, you are not even capable of understanding
what "undefined behavior" means as written in the the standard;
so why should I, or anyone else, listen to _anything_ you have
to say about the matter? Hint: we shouldn't.
>> I am forced to conclude that you don't actually have much in the
>> way of true expertise in the domain.
>
>What does true expertise look like?
For starters, demonstrating that you know what the terms in the
standard actually mean.
>What are the characteristics of a
>well-designed product?
>
>I have my own set of criteria. A product LLVM, for example, fails on
>just about every one.
So? Why should anyone care about your criteria or opinion?
>>> But then, I first come across C in 1982
>>> and disliked it then; I didn't need 45 extra years of experience to
>>> confirm it!
>>
>> C now is not C from 1982. Void pointers hadn't even been
>> invented then. Function prototypes weren't a thing yet.
>
>My dislike then was superficial. I'd spent £12 on K&R1, but I found it
>so disapppointing as a language (I was used to Fortran, Pascal and the
>Algols, especially Algol68) that I sold it to a colleague for £2.
Perhaps we should add "superficial" to the list of common words
and phrases you do not understand.
>> So in other words, you have no especial expertise in the matter.
>>
>> I had a drill instructor in Marine Corps boot camp once who said
>> rather colorfully, "excuses are like assholes; everybody's got
>> one." Opinions are like that, too.
>
>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 ...
That's awful.
>All the parameters are the same type. If you change that first u64, they
>all change. The parameter names are 's t u v'.
>
>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.
>
>You will also have a harder type discerning the parameter names, as
>there are dominated by all those ugly types.
>
>This is one tiny example of better ergonomics. Now you're going to tell
>me the C version is better!
No. I'm going to tell you that nobody cares what your language
does and what you just wrote is a total non sequitur. None of
this demonstrates expertise in C.
>>> C's use of curly braces do have a number of problems:
>>>
>>> if (c)
>>> x;
>>> y;
>>>
>>> if (c1)
>>> x; // [This line shouldn't be here]
>>> if (c2);
>>> y;
>>> else
>>> z;
>>>
>>> What's happened with C is that a thousand times as much effort has gone
>>> into compilers that try to detect and mitigate all its issues, as would
>>> have taken to just fix the language in the first place.
>>
>> This is exactly the sort of ill-informed argument that I'm
>> talking about.
>
>Yet it is true. C compilers do have to work harder to detect things in
>C, which wouldn't be necessary with a more thoughtful design.
...but that has nothing to do with curly braces....
>> Note that there is not a single curly brace in
>> the example above.
>
>You noticed! They being optional is the point.
...which has nothing to do with them being curly braces....
>> The statement I suspect you are _trying_ to make is that the
>> grammar of the language matches code that a human might see as
>> ambiguous, particularly if formatted in a misleading way. In
>> particular, the `secondary-block` production allows the braces
>> to be elided in a way that is _usually_ grammatically correct,
>> but may not be what the programmer intended.
>>
>> Two things on that.
>>
>> First, Pascal uses, `begin` and `end` to delimit block, but
>> those are often _also_ optional in a similar way, and arguably
>> it suffers from the same problem.
>
>Yes, Algol60 and Pascal had the same annoying problem, in giving rise to
>examples like this:
>
> [snip a bunch of subjective assertions that only tangentially
> mention curly braces]
>
>> Second, consider both Go and Rust, which use matched braces as
>> delimiters, but make them required (and provide pretty-printers
>> to format code readably, so that the structure is evident).
>> Neither suffers from the ambiguity problems of the above snippet
>> despite using curly braces.
>
>They either need 'elsif/elseif', or there is a special rule for 'if' so
>that you can write 'else if ...' instead of 'else {if ...'.
...which has nothing to do with curly braces....
>> I conclude that the actual tokens used to delimit block
>> structure are purely incidental.
>
>The problems are partly {} being optional, which makes it error prone
>(forget one brace, but it is balanced by an extra one elsewhere), and
>also by the plethora of placement options, leading to lots of diverse
>styles.
...which has nothing to do with the choice of symbols for the
delimiter tokens; that is, nothing to do with curly braces.
>(There are fewer ways to arrange one token 'else', compared with the
>three in '} else {'.)
...which has nothing to do with curly braces as delimiter
tokens.
>I also dislike braces because I don't consider them substantial enough
>for multi-line blocks. They're OK on one line, or for machine-generated
>code.
This is completely subjective.
>> Well, that curly braces are a problem with the language, for
>> one. See the previous example.
>
>And see my new comments.
Your comments had little to do with curly braces; rather they
expressed a subjective dislike for matched delimiter pairs
denoting block scope. The only comment that was _actually_
about braces amounted to a statement that you don't like them.
>>> Those people did not invent their own languages and implementations.
>>
>> Perhaps they did not; at least as far as you are aware of. But
>> so what? How is that relevant?
>
>It shows my product was not a toy,
Nope. That doesn't follow at all. Whether someone else
developed their own language and implementation has absolutely
nothing to do with whether your thing is a toy or not; these
are orthogonal.
>which you were using to belittle my arguments.
I'm using your arguments to belittle your arguments. They're
just not good.
>If you were writing apps in the 1980s on machines like PCs,
>then you were probably responsible for 99% of code running while your
>app was active, including drivers and library vector and bitmap graphics.
>
>The language used had some heavy lifting to do, and mine was also
>self-hosted. It earned its keep.
Ok.
...none of which qualifies you as an expert on C, programming
language, or compiler design.
>>> The
>>> point was brought up because you were dismissing my efforts as worthless
>>> toys.
>>
>> Yes. What I suspect happened is that you stumbled onto a niche
>> that is vanishingly small, with few or no other players, so you
>> were able to dictate your own technology terms,
>
>This is getting tedious. You can't seem to stand the fact that I may
>have done something worthwhile, and have to find excuses. So maybe it
>was all luck!
No, I am not making any statements about whether what you did
was worthwhile or not; honestly I don't care.
What I am saying is that none of it qualifies as you as an
expert on language or compiler design, nor on C.
>My product was low-end CAD. At one time I believe it was second to
>AutoCAD in the Netherlands. Yes, it was a dull sector and not very sexy,
>but why does that have to detract from what I managed to do?
It doesn't. But it doesn't mean that what you managed to do has
qualified you in some unique way to have opinions on programming
lanauges. Or compilers. Or C.
>For that matter, there were a few other players too.
Ok.
>> But that does not make you an expert in C, or qualify your
>> opinions above those of others, and your public statements show
>> a lack of understanding of the language itself.
>
>I've suggested that signed overflow should be either well-defined by the
>language, with wraparound semantics like unsigned, or be implementation
>defined. See my post at 12:00 BST, today 6th.
Even today your statements suggested you still don't have a good
handle on what "undefined behavior" means.
>You don't agree, OK (and it's never going to happen anyway).
I never said I disagreed. What I said is that your opinion is
not well-informed.
>But you decide to go on a long campaign to discredit me, and try to
>destroy and belittle everything I've done ('it must have been a fluke!')
>to the extent that I'm starting to have serious self-doubts.
>
>I shouldn't be affected by the personal digs of a random guy on the
>internet, but there we here. Last year I had to take a 6-month break
>from this forum because it was becoming a toxic environment.
>
>Maybe it's time to do the same.
Probably a good idea.
You post a bunch of misinformed claptrap, claim without evidence
to be some kind of expert because you designed your own language
and wrote a compiler for it back in the 1980s, smugly proclaim
that it is better than C, but can't really support that
assertion, and now that people are pointing out how none of your
arguments really hold up and you keep making factual
misstatements, keep arguing leaving gaps in logic, and that you
keep indulging in logical fallacies, all about the area you
claim to be an expert in, and now you're saying that that's
making you feel bad? Wow.
>> "Just about"? As in, not fully? Actually, don't answer that; I
>> don't care. If you think that in itself is sufficient
>> demonstration already tells me everything I need to know.
>
>FFS. Not many people write C compilers, especially those that dislike
>the language. Can't I have just one win?!
Sure. You can have a win. Go read and internalize what UB
means and demonstrate that you understand it. That'd be a win:
you would learn something, and people would take you more
seriously.
>>> While my 2026 language is old-fashioned compared with modern languages,
>>> it runs rings around C. Here are some highlights:
>>>
>>> [snip]
>>
>> 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:
>
>* There are no C-style header files
>* There are no separate declarations needed, neither in shared headers,
>nor as prototypes
>* If a module is imported by 50 others, it is processed exactly once
>* Project info (modules etc) is present in only one module of a project.
>(Most module schemes require import directives in every module)
>* That means no external build system is needed.
>
>Just that is HUGE.
See above, caveat that the modules thing sounds like a huge
mess.
>> And moreover, even if it did, your language is not subject to
>> any of the real-world constraints that C is vis installed base
>> or backwards compatibility, or the need to run on anything other
>> than a tiny set of machine architectures decided solely by you.
>> You have it positively _easy_ compared to C.
>
>Exactly! (I've probably mentioned it in this long post.)
>
>For that very reason my language has the advantage, and that helps with
>productivity.
No, it just means that code in your language is proprietary and
not particularly portable. Neither of those is an "advantage."
> > than a tiny set of machine architectures decided solely by you.
>
>It will run on x64/Windows. It could also run on any other 64-bit
>platform if I were to create a backend. (It will do that now if I deign
>to use its C backend, but that only exists on an older compiler.)
>
>A version of it, with a restricted front-end, targets 8-bit Z80 (but
>won't run /on/ the Z80).
>
>Look, C wouldn't run on much either if it weren't for an army of people
>doing all the work! The language itself runs on NOTHING until somebody
>implements it.
Non-sequitur.
>>> You are determined to belittle any of my achievements.
>>
>> Frankly, I don't care about your achievements one way or the
>> other. They don't affect me in any material way.
>
>They seem to annoy you.
Not at all. They're just not evidence of the things you claim
them to be evidence of. They're irrelevant to me, either way.
>> Further, you are claiming an above average level of expertise
>> that you have not shown yourself to possess.
>
>That's your opinion. But I am not sure you have the expertise in this
>area to be able to judge.
That's ok. I am quite certain that you do not have that
expertise.
>>> However lots of people do believe that working directly on hardware
>>> gives you valuable insights.
>>
>> Sure. Into hardware. Perhaps into architecture. Perhaps it
>> leads to the realization that the real world is analog and the
>> "digital" nature of computers is a bit of a parlor trick made
>> from timing smoke and fuzzily defined ranges for "logic level"
>> mirrors.
>>
>> But into the design of programming languages or compilers? No.
>
>OK, now I am more sure, and so I won't take this line any further.
Good. Perhaps there is hope for you yet.
>>> It is 100% relevant since PLs have to be implemented on real hardware.
>>
>> Actually, that's demonstrably not true. Consider bytecode
>> interpreters, such as the JVM, or transpilation to other
>> languages.
>
>Bytecode interpreters have to be implemented on real hardware. Remember
>I do both!
But that's not what you said. You said, "PLs have to be
implemented on real hardware." A byte code interpreter may be
implemented in a program that runs directly on hardware (or in
its own ersatz threaded code interpreter, say). But that is
qualitatively different than running directly on the bare metal.
I see you snipped the vinette about Lisp.
>> Ah, see, you admit it. You don't just think that you are
>> entitled to an opinion, _you believe that you are entitled to
>> your opinion being respected_.
>
>This is something I encounter a lot. Somebody ends up with 'X', a big
>steaming pile of complexity, layer upon layer, full of ancient folklore,
>that only a few gurus know completely (or nobody in the case of C++).
>
>Then somebody comes along and questions that complexity. They want to
>get quickly and easily from A to B but don't like dealing with X in the
>middle which is causing problems.
>
>However if they complain, they get told that they don't understand X and
>they don't know what they're talking about.
>
>Needing to understand X is the problem.
Non-sequitur to what I just said. None of it changes the fact
that you believe you are not only entitled to _an_ opinion, but
also entitled to that opinion commanding respect. But again,
you've produced scant little evidence supporting that assertion,
and you certainly have not earned the right to demand that your
opinion be "respected."
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-07 12:10 +0100 |
| Message-ID | <10thrud$1v1r3$1@dont-email.me> |
| In reply to | #398430 |
On 07/05/2026 04:02, Dan Cross wrote: > You don't even understand what UB is. > You just do not seem capable of understanding those explanations, or the concept. > To be informed you have to actually understand the thing. > Good for you. > To what, a binary? No thanks. > Because you are claiming expertise, obviously. > You must be joking. > you clearly do not even understand C. So how can you meaningfully > critique it? > Again, a logical fallacy. What I am saying is that you do not > seem to have any special qualifications that should privilege > your opinion of C over that of anyone else, and the evidence, > which is based on your own written statements, show that your > understanding of the C programming language is not very good. > It just means that, when you are right, it is just as > likely (if not somewhat more so) that it is by accident than > otherwise. > But _you don't_ know more about the subject. That's the point. > On the other hand, you are not even capable of understanding > what "undefined behavior" means as written in the the standard; > So? Why should anyone care about your criteria or opinion? > Perhaps we should add "superficial" to the list of common words > and phrases you do not understand. >> func F(u64 s, t, u, v)u64 ... > > That's awful. (I guess I win my bet.) > None of this demonstrates expertise in C. >> You noticed! They being optional is the point. > ...which has nothing to do with them being curly braces.... > ...which has nothing to do with curly braces.... > ...which has nothing to do with curly braces as delimiter > tokens. > This is completely subjective. > I'm using your arguments to belittle your arguments. They're > just not good. > No, I am not making any statements about whether what you did > was worthwhile or not; honestly I don't care. > What I am saying is that none of it qualifies as you as an > expert on language or compiler design, nor on C. > It doesn't. But it doesn't mean that what you managed to do has > qualified you in some unique way to have opinions on programming > lanauges. Or compilers. Or C. > Even today your statements suggested you still don't have a good > handle on what "undefined behavior" means. > I never said I disagreed. What I said is that your opinion is > not well-informed. > You post a bunch of misinformed claptrap, claim without evidence > to be some kind of expert because you designed your own language > and wrote a compiler for it back in the 1980s, smugly proclaim > that it is better than C, but can't really support that > assertion, and now that people are pointing out how none of your > arguments really hold up and you keep making factual > misstatements, keep arguing leaving gaps in logic, and that you > keep indulging in logical fallacies, all about the area you > claim to be an expert in, and now you're saying that that's > making you feel bad? Wow. > Sure. You can have a win. Go read and internalize what UB > means and demonstrate that you understand it. That'd be a win: > you would learn something, and people would take you more > seriously. > See above, caveat that the modules thing sounds like a huge > mess. > Non-sequitur. > Not at all. They're just not evidence of the things you claim > them to be evidence of. They're irrelevant to me, either way. Wow. You're quite a piece of work, you know that? I'm also not entirely sure whether this is all an elaborate wind-up: require somebody to back up their comments up with credentials from their real life (SOMETHING THAT NEVER HAPPENS WITH ANYONE ELSE POSTING), just to be able to shoot them down no matter what they say, because you get a kick out it. Or maybe you are just a very unpleasant person anyway. >> OK, now I am more sure, and so I won't take this line any further. > > Good. Perhaps there is hope for you yet. (I was politely indicating that you don't appear to understand the subject and it would be futile to discuss it further with you.) > I dunno, how about a written description of this language of > yours and its semantics? https://github.com/sal55/langs/tree/master/MLanguage (Against my better judgement, as I can't imagine any circumstances in which you are going to have anything positive to say about it, it will be just be fuel for more cutting remarks.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-07 08:32 -0700 |
| Message-ID | <86bjeruteu.fsf@linuxsc.com> |
| In reply to | #398438 |
Bart <bc@freeuk.com> writes: > On 07/05/2026 04:02, Dan Cross wrote: [...] >> [...] how about a written description of this language of >> yours and its semantics? > > https://github.com/sal55/langs/tree/master/MLanguage I found the language features document, https://github.com/sal55/langs/tree/master/MLanguage/Mfeatures.md quite illuminating.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-07 15:36 +0000 |
| Message-ID | <10tibhl$ba1$1@reader1.panix.com> |
| In reply to | #398438 |
In article <10thrud$1v1r3$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 07/05/2026 04:02, Dan Cross wrote: >> [snip] > >Wow. You're quite a piece of work, you know that? I gather you did not appreciate my responses. >I'm also not entirely sure whether this is all an elaborate wind-up: >require somebody to back up their comments up with credentials from >their real life (SOMETHING THAT NEVER HAPPENS WITH ANYONE ELSE POSTING), >just to be able to shoot them down no matter what they say, because you >get a kick out it. I have required you to do nothing; I have literally no control over you in any form whatsoever. I've simply made statements about what you have said. >Or maybe you are just a very unpleasant person anyway. *shrug* Ok. >>> OK, now I am more sure, and so I won't take this line any further. >> >> Good. Perhaps there is hope for you yet. > >(I was politely indicating that you don't appear to understand the >subject and it would be futile to discuss it further with you.) *shrug* Ok. > > I dunno, how about a written description of this language of > > yours and its semantics? > >https://github.com/sal55/langs/tree/master/MLanguage > >(Against my better judgement, as I can't imagine any circumstances in >which you are going to have anything positive to say about it, it will >be just be fuel for more cutting remarks.) I like that it is expression-oriented. It was clearly inspired by (at least) ML, which is a sound basis for a language design. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-07 18:20 +0200 |
| Message-ID | <10tie4h$1l93l$1@dont-email.me> |
| In reply to | #398452 |
On 2026-05-07 17:36, Dan Cross wrote: > In article <10thrud$1v1r3$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >> >> https://github.com/sal55/langs/tree/master/MLanguage >> >> (Against my better judgement, as I can't imagine any circumstances in >> which you are going to have anything positive to say about it, it will >> be just be fuel for more cutting remarks.) Your languages have no importance for most people here but it serves my curiosity! And it's good that you posted that link and gave us an impression of what sort of language you specifically like. (Not too many surprises here, though, given that you've regularly talked about your languages here with unsolicited examples.) > > I like that it is expression-oriented. It was clearly inspired > by (at least) ML, which is a sound basis for a language design. I can't tell about ML, but from earlier posts of Bart I'd have guessed it was rather from Algol 68, and a statement on these pages seems to confirm that: "This was heavily inspired by Algol68, but with a number of differences [...]" Janis
[toc] | [prev] | [next] | [standalone]
Page 7 of 37 — ← Prev page 1 … 5 6 [7] 8 9 … 37 Next page →
Back to top | Article view | comp.lang.c
csiph-web