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 733 — 19 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' 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' 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 22 of 37 — ← Prev page 1 … 20 21 [22] 23 24 … 37 Next page →
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-14 09:54 +0200 |
| Message-ID | <10u3v2p$34b89$7@dont-email.me> |
| In reply to | #398929 |
On 2026-05-14 07:47, tTh wrote: > On 5/14/26 03:39, Janis Papanagnou wrote: > >> although it's somewhat >> quirky to imagine a thing that is physically "5 Bit" > > Â Â Is data on the wire a physical thing ? These terms are a bit peculiar in the given context, but I'd say yes, they are sort of a "physical thing". - Certainly so if you want them differentiated from the abstract unit "bit". > > Â Â https://en.wikipedia.org/wiki/Baudot_code Not sure what you want to tell us with that link. But since you mention the Baudot_code; you certainly remember the unit 'baud'; it's basically a symbol rate, not a bit-rate, and only with specific constraints there's an equivalence relation possible to bit-rate possible. - How would an analog modulated signal of a symbol be expressed in "bits"! Just BTW. Janis
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-14 06:25 -0700 |
| Message-ID | <86pl2yi0n3.fsf@linuxsc.com> |
| In reply to | #398919 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 2026-05-13 20:00, Tim Rentsch wrote: > >> There is another difference worth noting. A byte is a unit of >> storage, whereas octet is a measure of information. The word >> byte is inherently about memory; the word octet is inherently >> about value (eight bits of information). For this reason too >> the name 'octet' is a better choice for a type name than 'byte'. > > Well, I have a slightly different view; I suppose it's cultural. > > I often see, specifically from the Anglo-American culture, that > they talk about, say, "8 bits"; and this has partly culturally > also spread across the ocean. - Here we try to distinguish the > units and the "metal"; the latter are formally substantives and > written with a capital letter. So we have units of "1 bit" or > "5 bit" entities (no 's' at the end). But seen as "metal" we > speak about "one Bit" or "five Bits" - although it's somewhat > quirky to imagine a thing that is physically "5 Bit", mostly it > is more accurate to say it's an entity of "5 bit" - and similar > with "1 byte". Because we use that also as _unit_ for 8 bit > entities. It gets complicated by us addressing the unit 'bit' > by a name, which is then "Bit". So the more accurate forms for > the _units_ are 5 bit or 8 byte. - As said, we may culturally > see that differently, and colloquially you nowadays also often > hear "5 Bits" or "8 Bytes" (as pluralized substantive), so it's > cumbersome to argue about that. - Only that "byte" is also a > unit (and not necessarily associated with memory) seems to be > our difference in how we view that. I don't know if I see what you're getting at here. My writing follows standard usage in American English. Sometimes the names of units are capitalized but for the most part they aren't. The names of units are singular or plural when used as nouns (1 bit, 2 bits), but singular when used as adjectives (16-bit int). There may be exceptions to those rules, I haven't thought about it deeply. My main point is that "byte" and "octet" are talking about different kinds of things. A computer might have 64k bytes of RAM, but normally I wouldn't (and I think normally other people wouldn't) say that a computer has 64k octets of RAM. We might say a computer has enough RAM to _hold_ 64k octets, but not that it _has_ 64k octets. There's a semantic incongruity in the latter case. Do you see what I mean?
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-14 17:49 +0000 |
| Message-ID | <10u51uq$euq$1@reader1.panix.com> |
| In reply to | #398946 |
In article <86pl2yi0n3.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > >> On 2026-05-13 20:00, Tim Rentsch wrote: >> >>> There is another difference worth noting. A byte is a unit of >>> storage, whereas octet is a measure of information. The word >>> byte is inherently about memory; the word octet is inherently >>> about value (eight bits of information). For this reason too >>> the name 'octet' is a better choice for a type name than 'byte'. >> >> Well, I have a slightly different view; I suppose it's cultural. >> >> I often see, specifically from the Anglo-American culture, that >> they talk about, say, "8 bits"; and this has partly culturally >> also spread across the ocean. - Here we try to distinguish the >> units and the "metal"; the latter are formally substantives and >> written with a capital letter. So we have units of "1 bit" or >> "5 bit" entities (no 's' at the end). But seen as "metal" we >> speak about "one Bit" or "five Bits" - although it's somewhat >> quirky to imagine a thing that is physically "5 Bit", mostly it >> is more accurate to say it's an entity of "5 bit" - and similar >> with "1 byte". Because we use that also as _unit_ for 8 bit >> entities. It gets complicated by us addressing the unit 'bit' >> by a name, which is then "Bit". So the more accurate forms for >> the _units_ are 5 bit or 8 byte. - As said, we may culturally >> see that differently, and colloquially you nowadays also often >> hear "5 Bits" or "8 Bytes" (as pluralized substantive), so it's >> cumbersome to argue about that. - Only that "byte" is also a >> unit (and not necessarily associated with memory) seems to be >> our difference in how we view that. > >I don't know if I see what you're getting at here. My writing >follows standard usage in American English. Sometimes the names >of units are capitalized but for the most part they aren't. The >names of units are singular or plural when used as nouns (1 bit, >2 bits), but singular when used as adjectives (16-bit int). >There may be exceptions to those rules, I haven't thought about >it deeply. > >My main point is that "byte" and "octet" are talking about >different kinds of things. Not really. It has always been understood to refer to the same kind of thing that "byte" refers to. The problem was that, at the time the term "octet" was coined, the size of a byte (measured in bits) varied between different computers, and sometimes on the same computer. When people starting getting serious about making computers talk to one another, this became an issue: hence octet to have standard nomenclature. >A computer might have 64k bytes of >RAM, but normally I wouldn't (and I think normally other people >wouldn't) say that a computer has 64k octets of RAM. Some would, though it may sound a bit odd. The term is mostly historical at this point: the vast majority of systems standardized on 8-bit bytes last century, after IBM introduced the 360 line of computers with power-of-two widths for different types of data. 8-bit bytes quickly became dominant. >We might >say a computer has enough RAM to _hold_ 64k octets, but not that >it _has_ 64k octets. There's a semantic incongruity in the >latter case. Do you see what I mean? At this point, the term "byte" has been standardized by several different bodies (IEC, ISO) to be synonymous with octet. The continued use of "octet" by organizations like the IETF is mostly a legacy curiosity. Use of "octet" when referring to legacy systems that different byte sizes, or perhaps for some highly specialized devices, remains. Some hardware engineers may use it when dealing with, for example, RAM parts that have an extra parity bit per octet, combining to make a nine-bit byte, but would be a highly specialized and thus uncommon use. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-14 16:33 -0700 |
| Message-ID | <10u5m4m$uo0d$3@kst.eternal-september.org> |
| In reply to | #398960 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <86pl2yi0n3.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
[...]
>>My main point is that "byte" and "octet" are talking about
>>different kinds of things.
>
> Not really. It has always been understood to refer to the same
> kind of thing that "byte" refers to.
I agree, at least for the way I understand the terms. For me,
"octet" and "byte" refer to the same kind of thing. The difference
is that an "octet" is specifically 8 bits, and a "byte" is a
fundamental unit of storage for a given system (commonly 8 bits).
ISO/IEC 2382 happens to agree with me.
> The problem was that, at the time the term "octet" was coined,
> the size of a byte (measured in bits) varied between different
> computers, and sometimes on the same computer. When people
> starting getting serious about making computers talk to one
> another, this became an issue: hence octet to have standard
> nomenclature.
>
>>A computer might have 64k bytes of
>>RAM, but normally I wouldn't (and I think normally other people
>>wouldn't) say that a computer has 64k octets of RAM.
>
> Some would, though it may sound a bit odd.
Agreed. "64k bytes" is certainly more common, but "64k octets"
means essentially the same thing while being more specific.
Also, the "k" suffix formally means 1000, but is often used to mean
1024, which is why we have "Ki", "kibi" to denote a power of two
explicitly.
[...]]
> At this point, the term "byte" has been standardized by several
> different bodies (IEC, ISO) to be synonymous with octet. The
> continued use of "octet" by organizations like the IETF is
> mostly a legacy curiosity.
Has it? The ISO C and C++ standards certainly do not use "byte"
to mean exactly 8 bits. ISO/IEC 2382 says:
byte
string that consists of a number of bits, treated as a unit, and
usually representing a character or a part of a character
Note 1 to entry: The number of bits in a byte is fixed for a given
data processing system.
Note 2 to entry: The number of bits in a byte is usually 8.
and
octet
8-bit byte
byte that consists of eight bits
<https://www.iso.org/obp/ui/#iso:std:iso-iec:2382:ed-1:v2:en>
The latter implies that you can't have octets on a system with,
say, 16-bit bytes, which doesn't match what I would have expected.
I would think it would be reasonable to say that a system with
16-bit bytes has, say, 32k bytes or 64k octets of memory. But C
doesn't use the word "octet", so this is at best marginally topical.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-15 03:31 +0200 |
| Message-ID | <10u5t1q$34b89$10@dont-email.me> |
| In reply to | #398973 |
On 2026-05-15 01:33, Keith Thompson wrote: > cross@spitfire.i.gajendra.net (Dan Cross) writes: > [...] > >> At this point, the term "byte" has been standardized by several >> different bodies (IEC, ISO) to be synonymous with octet. The >> continued use of "octet" by organizations like the IETF is >> mostly a legacy curiosity. > > Has it? The ISO C and C++ standards certainly do not use "byte" > to mean exactly 8 bits. ISO/IEC 2382 says: > > byte > > string that consists of a number of bits, treated as a unit, and > usually representing a character or a part of a character > > Note 1 to entry: The number of bits in a byte is fixed for a given > data processing system. > > Note 2 to entry: The number of bits in a byte is usually 8. > > and > > octet > > 8-bit byte > > byte that consists of eight bits > > <https://www.iso.org/obp/ui/#iso:std:iso-iec:2382:ed-1:v2:en> > > The latter implies that you can't have octets on a system with, > say, 16-bit bytes, which doesn't match what I would have expected. > I would think it would be reasonable to say that a system with > 16-bit bytes has, say, 32k bytes or 64k octets of memory. But C > doesn't use the word "octet", so this is at best marginally topical. I've seen octets used in ITU-T standards (called "recommendations") earlier than in ISO standards (who often borrowed ITU-T standards later under their label as an International Standard). Specifically in context of the ASN.1 definition in the 1980's (IIRC), specifically in ITU-T X.209 (which got later replaced by X.680, and X.690 for BER). I'm too lazy to "grep" the tons of the respective ITU-T papers, but Google(AI) confirms my memories when it says: | An octet, defined as a sequence of exactly 8 bits, is commonly | defined in several ITU-T (International Telecommunication Union - | Telecommunication Standardization Sector) standards, particularly | within the X-series for Open Systems Interconnection (OSI) and ASN.1 | encoding. | Key ITU-T standards that define or rely on the definition| of an | octet include: | * ITU-T Rec. X.680 (ISO/IEC 8824-1): Defines the Abstract | Syntax Notation One (ASN.1) basic notation, where an "octet" | is fundamentally defined as an 8-bit unit. | * ... Janis
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-15 01:56 +0000 |
| Message-ID | <10u5uh3$k88$1@reader1.panix.com> |
| In reply to | #398973 |
In article <10u5m4m$uo0d$3@kst.eternal-september.org>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <86pl2yi0n3.fsf@linuxsc.com>,
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>[...]
>>>My main point is that "byte" and "octet" are talking about
>>>different kinds of things.
>>
>> Not really. It has always been understood to refer to the same
>> kind of thing that "byte" refers to.
>
>I agree, at least for the way I understand the terms. For me,
>"octet" and "byte" refer to the same kind of thing. The difference
>is that an "octet" is specifically 8 bits, and a "byte" is a
>fundamental unit of storage for a given system (commonly 8 bits).
>ISO/IEC 2382 happens to agree with me.
Indeed; Werner Buchholz created the term "byte" while working on
the IBM Stretch computer. This letter, from a 1977 issue of
BYTE magazine (bit on the nose, honestly) claims it was 21 years
old that year:
https://archive.org/details/byte-magazine-1977-02/page/n145/mode/1up
The letter says that initially, byte sizes ranged from 1 to 6
bytes, but were extended to 8 bits in late 1956. The IBM 360
used the same byte and word sizes as the Stretch, but fixed
bytes at 8 bits.
>> The problem was that, at the time the term "octet" was coined,
>> the size of a byte (measured in bits) varied between different
>> computers, and sometimes on the same computer. When people
>> starting getting serious about making computers talk to one
>> another, this became an issue: hence octet to have standard
>> nomenclature.
>>
>>>A computer might have 64k bytes of
>>>RAM, but normally I wouldn't (and I think normally other people
>>>wouldn't) say that a computer has 64k octets of RAM.
>>
>> Some would, though it may sound a bit odd.
>
>Agreed. "64k bytes" is certainly more common, but "64k octets"
>means essentially the same thing while being more specific.
Yes. I understand that "octet" is preferred in French, enough
so that I read it was the, "French word for byte." Not knowing
French, I don't know if that's true.
However, this cute story from Bob Bemer suggests he disliked the
term "byte" and greaterly preferred "octet," pushing it when he
was directly of software at Bull, in France, in the mid-1960s:
https://web.archive.org/web/20170403130829/http://www.bobbemer.com/BYTE.HTM
>Also, the "k" suffix formally means 1000, but is often used to mean
>1024, which is why we have "Ki", "kibi" to denote a power of two
>explicitly.
Yes. K, M, G, etc, have always been the SI indicators for
powers of 10, not powers of 2. The "Ki", "Mi", "Gi", etc, forms
are (as I understand it) relatively new.
>[...]]
>
>> At this point, the term "byte" has been standardized by several
>> different bodies (IEC, ISO) to be synonymous with octet. The
>> continued use of "octet" by organizations like the IETF is
>> mostly a legacy curiosity.
>
>Has it?
Yes. IEC 80000-13 declares them to be synonyms.
>The ISO C and C++ standards certainly do not use "byte"
>to mean exactly 8 bits.
Indeed. I don't blame them. I suspect there are some DSP chips
or weird one-off processors with oddball byte sizes, even now.
>ISO/IEC 2382 says:
>
> byte
>
> string that consists of a number of bits, treated as a unit, and
> usually representing a character or a part of a character
>
> Note 1 to entry: The number of bits in a byte is fixed for a given
> data processing system.
>
> Note 2 to entry: The number of bits in a byte is usually 8.
>
>and
>
> octet
>
> 8-bit byte
>
> byte that consists of eight bits
>
><https://www.iso.org/obp/ui/#iso:std:iso-iec:2382:ed-1:v2:en>
>
>The latter implies that you can't have octets on a system with,
>say, 16-bit bytes, which doesn't match what I would have expected.
I suspect that ambiguity is unintentional.
>I would think it would be reasonable to say that a system with
>16-bit bytes has, say, 32k bytes or 64k octets of memory. But C
>doesn't use the word "octet", so this is at best marginally topical.
I wonder. For word oriented systems, it was common to describe
memory in terms of words (e.g., "the KL-10B processor with
extended addressing supports a maximum of 4 MW of memory...").
Similarly, even for byte-addressed machines, like the PDP-11,
memory capacities were often described in terms of 16-bit words
("this machine has 256 KW of memory", aka, 512 KB). [Of course,
these machines all predate common use if the "Ki" and "Mi"
units). Anyway, there is some precedent for using the machine
specific sizes in discussion, though I agree generally that
using octets makes sense in this context.
None of this has much to do with C, though, as you point out.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-14 19:12 -0700 |
| Message-ID | <10u5ver$uo0d$11@kst.eternal-september.org> |
| In reply to | #398991 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <10u5m4m$uo0d$3@kst.eternal-september.org>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
>>> At this point, the term "byte" has been standardized by several
>>> different bodies (IEC, ISO) to be synonymous with octet. The
>>> continued use of "octet" by organizations like the IETF is
>>> mostly a legacy curiosity.
>>
>>Has it?
>
> Yes. IEC 80000-13 declares them to be synonyms.
Interesting. It's odd that ISO/IEC 2382 and ISO/IEC 80000-13
disagree with each other.
<https://www.iso.org/standard/87648.html>
IEC 80000-13:2025 Quantities and units
Part 13: Information science and technology
I'm not going to spend 115 Swiss Francs (currently
146.39 USD) to get a copy.
If you have a copy, can you quote the relevant wording?
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-15 02:20 +0000 |
| Message-ID | <10u5vtu$abr$1@reader1.panix.com> |
| In reply to | #398995 |
In article <10u5ver$uo0d$11@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >> In article <10u5m4m$uo0d$3@kst.eternal-september.org>, >> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>>cross@spitfire.i.gajendra.net (Dan Cross) writes: >[...] >>>> At this point, the term "byte" has been standardized by several >>>> different bodies (IEC, ISO) to be synonymous with octet. The >>>> continued use of "octet" by organizations like the IETF is >>>> mostly a legacy curiosity. >>> >>>Has it? >> >> Yes. IEC 80000-13 declares them to be synonyms. > >Interesting. It's odd that ISO/IEC 2382 and ISO/IEC 80000-13 >disagree with each other. > ><https://www.iso.org/standard/87648.html> >IEC 80000-13:2025 Quantities and units >Part 13: Information science and technology > >I'm not going to spend 115 Swiss Francs (currently >146.39 USD) to get a copy. > >If you have a copy, can you quote the relevant wording? Sure. |The specified data elements depend on the organization of the |storage device, for example, binary elements (also called |"bits"), octets (also called "bytes"), words of a given |number of bits, blocks. A subscript referring to a specified |data element can be added to the symbol. | | ... | |When used to express a storage capacity or an equivalent binary |storage capacity, the bit and the octet (or byte) may be |combined with SI prefixes or prefixes for binary multiples. | |In English, the name "byte", symbol B, is used as a synonym |for "octet". Here, "byte" means an eight-bit byte. However, |"byte" has been used for numbers of bits other than eight. To |avoid the risk of confusion, it is strongly recommended that |the name "byte" and the symbol B be used only for eight-bit |bytes. Note that they do acknowledge the historical usage, but it's clear they are defining "byte" and "octet" to mean the same thing. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-05-15 13:44 +0200 |
| Message-ID | <10u70uk$5ntt$1@dont-email.me> |
| In reply to | #398991 |
On 15/05/2026 03:56, Dan Cross wrote:
> In article <10u5m4m$uo0d$3@kst.eternal-september.org>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>> In article <86pl2yi0n3.fsf@linuxsc.com>,
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> [...]
>> Also, the "k" suffix formally means 1000, but is often used to mean
>> 1024, which is why we have "Ki", "kibi" to denote a power of two
>> explicitly.
>
> Yes. K, M, G, etc, have always been the SI indicators for
> powers of 10, not powers of 2. The "Ki", "Mi", "Gi", etc, forms
> are (as I understand it) relatively new.
>
They are also very rarely used, IME. People who care about these things
already know that 1 KB is 1024 bytes, not 1000 bytes. (There was a big
to-do about disk sizes a number of years ago, where disks were marketed
using 1000-based units but users expected 1024-based units.)
>> [...]]
>>
>>> At this point, the term "byte" has been standardized by several
>>> different bodies (IEC, ISO) to be synonymous with octet. The
>>> continued use of "octet" by organizations like the IETF is
>>> mostly a legacy curiosity.
>>
>> Has it?
>
> Yes. IEC 80000-13 declares them to be synonyms.
>
>> The ISO C and C++ standards certainly do not use "byte"
>> to mean exactly 8 bits.
>
> Indeed. I don't blame them. I suspect there are some DSP chips
> or weird one-off processors with oddball byte sizes, even now.
>
There certainly are. But on these systems, IME no one ever uses the
word "byte" to refer to anything other than 8 bits. Sizes are generally
given explicitly, or refer to "unsigned char" (which will be perhaps
12-bit or 16-bit), or sometimes a more generic term like "word" will be
used. When you read the manual for a CHAR_BIT 16 compiler for a DSP (at
least for the two that I have read), you won't see the term "byte"
referring to anything other than 8 bits.
>
>> I would think it would be reasonable to say that a system with
>> 16-bit bytes has, say, 32k bytes or 64k octets of memory. But C
>> doesn't use the word "octet", so this is at best marginally topical.
>
> I wonder. For word oriented systems, it was common to describe
> memory in terms of words (e.g., "the KL-10B processor with
> extended addressing supports a maximum of 4 MW of memory...").
That is the norm in the embedded world. While it is mostly just DSP's
that have char greater than 8 bits, it is not uncommon to have flash or
other program memory that is wider than 8 bits. An AVR microcontroller
might be said to have 16 kW or 32 kB of memory, where each word of flash
is 16 bits. For PIC microcontrollers, kW is common since each word of
program memory might be 12, 14 or 16 bits according to the family.
(These are Harvard architecture devices - data memory is entirely
separate from code memory.)
> Similarly, even for byte-addressed machines, like the PDP-11,
> memory capacities were often described in terms of 16-bit words
> ("this machine has 256 KW of memory", aka, 512 KB). [Of course,
> these machines all predate common use if the "Ki" and "Mi"
> units). Anyway, there is some precedent for using the machine
> specific sizes in discussion, though I agree generally that
> using octets makes sense in this context.
>
> None of this has much to do with C, though, as you point out.
>
> - Dan C.
>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-31 14:43 -0700 |
| Message-ID | <86pl2bdzll.fsf@linuxsc.com> |
| In reply to | #398973 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > cross@spitfire.i.gajendra.net (Dan Cross) writes: > >> In article <86pl2yi0n3.fsf@linuxsc.com>, >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > > [...] > >>> My main point is that "byte" and "octet" are talking about >>> different kinds of things. >> >> Not really. It has always been understood to refer to the same >> kind of thing that "byte" refers to. > > I agree, at least for the way I understand the terms. For me, > "octet" and "byte" refer to the same kind of thing. [...] An octet is a quantity of information. An octet can be stored in a computer memory, transmitted over a network wire, shown on a movie screen, sent in a text message, or written on a piece of paper. In C, a byte is an addressable unit of data storage large enough to hold any member of the basic character set of the execution environment. There was slightly different wording in the original C standard, but since C99 the definition has stayed the same up to the present (specifically, n3220). If someone wants to use the term "byte" in a C program to mean something other than the above definition, there is nothing stopping them from doing so, but it comes with a risk of ambiguity and confusion. A safer path is to follow the suggestion given by many people familiar with the C standard, which is to use terms defined in the C standard in the same way that they are used in the standard.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-14 15:26 +0000 |
| Message-ID | <NQlNR.734912$1OHe.386488@fx09.iad> |
| In reply to | #398919 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >On 2026-05-13 20:00, Tim Rentsch wrote: >> >> There is another difference worth noting. A byte is a unit of >> storage, whereas octet is a measure of information. The word >> byte is inherently about memory; the word octet is inherently >> about value (eight bits of information). For this reason too >> the name 'octet' is a better choice for a type name than 'byte'. > >Well, I have a slightly different view; I suppose it's cultural. > >I often see, specifically from the Anglo-American culture, that >they talk about, say, "8 bits"; For many older Americans, 8 bits is a dollar.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-11 11:22 -0700 |
| Message-ID | <10tt6of$1adha$5@kst.eternal-september.org> |
| In reply to | #398722 |
scott@slp53.sl.home (Scott Lurndal) writes:
[...]
> On at least one system with a working C compiler,
> a byte is 9 bits, not 8. If I wanted an 8-bit datum
> on that system, I'd have to use uint8_t.
>
> (Now, I haven't used that system in decades, but it
> still exists and powers a large fraction of the
> worlds airline reservation and operational functions).
[...]
What system is that?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-05-11 19:20 +0000 |
| Message-ID | <%ZpMR.617788$9qO5.459988@fx12.iad> |
| In reply to | #398744 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>[...]
>> On at least one system with a working C compiler,
>> a byte is 9 bits, not 8. If I wanted an 8-bit datum
>> on that system, I'd have to use uint8_t.
>>
>> (Now, I haven't used that system in decades, but it
>> still exists and powers a large fraction of the
>> worlds airline reservation and operational functions).
>[...]
>
>What system is that?
Univac 2200 (Unisys Clearpath 2200[*])
[*] Mostly emulated, I don't know if any of the CMOS
processors are still running.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-05-11 13:51 -0700 |
| Message-ID | <10ttfhb$1dsaq$2@dont-email.me> |
| In reply to | #398722 |
On 5/11/2026 7:45 AM, Scott Lurndal wrote: > kalevi@kolttonen.fi (Kalevi Kolttonen) writes: >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> In almost all cases where uint8_t >>> might be used, unsigned char works just as well. >> >> Why "almost"? Where is the difference if any? >> >> As far as I know, ISO guarantees that >> sizeof(unsigned char) is always 1 byte. > > On at least one system with a working C compiler, > a byte is 9 bits, not 8. If I wanted an 8-bit datum > on that system, I'd have to use uint8_t. > > (Now, I haven't used that system in decades, but it > still exists and powers a large fraction of the > worlds airline reservation and operational functions). > >> >> And operations on unsigned char are well defined, >> including wrap-around. So I fail to see any >> difference between unsigned char and uint8_t. > > Indeed. Although from my perspective, the use of the > stdint types clearly documents the programmers > intent, whereas a typedef such as BYTE or WORD > is inherently ambiguous and would require a programmer > to look up the definition of such types in the > application to determine the original programmers intent. Gotta love uintptr_t. Still need to see how big it is. Can call that a word. ;^)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-05-09 15:32 -0700 |
| Message-ID | <10tocmt$3vl63$1@kst.eternal-september.org> |
| In reply to | #398594 |
Bart <bc@freeuk.com> writes:
[...]
> FBC seems to include a working gcc.exe program.
>
> If I do 'fib64 -R hello.bas' then it produces the C file below.
FBC (FreeBasic) may or may not use C as an intermediate language.
I don't see why it matters, unless you're working with FBC.
> (You can also see from this that /nobody/ likes stdint.h types, even
> though standardised from C99 which also introduced 'long long' used
> here. That is another bugbear. Oh, I forgot, my criticism is not not
> valid.)
This specific criticism is not valid because it's inaccurate.
Your claim that "nobody" likes <stdint.h> types is blatantly and
demonstrably false. You appear to have reached this laughable
conclusion based on the fact that one specific implementation of
one language uses something else.
It's not your credentials that make your criticism invalid.
It's the falsehoods.
>>> Programs however move on. If I download it now, then it does bundle
>>> something called 'gcc.exe', but it is a stub: it can load C files, but
>>> it is missing 'cc1'.
>>
>> This doesn't seem particularly relevant to anything.
>
> We're drifting from my point, which is that C is in that small
> category, of a deceptively simple and malleable language that would be
> a good fit for a target language.
>
> I'm saying mine would be in that group, which is my I'm doing
> comparisons with Pascal or Ada which have been brought up.
It may well be true that your language would be a good fit for
this purpose. That has nothing to do with C, which is the topic
of this newsgroup. You know how to find comp.lang.misc (which,
as it happens, I follow).
[...]
> If you disagree with an opinion of mine, would be make it any
> difference if I knew the C standard inside out? You are hardly going
> to change your mind.
It might, depending on the circumstances.
> Suppose I proposed for example that C should deprecate, then ban, the
> ability to write:
>
> A[i]
> B[i][j]
>
> respectively as:
>
> i[A]
> j[i[A]]
>
> (The last one is a little mind-blowing, as it turns one 2D array
> access - two consecutive 1D accesses) into two /nested/ 1D accesses.)
>
> Basically, it would mean addition between pointers and integers would
> not be commutative: P + i, but not i + P.
>
> You will either agree with this or not. But I can't see that it
> requires any deep knowledge of the standard to make such a proposal,
> or why somebody would require that of me in order to even consider it.
It doesn't. You don't need to have a deep understanding of the
entire standard to be able to comment on specific aspects of it.
That's just your fantasy of what you think we're telling you.
As it happens, I would agree with that suggestion. As it happens,
the committee also agrees. The latest C2Y standard draft, N3854,
says "A postfix expression followed by an expression in square
brackets [] is a subscripted designation of an element of an
array. The use of this operator with the first operand of integer
type is an obsolescent feature." (I'll skip over the distinction
between "deprecated" and "obsolescent".)
Suggesting that index[array] should be deprecated is reasonable.
Whining about the meaning of "undefined behavior" while explictly
refusing to even read the definition of that term is not.
>>> There are reasonable adjustments you need to make to switch languages,
>>> and there are unreasonables ones, such as needing to become a guru in
>>> the new language.
>> It strikes me that you need to know the language if you want to
>> use and discuss it.
>
> You want EVERYBODY who uses C to know the standard in as much depth as
> KT, JK and TR? (Maybe a few others too but they don't seem that
> bothered about it.)
No. Again, that's your fantasy intepretation. Your conceptual leap to
"you need to know the language" to "EVERYBODY" (not just you) needs to
know the standard in depth is breathtaking.
If you want to discuss details of a language, you should understand
those details. In the case of array indexing, you've already
demonstrated reasonable understanding -- not by telling us that
you've written a C compiler, but by talking about the feature here,
mostly correctly.
> (I've just tried the above proposal in my C compiler. It took half a
> minute to find where I had to comment out 4 lines to make it work.
The difficulty of making a change in one compiler has very little
to do with the effort needed to make a change in the language.
> As it happens, because this ability has been there a long time, some
> programs use it, for example from sqlite:
>
> nPage = nPageHeader = get4byte(28+(u8*)pPage1->aData);
>
> So this change is not going to happen, and people will continue
> writing quirky things like 3["ABCDEF"] just for the hell of it.
>
> This is the story of C.)
You were talking about the indexing operator. There is no indexing
operator in that code.
The ability to write index[array] rather than array[index] is
obsolescent in C2Y. The ability to write index+array rather than
array+index is not, and I don't believe anyone has proposed that it
should be. Array indexing and pointer arithmetic are closely tied
together, though the C2Y draft decouples them when the operand is
of array type.
[...]
Bart, the following is directed to people who are interested in
the standard.
In C23 and earlier, the operands of the [] operator must be an
integer and a pointer. The pointer operand is commonly the result
of the "decay" of an array expression, such as the name of an
array object.
In the N3854 draft of C2y, the rules are the same when one of the
operands is a pointer; E1[E2] is equivalent to *((E1)+(E2)) and is
an lvalue. If one operand is of array type, it does not decay, and
the result is described in terms of elements of the array (object
or value). The array operand is not required to be an lvalue.
(This reduces the need for "temporary lifetime". I don't know
whether it makes it unnecessary in all cases.)
In editions of the C standard up to and including C17, there are
three contexts in which array-to-pointer does not occur: when the
expression is the operand of sizeof, when it's the operand of unary
"&", or when it's a string literal used to initialize an array
object. C23 adds another case, an operand of the typeof operators.
C2Y adds two more cases, an operand of the _Countof operator and
an operand of the array subscripting operator.
(The N1570 draft of C11 incorrectly included the _Alignof operator,
which can only be applied to a parenthesized type name.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-10 01:35 +0000 |
| Message-ID | <10tond1$ev1$1@reader1.panix.com> |
| In reply to | #398594 |
In article <10tnmk6$3os5b$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 09/05/2026 16:18, Dan Cross wrote: >> In article <10tn3so$3j8hc$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >> [snip] >(You can also see from this that /nobody/ likes stdint.h types, even >though standardised from C99 which also introduced 'long long' used >here. That is another bugbear. Oh, I forgot, my criticism is not not valid.) Funny, I was just talking to some folks about this, who lamented that it hadn't been done a decade sooner. It would have saved a lot of pain. >> This doesn't seem particularly relevant to anything. > >We're drifting from my point, which is that C is in that small category, >of a deceptively simple and malleable language that would be a good fit >for a target language. > >I'm saying mine would be in that group, which is my I'm doing >comparisons with Pascal or Ada which have been brought up. Apparently you feel your language fits into a category that could be categorized by the "level" at which you program in it. Ok. I don't see what that has to do with anything. >> Why would it? C compilers are ubiquitous. > >For the major platforms, so are compilers for dozens of languages. So what? >> You don't care about C _as it is defined_. You only care about >> how _you think it should work based on your intuition_. Your >> incredulity at its definition not matching your expectations has >> no bearing on anything at all. > >If you disagree with an opinion of mine, would be make it any difference >if I knew the C standard inside out? You are hardly going to change your >mind. The point is that if you understood the language better, your opinion would actually be worth agreeing or disagreeing with. As it is, since you do Not know the language particularly well, your opinion carries little weight; certainly not enough to merit significant discussion. It's really not that hard to figure out what all of this means, by the way. People (plural because, apparently, I am not the only one) just don't find your opinions worth all that much. >Suppose I proposed for example that C should deprecate, then ban, the >ability to write: > > A[i] > B[i][j] > >respectively as: > > i[A] > j[i[A]] > >(The last one is a little mind-blowing, as it turns one 2D array access >- two consecutive 1D accesses) into two /nested/ 1D accesses.) I haven't really given it much thought. This is an historical artifact that came from B via "nb", where pointers were denoted as `A[]`, so A[i] = A + i = i + A = i[A] because arithmetic in the integers is commutative, and B was word-oriented. It's a cute parlor trick, surprising to a few who haven't looked closely at the history, but no deep mystery. I would not mourn if it were removed from the language. https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html >Basically, it would mean addition between pointers and integers would >not be commutative: P + i, but not i + P. No, it would not mean that. It would merely mean that the syntax for array accesses was divorced from its early history. >You will either agree with this or not. But I can't see that it requires >any deep knowledge of the standard to make such a proposal, or why >somebody would require that of me in order to even consider it. In observing your behavior, this fits the pattern of being about the place where your argument breaks down. Chesterson's fence applies, of course, but I do not think you are not wrong to question whether that surprising syntax should endure. But it is your conclusion about communitivity of pointer arithmetic that fails. You go from something that is, at least, open to reasonable debate, and draw a specious conclusion that you then assert as fact. >>> There are reasonable adjustments you need to make to switch languages, >>> and there are unreasonables ones, such as needing to become a guru in >>> the new language. >> >> It strikes me that you need to know the language if you want to >> use and discuss it. > >You want EVERYBODY who uses C to know the standard in as much depth as >KT, JK and TR? (Maybe a few others too but they don't seem that bothered >about it.) I did not say that. You presented a straw man. I merely countered with what I feel is reasonable. (For the record, your response is another strawman.) If one wants to use a programming language, then it is axiomatic that one must know that language. It does not follow that one must necessarily be a total expert, or have internalized the standard to the degree that one is capable of citing chapter and verse for any given construct without the aid of references. I don't know what your definition of "guru" is, but lots of people who successfully use a language have a good but imperfect working knowledge of it, and know to use references, ask someone more knowledgable than themselves, or avail themselves of other resources when they are unsure of something about it. The critical difference between you and those programmers is that they are _open_ to learning new things. There are many aspects of C that are (at a minimum) surprising to the uninitiated; this is known. On learning about them they may have a subjectively negative reaction; they may express dislike. But there's a big difference between disliking a thing and disregarding it. One might find it silly to stop at a traffic signal in the middle of the night, when it is easy to see there is no other traffic and obviously no else is nearby. But if you decide not to stop, don't be upset when a cop pulls you over and gives you a ticket. >(I've just tried the above proposal in my C compiler. It took half a >minute to find where I had to comment out 4 lines to make it work. And did you break commutative arithmetic on pointers when you were at it? >As it happens, because this ability has been there a long time, some >programs use it, for example from sqlite: > > nPage = nPageHeader = get4byte(28+(u8*)pPage1->aData); That's not using subscripting at all. >So this change is not going to happen, and people will continue writing >quirky things like 3["ABCDEF"] just for the hell of it. > >This is the story of C.) No, it's not. This appears to be another of your misunderstandings. There are reasons to dislike the semantic quirk of array subscribes inherited from nb. But once again, your conclusion is specious. >Output from fbc64 -R hello.bas: >----------------------------- > [snip] >Looks like C to me! Looks like a non-sequitur to me. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-05-10 06:19 +0200 |
| Message-ID | <10tp104$1l93l$20@dont-email.me> |
| In reply to | #398619 |
On 2026-05-10 03:35, Dan Cross wrote: > In article <10tnmk6$3os5b$1@dont-email.me>, Bart <bc@freeuk.com> wrote: [...] >> Suppose I proposed for example that C should deprecate, then ban, the >> ability to write: >> >> A[i] >> B[i][j] >> >> respectively as: >> >> i[A] >> j[i[A]] >> >> (The last one is a little mind-blowing, as it turns one 2D array access >> - two consecutive 1D accesses) into two /nested/ 1D accesses.) > > I haven't really given it much thought. This is an historical > artifact that came from B via "nb", where pointers were denoted > as `A[]`, so A[i] = A + i = i + A = i[A] because arithmetic in > the integers is commutative, and B was word-oriented. > > It's a cute parlor trick, surprising to a few who haven't looked > closely at the history, but no deep mystery. I would not mourn > if it were removed from the language. > > https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html > >> Basically, it would mean addition between pointers and integers would >> not be commutative: P + i, but not i + P. > > No, it would not mean that. It would merely mean that the > syntax for array accesses was divorced from its early history. > >> You will either agree with this or not. But I can't see that it requires >> any deep knowledge of the standard to make such a proposal, or why >> somebody would require that of me in order to even consider it. > > In observing your behavior, this fits the pattern of being about > the place where your argument breaks down. Chesterson's fence > applies, of course, but I do not think you are not wrong to > question whether that surprising syntax should endure. But it > is your conclusion about communitivity of pointer arithmetic > that fails. You go from something that is, at least, open to > reasonable debate, and draw a specious conclusion that you then > assert as fact. There's a truth in Chesterson's Fence. But I have my doubts when applied for the case here; basically asking Bart to inform himself about the original rationales for that option/rule or "fence". It would be fine if we'd have a source documenting specifically this (and all debatable) feature's rationale. It could be that there is somewhere such a (list of) rationale(s) - I'm not aware of one. It could of course also be just an obvious property that most people just recognize. In that light I wouldn't expect anyone criticizing the 'P+i' symmetry to make any research in the wild first. A formulated question or criticism (that I'd consider valid) is fine per se. A rationale might not even exist; design may have been by inheriting other bad (or deliberate primitive) design, it may have been just a stupid idea, a personal preference, whatever - usually we don't know. If I come from other languages - and not inferring the 'int' commutativity to the case here - I'd see two different types, a pointer and an integer, and I see an _asymmetric_ (non- commutative) operator in between; if the operator would have been '@' instead, say p @ i, the presumed commutativity would be less obtrusive. In short; what I was trying to say is that Chesterson's Fence is probably a disproportionate, if not badly fitting, cannon. Personally I'm not much surprised any more by "C" design-decisions. We can observe the enduring, often hard (and sometimes impossible), way to fix or enhance quality of legacy issues by the standards' evolution. And until something gets available we use "C" as it is. I'm writing my "C" code, if possible, without kludges or deliberate swap of pointer and integer as shown above; that symmetry doesn't hinder me. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-10 12:52 +0000 |
| Message-ID | <10tpv2r$ivo$1@reader1.panix.com> |
| In reply to | #398623 |
In article <10tp104$1l93l$20@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>On 2026-05-10 03:35, Dan Cross wrote:
>> [snip]
>> In observing your behavior, this fits the pattern of being about
>> the place where your argument breaks down. Chesterson's fence
>> applies, of course, but I do not think you are not wrong to
>> question whether that surprising syntax should endure. But it
>> is your conclusion about communitivity of pointer arithmetic
>> that fails. You go from something that is, at least, open to
>> reasonable debate, and draw a specious conclusion that you then
>> assert as fact.
>
>There's a truth in Chesterson's Fence. But I have my doubts when
>applied for the case here; basically asking Bart to inform himself
>about the original rationales for that option/rule or "fence".
My point is that one should seek to understand _why_ something
is the way that it is before unilaterally deciding that changing
it is the best thing to do.
In this case, I gave him a reference to the paper Dennis Ritchie
gave on the history of C, which discusses the origin: in "nb",
one declared a pointer to e.g. `int` as `int ptr[];`. In B, all
of the addressable memory address space was considered an
"array"; the square bracket subscript notation was merely
syntactic sugar. The "Critique" section of that paper also has
on this notion.
|Moreover, some rules designed to ease early transitions
|contributed to later confusion. For example, the empty square
|brackets in the function declaration
|
| int f(a) int a[]; { ... }
|
|are a living fossil, a remnant of NB's way of declaring a
|pointer; a is, in this special case only, interpreted in C as a
|pointer. The notation survived in part for the sake of
|compatibility, in part under the rationalization that it would
|allow programmers to communicate to their readers an intent to
|pass f a pointer generated from an array, rather than a
|reference to a single integer. Unfortunately, it serves as
|much to confuse the learner as to alert the reader.
(https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html)
I think one can take from this that the designers of the
language regarded this as something of an embarrassing accident.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-10 11:49 +0100 |
| Message-ID | <10tpnru$a6kp$1@dont-email.me> |
| In reply to | #398619 |
On 10/05/2026 02:35, Dan Cross wrote: > In article <10tnmk6$3os5b$1@dont-email.me>, Bart <bc@freeuk.com> wrote: > One might find it silly to stop at a traffic signal in the > middle of the night, when it is easy to see there is no other > traffic and obviously no else is nearby. But if you decide not > to stop, don't be upset when a cop pulls you over and gives you > a ticket. Yes, and you don't need to be an expert in highways and traffic management to be able to complain about it. Just a user. Or maybe you are a visitor from another country (eg. Netherlands) where they have a more sensible approach (for example, traffic lights switch to flashing amber at night so that drivers can make their own decisions). > >> (I've just tried the above proposal in my C compiler. It took half a >> minute to find where I had to comment out 4 lines to make it work. > > And did you break commutative arithmetic on pointers when you > were at it? Yes, that's exactly how it works, since A[i] is reduced to *(A + i). I commented out the bit of code that swapped operands when the pointer was on the right, as in (i + A). >> As it happens, because this ability has been there a long time, some >> programs use it, for example from sqlite: >> >> nPage = nPageHeader = get4byte(28+(u8*)pPage1->aData); > > That's not using subscripting at all. In C, you can write i[A] /because/ it is exactly equivalent to *(i + A), and pointer addition (between T* and int) is commutative. >> So this change is not going to happen, and people will continue writing >> quirky things like 3["ABCDEF"] just for the hell of it. >> >> This is the story of C.) > > No, it's not. > > This appears to be another of your misunderstandings. What is the misunderstanding? > There are > reasons to dislike the semantic quirk of array subscribes > inherited from nb. But once again, your conclusion is specious. There are cruder ways to stop people writing i[A] whilst still allowing (i + P). But it would be more of a hack. (In my languages, i + P is simply not allowed, while A[i] is not reduced to pointer arithmetic at the AST level. For one thing, arrays have an arbitrary lower bound so the mapping isn't as simple.) > >> Output from fbc64 -R hello.bas: >> ----------------------------- >> [snip] >> Looks like C to me! > > Looks like a non-sequitur to me. You suggested FBC didn't transpile to C. I actually tried it to find > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-10 12:59 +0000 |
| Message-ID | <10tpvfl$ivo$2@reader1.panix.com> |
| In reply to | #398633 |
In article <10tpnru$a6kp$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 10/05/2026 02:35, Dan Cross wrote: >> In article <10tnmk6$3os5b$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >>> [snip] >>> (I've just tried the above proposal in my C compiler. It took half a >>> minute to find where I had to comment out 4 lines to make it work. >> >> And did you break commutative arithmetic on pointers when you >> were at it? > >Yes, I was asking rhetorically. >that's exactly how it works, since A[i] is reduced to *(A + i). Yes, we're all aware of this. The point is that you are proposing a change but then declaring it impossible because you don't want to make another, related change. >I >commented out the bit of code that swapped operands when the pointer was >on the right, as in (i + A). I suppose one needs to explicitly say that that is probably not the only way to express the desired change. >>> As it happens, because this ability has been there a long time, some >>> programs use it, for example from sqlite: >>> >>> nPage = nPageHeader = get4byte(28+(u8*)pPage1->aData); >> >> That's not using subscripting at all. > >In C, you can write i[A] /because/ it is exactly equivalent to *(i + A), >and pointer addition (between T* and int) is commutative. We know. >>> So this change is not going to happen, and people will continue writing >>> quirky things like 3["ABCDEF"] just for the hell of it. >>> >>> This is the story of C.) >> >> No, it's not. >> >> This appears to be another of your misunderstandings. > >What is the misunderstanding? That you can change two things at one time. >> There are >> reasons to dislike the semantic quirk of array subscribes >> inherited from nb. But once again, your conclusion is specious. > >There are cruder ways to stop people writing i[A] whilst still allowing >(i + P). But it would be more of a hack. Perhaps in your compiler, you might consider it so. >(In my languages, i + P is simply not allowed, while A[i] is not reduced >to pointer arithmetic at the AST level. For one thing, arrays have an >arbitrary lower bound so the mapping isn't as simple.) We're talking about C, not your language. >>> Output from fbc64 -R hello.bas: >>> ----------------------------- >>> [snip] >>> Looks like C to me! >> >> Looks like a non-sequitur to me. > >You suggested FBC didn't transpile to C. I actually tried it to find I suggested it was irrelevant. I honestly don't care what it generates. I fail to see how that is at all related to C, other than FBC (apparently) using C as an intermediate representation. - Dan C.
[toc] | [prev] | [next] | [standalone]
Page 22 of 37 — ← Prev page 1 … 20 21 [22] 23 24 … 37 Next page →
Back to top | Article view | comp.lang.c
csiph-web