Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #394650 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2025-10-22 09:45 -0300 |
| Last post | 2025-11-24 11:52 -0600 |
| Articles | 20 on this page of 248 — 14 participants |
Back to article view | Back to comp.lang.c
_BitInt(N) Thiago Adams <thiago.adams@gmail.com> - 2025-10-22 09:45 -0300
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-10-22 11:42 -0500
Re: _BitInt(N) Thiago Adams <thiago.adams@gmail.com> - 2025-10-22 14:23 -0300
Re: _BitInt(N) Thiago Adams <thiago.adams@gmail.com> - 2025-10-22 14:25 -0300
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-10-22 14:03 -0500
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-23 12:46 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-23 13:32 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-23 13:59 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-23 17:06 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 10:29 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 11:17 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 05:12 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 14:49 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 17:23 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-25 07:56 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-29 19:36 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-30 11:56 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-30 15:50 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 05:06 -0800
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-24 15:27 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 14:51 +0100
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-29 22:06 +0100
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-29 17:10 -0600
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-29 17:32 -0800
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-30 11:46 +0200
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 11:12 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-30 12:07 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-23 17:55 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-23 14:38 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 00:30 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 12:17 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-24 13:44 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 15:02 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 12:31 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 05:33 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 14:41 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 16:46 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 15:41 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 18:35 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 21:26 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 22:27 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 18:10 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-25 21:25 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-25 21:58 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-25 15:20 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-26 02:08 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-25 19:06 -0800
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-26 11:52 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 13:15 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-26 15:08 +0200
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-25 19:21 -0800
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-29 22:40 +0100
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-11-29 22:04 -0500
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 08:55 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-26 12:05 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 15:49 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-26 15:44 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 17:37 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-26 18:42 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 21:43 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-26 22:19 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-27 02:32 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-27 12:46 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-27 14:39 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-27 11:43 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-27 12:20 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-27 14:02 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-27 16:02 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-27 21:15 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-28 00:15 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-28 09:46 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-28 13:12 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-28 12:45 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-28 15:33 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-28 15:47 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-29 19:23 +0200
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-29 00:20 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-29 19:30 +0200
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-28 13:09 -0600
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-28 22:43 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-27 17:13 +0000
Re: _BitInt(N) Ike Naar <ike@sdf.org> - 2025-11-27 17:38 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-27 17:59 +0000
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-28 03:33 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-28 11:49 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-28 14:46 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-28 15:23 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-29 00:08 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-29 03:12 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-28 19:38 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-29 11:24 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-29 14:45 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-29 14:40 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-29 17:15 +0100
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-11-29 10:27 -0500
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-29 16:29 -0800
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-11-29 22:08 -0500
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-20 11:24 -0800
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-12-21 00:18 +0000
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-21 23:07 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-22 02:51 -0800
Re: _BitInt(N) Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-22 19:23 +0000
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 03:01 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-20 18:22 -0800
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-06 21:57 -0800
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-20 21:27 -0500
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-06 21:51 -0800
Re: _BitInt(N) Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-21 02:27 +0000
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-21 22:48 -0800
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-29 03:26 +0100
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-29 03:32 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-29 12:24 +0000
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-11-28 09:48 -0500
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-28 11:41 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-28 19:46 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-28 21:58 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-27 15:59 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-28 00:11 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-27 16:39 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-28 01:49 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-27 19:36 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-04 17:58 -0800
[meta] Newsreader and formatting (was Re: _BitInt(N)) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-28 02:56 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-12-01 14:59 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 14:18 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-01 12:06 -0800
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-01 23:59 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-02 08:31 +0100
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-12-02 12:14 +0100
[OT] Keyboard layout (was Re: _BitInt(N)) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-02 14:01 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-02 15:33 -0800
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-12-03 09:23 +0100
Re: _BitInt(N) Richard Heathfield <rjh@cpax.org.uk> - 2025-12-03 08:29 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-03 02:16 -0800
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-15 11:01 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-15 14:19 -0800
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-21 22:24 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-02 12:21 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-02 13:45 +0100
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-02 14:15 +0100
Block syntax (was Re: _BitInt(N)) bart <bc@freeuk.com> - 2025-12-02 14:12 +0000
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-02 13:53 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-12-02 19:55 +0200
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-02 19:37 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-02 21:07 +0100
Re: _BitInt(N) Ike Naar <ike@sdf.org> - 2025-11-27 08:10 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-27 01:30 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-27 02:18 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-27 04:12 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-29 20:24 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-29 22:58 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-29 16:46 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-30 02:30 +0000
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-30 05:31 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-30 12:51 +0000
Re: _BitInt(N) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-11-30 18:17 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-30 17:55 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-12-01 00:08 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 01:14 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-12-01 04:10 +0000
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 14:41 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 16:24 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 17:19 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 19:33 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 20:14 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-12-02 01:04 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-01 18:21 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-01 12:34 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 22:01 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-01 15:01 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 11:33 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 11:29 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 14:10 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-01 08:56 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 19:38 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-01 12:42 -0800
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-12-02 22:17 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-03 09:25 +0100
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-03 06:17 -0500
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-03 10:07 -0800
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-15 08:19 -0800
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-15 08:21 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-30 18:05 -0800
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-29 20:32 -0800
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-30 12:22 +0200
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 11:41 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-30 12:28 +0100
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 13:35 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-30 15:14 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-30 12:09 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 18:03 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-25 11:38 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-25 14:12 +0200
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-25 14:57 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-25 18:29 +0200
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-25 18:33 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-26 11:12 +0200
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-26 12:45 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-26 15:31 +0200
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-26 11:29 +0200
Re: _BitInt(N) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-11-26 21:19 -0500
Re: _BitInt(N) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-12-15 08:29 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-25 21:54 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-25 13:42 -0800
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-26 12:01 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 15:08 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-26 13:24 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-25 23:11 +0200
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-26 17:04 -0600
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-27 01:05 +0000
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-27 02:54 +0000
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-29 22:17 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-29 22:41 +0000
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 00:17 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-30 01:22 +0000
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 11:00 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-30 11:05 +0200
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 10:51 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-30 13:10 +0000
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-30 15:26 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-30 15:09 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-30 17:26 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-30 21:53 +0000
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-30 17:32 -0800
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 08:36 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 11:37 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 14:37 +0100
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-12-01 14:14 +0000
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-12-01 16:28 +0100
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-30 12:39 +0100
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-24 14:10 +0200
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 04:29 -0800
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-23 21:39 -0600
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 11:45 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-24 13:57 +0200
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 12:56 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-24 15:17 +0200
Re: _BitInt(N) David Brown <david.brown@hesbynett.no> - 2025-11-24 15:59 +0100
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 05:35 -0800
Re: _BitInt(N) bart <bc@freeuk.com> - 2025-11-24 14:21 +0000
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-24 13:12 -0600
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 17:00 -0800
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-24 20:10 -0600
Re: _BitInt(N) Philipp Klaus Krause <pkk@spth.de> - 2025-11-29 22:30 +0100
Re: _BitInt(N) antispam@fricas.org (Waldek Hebisch) - 2025-11-30 01:51 +0000
Re: _BitInt(N) Michael S <already5chosen@yahoo.com> - 2025-11-30 11:22 +0200
Re: _BitInt(N) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-11-24 04:37 -0800
Re: _BitInt(N) BGB <cr88192@gmail.com> - 2025-11-24 11:52 -0600
Page 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-27 19:36 -0800 |
| Message-ID | <875xauj0ax.fsf@example.invalid> |
| In reply to | #395539 |
bart <bc@freeuk.com> writes:
> On 28/11/2025 00:39, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 27/11/2025 23:59, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 27/11/2025 10:43, David Brown wrote:
>>>> [...]
>>>>>> uint64_t get_exponent(double x) {
>>>>>> return ((union { double d; uint64_t u;}) { x }.u >> 52)
>>>>>> & ((1ull << (62 - 52 + 1)) - 1);
>>>>>> }
>> [...]
>>>> How exactly did clang and msvs express their dislike? What versions
>>>> are
>>>> you using?
>>>> On my systems, it works correctly with gcc 13.3.0, clang 18.1.3,
>>>> tcc 0.9.27, Microsoft Visual Studio 2022 17.14.20.
>>>> If your problem is that you're using older compilers that don't
>>>> support
>>>> compound literals, it would have saved some time if you had said so.
>> Can you *please* do something about the way your newsreader
>> (apparently Mozilla Thunderbird) mangles quoted text? That first
>> quoted line, starting with "> How exactly", would have been just
>> 74 columns, but your newsreader folded it, making it more difficult
>> to read. It also deletes blank lines between paragraphs.
>> I don't recall similar problems from other Thunderbird users.
>
> I don't see anything amiss with quoted content in my own posts. My
> last post looks like this to me:
>
> https://github.com/sal55/langs/blob/master/tbird.png
>
> In any case, I've no idea how to fix the problem, assuming it is at my end.
My apologies, the problem doesn't appear to be on your end.
I saved your post from my newsreader (Gnus), and the quoted text
was correctly formatted in the saved copy. The lines were not
unevenly wrapped, and blank lines between paragraphs were preserved.
The formatting is messed up when I view the article in Gnus, but ok
when I view it in Thunderbird.
Relevant headers in your article are:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
...
User-Agent: Mozilla Thunderbird
...
Content-Language: en-GB
I think the "format=flowed" might be an issue (I suggest it's
not ideal for Usenet posts), but yours aren't the only posts that
use 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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-04 17:58 -0800 |
| Message-ID | <87jyz1g04z.fsf@example.invalid> |
| In reply to | #395542 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> bart <bc@freeuk.com> writes:
>> On 28/11/2025 00:39, Keith Thompson wrote:
[...]
>>> Can you *please* do something about the way your newsreader
>>> (apparently Mozilla Thunderbird) mangles quoted text? That first
>>> quoted line, starting with "> How exactly", would have been just
>>> 74 columns, but your newsreader folded it, making it more difficult
>>> to read. It also deletes blank lines between paragraphs.
>>> I don't recall similar problems from other Thunderbird users.
>>
>> I don't see anything amiss with quoted content in my own posts. My
>> last post looks like this to me:
>>
>> https://github.com/sal55/langs/blob/master/tbird.png
>>
>> In any case, I've no idea how to fix the problem, assuming it is at my end.
>
> My apologies, the problem doesn't appear to be on your end.
[snip]
I think I've found a partial solution. This may be of interest to
Gnus users, but there is no C content.
Bart's articles have "Content-Type: text/plain; charset=UTF-8;
format=flowed". It seems that Gnus has problems with
"format=flowed".
As a workaround, I'm adding this line to my .emacs :
(setq fill-column 100)
The default value is 70, which causes Gnus to display flowed text
with line wrapping at 70 columns -- and worse, that wrapping is
propagated when I quote such text in a followup.
I think the interaction between "format=flowed" and hard line
breaks is tricky. With this change on my end, I *think* that any
reasonably formatted text will not be inappropriately line-wrapped.
If there are any replies to this, please consider moving the
discussion to gnu.emacs.gnus (I haven't posted there).
--
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 | 2025-11-28 02:56 +0100 |
| Subject | [meta] Newsreader and formatting (was Re: _BitInt(N)) |
| Message-ID | <10gavgs$1v1g3$1@dont-email.me> |
| In reply to | #395538 |
Am 28.11.25 um 01:39 schrieb Keith Thompson: > bart <bc@freeuk.com> writes: >> [...] > > Can you *please* do something about the way your newsreader > (apparently Mozilla Thunderbird) mangles quoted text? That first > quoted line, starting with "> How exactly", would have been just > 74 columns, but your newsreader folded it, making it more difficult > to read. It also deletes blank lines between paragraphs. > > I don't recall similar problems from other Thunderbird users. Actually Thunderbird is not very good in doing formatting; it's okay in cases where conventions are followed, but some types of replies just can't be (or aren't, at least) handled automatically. (Guessing a free-style format is ambitious.) Depending on the format and text quoted you sometimes need some additional manual formatting effort, especially if line lengths exceed the [historic] conventions, and if lines are manually split to respond to parts separately. Some posters just don't seem care much creating readable formatted text which includes to "fix" effects of that specific newsreader. But the format I see created from your newsreader (where you quoted bart) appears also "wrongly formatted". If I test-wise reply to bart's post the formatting of Thunderbird is okay. So it boils down, I think, that deviating from the posting standards will always create one or another formatting issue. (I'd vote for following historic conventions but I'm positive that wish won't come true.) A practical hint for Thunderbird users; marking a "corrupt" paragraph with the mouse and typing Ctrl-R reformats the text (including quoted parts by rearranging the indent characters). But of course don't try to do that with _preformatted_ texts like source code. Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-01 14:59 +0200 |
| Message-ID | <20251201145917.00001c99@yahoo.com> |
| In reply to | #395506 |
On Wed, 26 Nov 2025 21:43:59 +0100 David Brown <david.brown@hesbynett.no> wrote: > On 26/11/2025 19:42, bart wrote: > > On 26/11/2025 16:37, David Brown wrote: > >> On 26/11/2025 16:44, bart wrote: > > > > > > Well, it would be a minority. Grown-up languages with decent syntax > > exist such as Ada and Fortran; those are not that popular. People > > prefer brace-based languages such as C, Java, Go, Zig, Rust. > > > > Anything without braces isn't taken as seriously, eg. scripting > > languages. > > What a /very/ strange way to distinguish or classify languages. And > what a bizarre way to generalise what people think, as though all > programmers share the same opinions. > I think that Bart is spot on. Curly languages are much more likely to be widely accepted than others. The difference between Bart and me is that I like it. I strongly prefer VHDL over Verilog, but that's due to semantics and despite too wordy syntax of the former.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-12-01 14:18 +0100 |
| Message-ID | <10gk4ja$1bg69$2@dont-email.me> |
| In reply to | #395628 |
On 01/12/2025 13:59, Michael S wrote: > On Wed, 26 Nov 2025 21:43:59 +0100 > David Brown <david.brown@hesbynett.no> wrote: > >> On 26/11/2025 19:42, bart wrote: >>> On 26/11/2025 16:37, David Brown wrote: >>>> On 26/11/2025 16:44, bart wrote: >>> >>> >>> Well, it would be a minority. Grown-up languages with decent syntax >>> exist such as Ada and Fortran; those are not that popular. People >>> prefer brace-based languages such as C, Java, Go, Zig, Rust. >>> >>> Anything without braces isn't taken as seriously, eg. scripting >>> languages. >> >> What a /very/ strange way to distinguish or classify languages. And >> what a bizarre way to generalise what people think, as though all >> programmers share the same opinions. >> > > I think that Bart is spot on. > Curly languages are much more likely to be widely accepted than others. > The difference between Bart and me is that I like it. > > I strongly prefer VHDL over Verilog, but that's due to semantics and > despite too wordy syntax of the former. > I too tend to prefer braces as a way of distinguishing blocks in most languages (I don't think it would work as well in functional programming languages). But that's just personal preference for one part of syntax, and rarely the deciding factor in choosing a language. Some people like a more "wordy" syntax, others prefer a more compact syntax. Obviously in a C language group there's going to be a bias towards a more compact syntax than if the same discussion were in comp.lang.ada. It most certainly is not a way people distinguish between "serious" or "grown-up" languages and other languages, nor do people view languages that are often used for scripting as "not serious". There are lots of programming languages, with different pros and cons and suitability for different types of programming task, as well as fitting personal preferences of different people.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-01 12:06 -0800 |
| Message-ID | <87y0nm7yru.fsf@example.invalid> |
| In reply to | #395505 |
bart <bc@freeuk.com> writes:
[...]
> Well, it would be a minority. Grown-up languages with decent syntax
> exist such as Ada and Fortran; those are not that popular. People
> prefer brace-based languages such as C, Java, Go, Zig, Rust.
>
> Anything without braces isn't taken as seriously, eg. scripting languages.
[...]
The use of curly braces vs. begin/end is IMHO trivial. But most
languages that use curly braces are strongly influenced by C,
and are likely to share other C features like C-style for loops.
Languages that use begin/end or similar are typically influenced,
directly or indirectly, by Pascal and/or Algol.
Someone who dislikes C for whatever reasons will probably dislike
most other languages that use curly braces, and not necessarily
because of that one syntactic detail.
--
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 | 2025-12-01 23:59 +0100 |
| Message-ID | <10gl6jq$3htol$9@dont-email.me> |
| In reply to | #395640 |
On 2025-12-01 21:06:13, Keith Thompson wrote:
>
> The use of curly braces vs. begin/end is IMHO trivial. [...]
>
> Someone who dislikes C for whatever reasons will probably dislike
> most other languages that use curly braces, and not necessarily
> because of that one syntactic detail.
There may also be just simple practical real-life facts that
influence the preferences of languages with curly braces (or
brackets). I want to remind that keyboards from other domains
may not have the simple access to the [ ] { } characters! On
my US keyboard [ and ] are adjacent and directly accessible,
and { and } are on the same keys reachable simply with 'Shift'.
That's extremely convenient if you're programming C-like syntax!
Though on my German keyboard these characters are placed on the
top numbers row in one line, ordered as { [ ] }, and reachable
only through the 'Alt Gr' key. This is really a pain to type.
For _very common characters_ in a fairly common and rich family
of programming languages it's an issue [in such non-US domains].
Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-12-02 08:31 +0100 |
| Message-ID | <10gm4l9$2302c$1@dont-email.me> |
| In reply to | #395645 |
On 01/12/2025 23:59, Janis Papanagnou wrote:
> On 2025-12-01 21:06:13, Keith Thompson wrote:
>>
>> The use of curly braces vs. begin/end is IMHO trivial. [...]
>>
>> Someone who dislikes C for whatever reasons will probably dislike
>> most other languages that use curly braces, and not necessarily
>> because of that one syntactic detail.
>
> There may also be just simple practical real-life facts that
> influence the preferences of languages with curly braces (or
> brackets). I want to remind that keyboards from other domains
> may not have the simple access to the [ ] { } characters! On
> my US keyboard [ and ] are adjacent and directly accessible,
> and { and } are on the same keys reachable simply with 'Shift'.
> That's extremely convenient if you're programming C-like syntax!
> Though on my German keyboard these characters are placed on the
> top numbers row in one line, ordered as { [ ] }, and reachable
> only through the 'Alt Gr' key. This is really a pain to type.
> For _very common characters_ in a fairly common and rich family
> of programming languages it's an issue [in such non-US domains].
>
My Norwegian keyboard needs AltGr for {[]}, but I don't find it a burden
- it's habit, I suppose.
But in days gone by if anyone ever needed to use trigraphs for C
programming, then I am sure they would happily switch to a word-based
language given half a chance. I find "{ }" nicer than "begin end", but
I'd pick "begin end" over "??< ??>" any day!
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-12-02 12:14 +0100 |
| Message-ID | <10gmhn1$10oh3$1@solani.org> |
| In reply to | #395649 |
Am 02.12.25 um 08:31 schrieb David Brown:
>
> But in days gone by if anyone ever needed to use trigraphs for C
> programming, then I am sure they would happily switch to a word-based
> language given half a chance. I find "{ }" nicer than "begin end", but
> I'd pick "begin end" over "??< ??>" any day!
AFAIK, there never was a real user of trigraphs (unless you count
compiler test suites). AFAIK for all real-world use digraphs were
sufficient.
Philipp
P.S.: Why did MSI move the <>| key (between left shift and y on a normal
german keyboard) into the place for AltGr (moving AltGr to the left,
into where normally the right end of the spacebar would be)? It is not
like they needed the space, they just made the left shift key bigger and
the space bar shorter.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-12-02 14:01 +0100 |
| Subject | [OT] Keyboard layout (was Re: _BitInt(N)) |
| Message-ID | <10gmnvm$3htom$3@dont-email.me> |
| In reply to | #395650 |
On 2025-12-02 12:14:41, Philipp Klaus Krause wrote:
>
> P.S.: Why did MSI move the <>| key (between left shift and y on a normal
> german keyboard) into the place for AltGr (moving AltGr to the left,
> into where normally the right end of the spacebar would be)? It is not
> like they needed the space, they just made the left shift key bigger and
> the space bar shorter.
There's so much "wrong" with my [German] keyboard I don't know where
to start. - But the major point comes with these many "Windows" keys
(that you also find on most contemporary keyboards in other country
domains). And even those are non-standard; e.g. my "Model-M" replica
has the Alt-Gr and the right Windows-Key switched; too bad since you
often need that Alt-Gr key (as shown in this thread with { [ ] } ).
Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-02 15:33 -0800 |
| Message-ID | <87o6og31e7.fsf@example.invalid> |
| In reply to | #395650 |
Philipp Klaus Krause <pkk@spth.de> writes:
> Am 02.12.25 um 08:31 schrieb David Brown:
>> But in days gone by if anyone ever needed to use trigraphs for C
>> programming, then I am sure they would happily switch to a
>> word-based language given half a chance. I find "{ }" nicer than
>> "begin end", but I'd pick "begin end" over "??< ??>" any day!
>
> AFAIK, there never was a real user of trigraphs (unless you count
> compiler test suites). AFAIK for all real-world use digraphs were
> sufficient.
There have been actual uses of trigraphs. Richard Heathfield posted
this on this newsgroup in 2010 :
Yes, they are still needed, for example in some mainframe
environments. They make the code look astoundingly ugly, but
they do at least make it work. It is not uncommon for "normal"
C code to be written and tested on PCs, then run through
a conversion program to replace monographs with trigraphs
where required before transfer to the mainframe for final
testing. That way, you get the readability where it matters,
and the usability where /that/ matters.
But trigraphs have been removed in C23.
--
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 | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-12-03 09:23 +0100 |
| Message-ID | <10gos2a$1266k$1@solani.org> |
| In reply to | #395662 |
Am 03.12.25 um 00:33 schrieb Keith Thompson: > > There have been actual uses of trigraphs. Richard Heathfield posted > this on this newsgroup in 2010 : > > Yes, they are still needed, for example in some mainframe > environments. They make the code look astoundingly ugly, but > they do at least make it work. It is not uncommon for "normal" > C code to be written and tested on PCs, then run through > a conversion program to replace monographs with trigraphs > where required before transfer to the mainframe for final > testing. That way, you get the readability where it matters, > and the usability where /that/ matters. > > But trigraphs have been removed in C23. > Yes; looking at the minutes now, I can see this was far more controversial than what I remembered about trigraphs, and likely wouldn't have happened if WG14 had required strong consensus then. But I think Heathfields'd use case couls still work in C23 if we consider that conversion program together with the compiler on the mainframe to be the C implementation.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-12-03 08:29 +0000 |
| Message-ID | <10gosdg$33du5$4@dont-email.me> |
| In reply to | #395662 |
On 02/12/2025 23:33, Keith Thompson wrote:
> Philipp Klaus Krause <pkk@spth.de> writes:
>> Am 02.12.25 um 08:31 schrieb David Brown:
>>> But in days gone by if anyone ever needed to use trigraphs for C
>>> programming, then I am sure they would happily switch to a
>>> word-based language given half a chance. I find "{ }" nicer than
>>> "begin end", but I'd pick "begin end" over "??< ??>" any day!
>>
>> AFAIK, there never was a real user of trigraphs (unless you count
>> compiler test suites). AFAIK for all real-world use digraphs were
>> sufficient.
>
> There have been actual uses of trigraphs. Richard Heathfield posted
> this on this newsgroup in 2010 :
>
> Yes, they are still needed, for example in some mainframe
> environments. They make the code look astoundingly ugly, but
> they do at least make it work. It is not uncommon for "normal"
> C code to be written and tested on PCs, then run through
> a conversion program to replace monographs with trigraphs
> where required before transfer to the mainframe for final
> testing. That way, you get the readability where it matters,
> and the usability where /that/ matters.
Nostalgia ain't what it used to be, but yes, I did indeed write
that, and yes, such workarounds are still used.
> But trigraphs have been removed in C23.
Then so, in some mainframe environments, have curly braces. I
suppose their fix will be to not adopt C23.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-03 02:16 -0800 |
| Message-ID | <87jyz3oop3.fsf@example.invalid> |
| In reply to | #395666 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 02/12/2025 23:33, Keith Thompson wrote:
[...]
>> But trigraphs have been removed in C23.
>
> Then so, in some mainframe environments, have curly braces. I suppose
> their fix will be to not adopt C23.
Or to use C23 with trigraphs as an extension. I think such an
extension would be non-conforming, but programmers who actually
need trigraphs aren't likely to be too bothered by that.
Or they might use a build environment with some kind of
pre-preprocessor that generates conforming C23 code (assuming that
some characters are treated as curly braces).
I don't know enough about mainframe software development (specifically
for EBCDIC systems) to know which approach would make the most sense.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-12-15 11:01 -0800 |
| Message-ID | <86ldj3tvq9.fsf@linuxsc.com> |
| In reply to | #395666 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 02/12/2025 23:33, Keith Thompson wrote:
>
>> Philipp Klaus Krause <pkk@spth.de> writes:
>>
>>> Am 02.12.25 um 08:31 schrieb David Brown:
>>>
>>>> But in days gone by if anyone ever needed to use trigraphs for C
>>>> programming, then I am sure they would happily switch to a
>>>> word-based language given half a chance. I find "{ }" nicer than
>>>> "begin end", but I'd pick "begin end" over "??< ??>" any day!
>>>
>>> AFAIK, there never was a real user of trigraphs (unless you count
>>> compiler test suites). AFAIK for all real-world use digraphs were
>>> sufficient.
>>
>> There have been actual uses of trigraphs. Richard Heathfield posted
>> this on this newsgroup in 2010 :
>>
>> Yes, they are still needed, for example in some mainframe
>> environments. They make the code look astoundingly ugly, but
>> they do at least make it work. It is not uncommon for "normal"
>> C code to be written and tested on PCs, then run through
>> a conversion program to replace monographs with trigraphs
>> where required before transfer to the mainframe for final
>> testing. That way, you get the readability where it matters,
>> and the usability where /that/ matters.
>
> Nostalgia ain't what it used to be, but yes, I did indeed write that,
> and yes, such workarounds are still used.
>
>> But trigraphs have been removed in C23.
>
> Then so, in some mainframe environments, have curly braces. I suppose
> their fix will be to not adopt C23.
Curly braces are still available by means of the digraphs <% and %>.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-15 14:19 -0800 |
| Message-ID | <87pl8ftmkf.fsf@example.invalid> |
| In reply to | #395821 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 02/12/2025 23:33, Keith Thompson wrote:
[...]
>>> But trigraphs have been removed in C23.
>>
>> Then so, in some mainframe environments, have curly braces. I suppose
>> their fix will be to not adopt C23.
>
> Curly braces are still available by means of the digraphs <% and %>.
True, and that's probably good enough, but digraphs aren't recognized
in string literals, character constants, header names, or comments.
Then again, if the system's character set doesn't even have '{'
and '}' characters, there isn't going to be much demand for them.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-12-21 22:24 -0800 |
| Message-ID | <86wm2frq3b.fsf@linuxsc.com> |
| In reply to | #395826 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Richard Heathfield <rjh@cpax.org.uk> writes: >> >>> On 02/12/2025 23:33, Keith Thompson wrote: > > [...] > >>>> But trigraphs have been removed in C23. >>> >>> Then so, in some mainframe environments, have curly braces. I suppose >>> their fix will be to not adopt C23. >> >> Curly braces are still available by means of the digraphs <% and %>. > > True, and that's probably good enough, but digraphs aren't recognized > in string literals, character constants, header names, or comments. Comments are irrelevant because they aren't translated; if someone wants to use trigraphs (or digraphs) for curly braces inside a comment they are perfectly free to do so. Header names can be handled by copying or linking the file with a new name, where the new name has <% and %> in place of curly braces. String literals and character constants are a mild inconvenience, but nothing more than that - just four #define of symbols with appropriate values. Once those values are determined it should be straightforward to effect the necessary changes programmatically.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-12-02 12:21 +0000 |
| Message-ID | <10gmlkc$296fj$1@dont-email.me> |
| In reply to | #395649 |
On 02/12/2025 07:31, David Brown wrote:
> On 01/12/2025 23:59, Janis Papanagnou wrote:
>> On 2025-12-01 21:06:13, Keith Thompson wrote:
>>>
>>> The use of curly braces vs. begin/end is IMHO trivial. [...]
>>>
>>> Someone who dislikes C for whatever reasons will probably dislike
>>> most other languages that use curly braces, and not necessarily
>>> because of that one syntactic detail.
>>
>> There may also be just simple practical real-life facts that
>> influence the preferences of languages with curly braces (or
>> brackets). I want to remind that keyboards from other domains
>> may not have the simple access to the [ ] { } characters! On
>> my US keyboard [ and ] are adjacent and directly accessible,
>> and { and } are on the same keys reachable simply with 'Shift'.
>> That's extremely convenient if you're programming C-like syntax!
>> Though on my German keyboard these characters are placed on the
>> top numbers row in one line, ordered as { [ ] }, and reachable
>> only through the 'Alt Gr' key. This is really a pain to type.
>> For _very common characters_ in a fairly common and rich family
>> of programming languages it's an issue [in such non-US domains].
>>
>
> My Norwegian keyboard needs AltGr for {[]}, but I don't find it a burden
> - it's habit, I suppose.
>
> But in days gone by if anyone ever needed to use trigraphs for C
> programming, then I am sure they would happily switch to a word-based
> language given half a chance. I find "{ }" nicer than "begin end", but
> I'd pick "begin end" over "??< ??>" any day!
>
So:
if .. then begin ... end else begin ... end
... represents multiple statements.
Even I would see braces in a more favourable light. I wonder why it took
some years for language designers to realise you could simply have:
if .. then ... else ... end
Unfortunately that didn't really work for braces:
if (..) ... else ... }
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-12-02 13:45 +0100 |
| Message-ID | <10gmn25$29f15$1@dont-email.me> |
| In reply to | #395651 |
On 02/12/2025 13:21, bart wrote:
> On 02/12/2025 07:31, David Brown wrote:
>> On 01/12/2025 23:59, Janis Papanagnou wrote:
>>> On 2025-12-01 21:06:13, Keith Thompson wrote:
>>>>
>>>> The use of curly braces vs. begin/end is IMHO trivial. [...]
>>>>
>>>> Someone who dislikes C for whatever reasons will probably dislike
>>>> most other languages that use curly braces, and not necessarily
>>>> because of that one syntactic detail.
>>>
>>> There may also be just simple practical real-life facts that
>>> influence the preferences of languages with curly braces (or
>>> brackets). I want to remind that keyboards from other domains
>>> may not have the simple access to the [ ] { } characters! On
>>> my US keyboard [ and ] are adjacent and directly accessible,
>>> and { and } are on the same keys reachable simply with 'Shift'.
>>> That's extremely convenient if you're programming C-like syntax!
>>> Though on my German keyboard these characters are placed on the
>>> top numbers row in one line, ordered as { [ ] }, and reachable
>>> only through the 'Alt Gr' key. This is really a pain to type.
>>> For _very common characters_ in a fairly common and rich family
>>> of programming languages it's an issue [in such non-US domains].
>>>
>>
>> My Norwegian keyboard needs AltGr for {[]}, but I don't find it a
>> burden - it's habit, I suppose.
>>
>> But in days gone by if anyone ever needed to use trigraphs for C
>> programming, then I am sure they would happily switch to a word-based
>> language given half a chance. I find "{ }" nicer than "begin end",
>> but I'd pick "begin end" over "??< ??>" any day!
>>
>
> So:
>
> if .. then begin ... end else begin ... end
>
> ... represents multiple statements.
>
> Even I would see braces in a more favourable light. I wonder why it took
> some years for language designers to realise you could simply have:
>
> if .. then ... else ... end
I think different languages handle it differently. Some might do it the
way you suggest with "if ... then ... end", others with the full "if ...
then begin ... end", others with "if ... begin". And some have "if ...
fi", or "if ... end if". I haven't looked in detail - there are many
languages, and many possibilities. It will depend on whether the block
part is considered part of the conditional statement, or whether the
conditional only applies to a single logical statement which might be a
compound statement surrounded by block delimiters.
>
> Unfortunately that didn't really work for braces:
>
> if (..) ... else ... }
>
>
Indeed - mismatched braces are not a good idea!
But if you make the braces a required part of the syntax, then you can
probably omit the parentheses :
if ... { ... };
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-12-02 14:15 +0100 |
| Message-ID | <10gmope$3htol$11@dont-email.me> |
| In reply to | #395651 |
On 2025-12-02 13:21:32, bart wrote: > So: > > if .. then begin ... end else begin ... end > > ... represents multiple statements. > > Even I would see braces in a more favourable light. I wonder why it took > some years for language designers to realise you could simply have: > > if .. then ... else ... end You're misrepresenting history, or at least convey the impression that this would be something new and previously obscure, or that language designers would not know all these syntactical options. You had the if .. then ... else ... fi syntax as paragon in the back then by language experts well known Algol 68 language, it's been inherited (also in comparable forms), e.g. by the common Unix shell, also in "more recent" languages (with "end") in Eiffel, for example. The huge impact of the "C" language syntax might have made that less visible in the modern, contemporary (used, hyped) languages. But there's really nothing to "realize" by language designers, I'm sure. Janis > [...]
[toc] | [prev] | [next] | [standalone]
Page 7 of 13 — ← Prev page 1 … 5 6 [7] 8 9 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web