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 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-27 17:13 +0000 |
| Message-ID | <10ga0sd$1jb9e$1@dont-email.me> |
| In reply to | #395525 |
On 27/11/2025 13:02, David Brown wrote:
> On 27/11/2025 13:20, bart wrote:
> In some areas of C usage, shifts and masks - and bitfield extraction -
> turn up quite a bit. But it seems the C operators work fine for the
> task. It would not exactly be difficult to add a standard
> "bit_range_extract" function to the C standard library, yet no one has
> felt it to be worth the effort over the last 50 years.
That doesn't say much. Binary literals only became official in C23.
Width-specific integers only became standard in C99 (what did people use
in the preceding quarter-century?) and are not yet in the core language.
Such things as bit-extraction don't get prioritised because it so easy
for people to put together some crummy macro to do the job. But this
means everybody will create their own incompatible solutions.
Min/Max operators, or 'lengthof', will never get added for similar
reasons. But there was a time when every other code-base I looked at
defined its own MIN/MAX or Min/Max or min/max macros or functions.
Examples:
#define MZ_MAX(a, b) (((a) > (b)) ? (a) : (b)) (MZ lib)
# define MAX(A,B) ((A)>(B)?(A):(B)) (SQLite)
#define MAX(a,b) ((a) > (b) ? (a) : (b)) (LIBjpeg)
While everywhere you see patterns like:
sizeof(somearray/somearray[0])
which is crying out for standardisation.
Here, I guess 'no one has felt it to be worth the effort'. Except me.
>> The syntax actually comes from DEC Algol60 IIRC. It was used to access
>> individual characters of a string, normally an indivisible type in
>> that language, and I applied the same concept to bits of an integer.
>
> I don't care if you found the syntax on the back of a cornflakes packet.
> The origin is not relevant.
Oh, I thought it was an automatic negative reaction from you to anything
I'd thought up. I guess you have it in for DEC too.
>>
>>>> How much more fundamental can you get?
>>>
>>> It is not fundamental for a low-level systems language.
>>
>> So bits are not fundamental either! But then, it has taken until C23
>> to standardise binary literals, and there is still no format code for
>> binary output.
>>
>
> Very few programmers are at all interested in bits.
Unless it is that extra bit in _BitInt(65)! Then it is apparently vital.
A "double" holds a
> floating point value, not a pattern of bits. You are thinking on a
> level of abstraction that is not realistic for most programming tasks.
This is systems programming.
>> They frequently have advanced features while ignoring the basics.
>
> No - they frequently have features that /you/ call "advanced" because
> you don't need or want them, and they ignore things that /you/ call
> "basics" because you /do/ need or want them. It's all about /you/.
Well, let's stick with C. Here are some features I use, and the C
equivalents (A has whatever type is needed):
M C
-------------------------------------------------------------
A.len sizeof(A)/sizeof(A[0])
* max(a, b) (a > b ? a : b)
A.odd A & 1, or A % 1
A.even - you can do this one
A.msbit (A>>31) & 1, or (A>>63) & 1
2 ** n (1LL << n)
a ** b (int) pow(a, b) (ints cast to float, and float result)
x ** y (float) pow(x, y)
A.[i] = x - you can do this too; assume x is 0 or 1
A.[i..j] = x - yikes!
* if c in 'A'..'Z' if (c >= 'A' && c <= 'Z')
* if c in [cr, lf] if (c == cr || c == lf)
* if a = b = c if (a == b && b == c)
* swap(A[i+1], A[j]) {T temp=A[i+1]; A[i+1]=A[j]; A[j]=temp;}
abs(x) abs(x), labs(x), llabs(x), fabs(x) ...
println =a, =b printf("A=%X B=%Y\n", a, b); what are X, Y?
readln a, b - some scanf nonsense
(a,b):=c divrem d - involves div_t and div()
print "-" * 50 "----------------------- ... "
A[i, j] A[i][j]
byte unsigned char, uint8_t, _BitInt(8), char maybe
(* marks examples that are problemetic in C when operands that have
side-effects are evaluated twice)
There are /dozens/ of examples like this that make small tasks a
pleasure to write, but also make them clearer, to the point, and less
error prone.
But let me guess, none of this cuts any ice at all. The C will always be
superior.
> You are talking nonsense.
End of discussion then. You either missed my point or chose to ignore it.
> I understand that simple maths and common sense is beyond you.
More insults.
>>> uint64_t get_exponent(double x) {
>>> return ((union { double d; uint64_t u;}) { x }.u >> 52)
>>> & ((1ull << (62 - 52 + 1)) - 1);
>>> }
>>>
>>> That compiles (with gcc on x86-64) to :
>>>
>>> movq rax, xmm0
>>> shr rax, 52
>>> and eax, 2047
>>> ret
>>>
>>> There's nothing in C that suggests this must be put in memory or do
>>> anything more than this.
>>
>> (This only seems to work with gcc. Clang and MSVS don't like it.)
>>
>
> I think you are mistaken. clang is fine with it. It is standard C99,
> so any decent C compiler from the last 25 years will handle it fine. MS
> gave up on bothering to make C compilers before the turn of the century
> (they make a reasonable enough C++ compiler). Even your hero tcc is
> fine with it (though on my attempts, it produces rubbish code - maybe it
> needs different flags for optimisation). The C code is not made invalid
> by the existence of C90-only compilers.
I was mistaken. I used godbolt.org but it was set to C++. Presumably gcc
has some C++ extensions that make it valid.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.org> |
|---|---|
| Date | 2025-11-27 17:38 +0000 |
| Message-ID | <slrn10ih33q.bhp.ike@iceland.freeshell.org> |
| In reply to | #395530 |
On 2025-11-27, bart <bc@freeuk.com> wrote: > Well, let's stick with C. Here are some features I use, and the C > equivalents (A has whatever type is needed): > > M C > ------------------------------------------------------------- > [snip] > A.odd A & 1, or A % 1 "A % 1" ?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-27 17:59 +0000 |
| Message-ID | <10ga3hn$1kv34$1@dont-email.me> |
| In reply to | #395531 |
On 27/11/2025 17:38, Ike Naar wrote: > On 2025-11-27, bart <bc@freeuk.com> wrote: >> Well, let's stick with C. Here are some features I use, and the C >> equivalents (A has whatever type is needed): >> >> M C >> ------------------------------------------------------------- >> [snip] >> A.odd A & 1, or A % 1 > > "A % 1" ? I guess A % 2 then. Note my remark about error proneness later on.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-11-28 03:33 +0100 |
| Message-ID | <10gb1md$203ao$2@dont-email.me> |
| In reply to | #395532 |
On 11/27/25 18:59, bart wrote:
> On 27/11/2025 17:38, Ike Naar wrote:
>> On 2025-11-27, bart <bc@freeuk.com> wrote:
>>> Well, let's stick with C. Here are some features I use, and the C
>>> equivalents (A has whatever type is needed):
>>>
>>> M C
>>> -------------------------------------------------------------
>>> [snip]
>>> A.odd A & 1, or A % 1
>>
>> "A % 1" ?
>
> I guess A % 2 then.
You guess? - LOL - okay. :-)
> Note my remark about error proneness later on.
Higher level abstractions (usually found in higher level languages)
are always less error prone than low-level (or composed) constructs.
"C" is inherently and by design a comparably low-level language, so
I wonder what you complain here about. (You won't change that.)
'even' and 'odd' are higher level abstractions than bit-operations,
and they are also _special cases_ (nonetheless useful; I like them,
and I appreciate if they are present in any language). The general
case of the terms like "odd" and "even" is defined mathematically,
though; so the natural way of describing them would (IMO) rather be
based on 'x mod 2 = 1' and 'x mod 2 = 0' respectively. (So the "C"
syntax with '%' is probably more "appropriate". Mileages may vary.)
You can of course add as many commodity features to "your language"
as you like. I seem to recall that one of the design principles of
"C" was to not add too many keywords. (Not sure whether 'A.odd' is
a function or keyword above [in "your language"].) Omitting to add
special case operators or functions for things that can simply be
expressed by the respective arithmetic or boolean counterparts is
not an unreasonable language-detail design decision.[*]
You made a mistake above (or just a typo), never mind. I suppose it
stems from your primary "thinking in bits". - This is not meant to
be offensive. - Back in university days (I still remember!) I made
a similar typo but vice versa; I wanted to express "div 2" in some
assembler language and accidentally wrote "shift-right 2", the same
type of typo but the other way round. I *knew*, and didn't "guess",
though, that "shift-right 1" would have been correct. ;-)
Janis
[*] Compare to Algol 68 that introduced everything ("including the
kitchen sink"), and even in multiple variants! - A design decision
that is also not appreciated by everyone.
PS: BTW, I was always wondering why Pascal and Algol 68 supported
'odd' but not 'even'! - In the documents of the Genie compiler we
can read: "This is a relic of times long past.", but beyond that
it doesn't explain why it's a "relic". I can only guess that it's,
as a special case, considered just unnecessary in the presence of
the modulus operator.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-28 11:49 +0000 |
| Message-ID | <10gc28l$2c8jt$1@dont-email.me> |
| In reply to | #395541 |
On 28/11/2025 02:33, Janis Papanagnou wrote: > On 11/27/25 18:59, bart wrote: >> On 27/11/2025 17:38, Ike Naar wrote: >>> On 2025-11-27, bart <bc@freeuk.com> wrote: >>>> Well, let's stick with C. Here are some features I use, and the C >>>> equivalents (A has whatever type is needed): >>>> >>>> M C >>>> ------------------------------------------------------------- >>>> [snip] >>>> A.odd A & 1, or A % 1 >>> >>> "A % 1" ? >> >> I guess A % 2 then. > > You guess? - LOL - okay. :-) > >> Note my remark about error proneness later on. > > Higher level abstractions (usually found in higher level languages) > are always less error prone than low-level (or composed) constructs. > > "C" is inherently and by design a comparably low-level language, so > I wonder what you complain here about. (You won't change that.) So is mine. But it has many more 'commodity' features that make life simpler. Plus a generally cleaner syntax to make it clearer. > 'even' and 'odd' are higher level abstractions than bit-operations, > and they are also _special cases_ (nonetheless useful; I like them, > and I appreciate if they are present in any language). The general > case of the terms like "odd" and "even" is defined mathematically, > though; The advantage of using '.odd' is that the language doesn't specify how it works, just the behaviour. (But internally, 'A.odd' is an alias for 'A.[0]', and 'A.even' is one for 'not A.[0]', but with the extra proviso that these are read-only: while `A.[0] := x' is possible, you can't do 'A.odd := x'.) > so the natural way of describing them would (IMO) rather be > based on 'x mod 2 = 1' and 'x mod 2 = 0' respectively. (So the "C" > syntax with '%' is probably more "appropriate". Mileages may vary.) I've made the mistake with % 1 more than once. > You can of course add as many commodity features to "your language" > as you like. I seem to recall that one of the design principles of > "C" was to not add too many keywords. (Not sure whether 'A.odd' is > a function or keyword above [in "your language"].) It is a reserved word, which means it can't be used as either a top-level user identifier, or a member name. With extra effort, it could be used for both, but that needs some special syntax, such as Ada-style "A'odd"; I've never got around to it. In Pascal (where I copied it from) it is a reserved word. > You made a mistake above (or just a typo), never mind. I suppose it > stems from your primary "thinking in bits". - This is not meant to > be offensive. - Back in university days (I still remember!) I made > a similar typo but vice versa; I wanted to express "div 2" in some > assembler language and accidentally wrote "shift-right 2", the same > type of typo but the other way round. I *knew*, and didn't "guess", > though, that "shift-right 1" would have been correct. ;-) I use a decimal type in another language. There bitwise operations don't work. I would have to define what they might do. For example, the possibilities for `123 << 2` might be: - Not valid (how it works now) - 12300 (shift decimal digits) - 492 (shift 'binary' digits) That last simply defines as 'A << n' as meaning 'A * 2**n'. > PS: BTW, I was always wondering why Pascal and Algol 68 supported > 'odd' but not 'even'! - In the documents of the Genie compiler we > can read: "This is a relic of times long past.", but beyond that > it doesn't explain why it's a "relic". I can only guess that it's, > as a special case, considered just unnecessary in the presence of > the modulus operator. Maybe because you can trivially define 'even' as 'not odd'.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-28 14:46 +0000 |
| Message-ID | <10gccjg$2g0lv$1@dont-email.me> |
| In reply to | #395548 |
On 28/11/2025 11:49, bart wrote: > On 28/11/2025 02:33, Janis Papanagnou wrote: >> On 11/27/25 18:59, bart wrote: >>> On 27/11/2025 17:38, Ike Naar wrote: >>>> On 2025-11-27, bart <bc@freeuk.com> wrote: >>>>> Well, let's stick with C. Here are some features I use, and the C >>>>> equivalents (A has whatever type is needed): >>>>> >>>>> M C >>>>> ------------------------------------------------------------- >>>>> [snip] >>>>> A.odd A & 1, or A % 1 >>>> >>>> "A % 1" ? >>> >>> I guess A % 2 then. >> >> You guess? - LOL - okay. :-) >> >>> Note my remark about error proneness later on. >> >> Higher level abstractions (usually found in higher level languages) >> are always less error prone than low-level (or composed) constructs. >> >> "C" is inherently and by design a comparably low-level language, so >> I wonder what you complain here about. (You won't change that.) > > So is mine. But it has many more 'commodity' features that make life > simpler. Plus a generally cleaner syntax to make it clearer. I didn't answer your (JP's) question. When I mention such micro-features of mine, the response is always overwhelmingly negative (even if I subsequently reveal they are inspired by other languages). In this thread, in response to a use-case of small BitInt types, I suggested a more general set of bit-operations that didn't involve emplying the type system. But apparently, even in the world's most famous and truly 'bare-metal' systems language, accessing the underlying bits of machine types is a rarely used, niche feature.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-28 15:23 -0800 |
| Message-ID | <875xatbv2s.fsf@example.invalid> |
| In reply to | #395548 |
bart <bc@freeuk.com> writes:
> On 28/11/2025 02:33, Janis Papanagnou wrote:
[...]
>> You can of course add as many commodity features to "your language"
>> as you like. I seem to recall that one of the design principles of
>> "C" was to not add too many keywords. (Not sure whether 'A.odd' is
>> a function or keyword above [in "your language"].)
>
> It is a reserved word, which means it can't be used as either a
> top-level user identifier, or a member name. With extra effort, it
> could be used for both, but that needs some special syntax, such as
> Ada-style "A'odd"; I've never got around to it.
>
> In Pascal (where I copied it from) it is a reserved word.
<OT>In Pascal, "odd" is not a reserved word. It's the name of a
predefined function.</OT>
[...]
>> PS: BTW, I was always wondering why Pascal and Algol 68 supported
>> 'odd' but not 'even'! - In the documents of the Genie compiler we
>> can read: "This is a relic of times long past.", but beyond that
>> it doesn't explain why it's a "relic". I can only guess that it's,
>> as a special case, considered just unnecessary in the presence of
>> the modulus operator.
>
> Maybe because you can trivially define 'even' as 'not odd'.
Or maybe because odd(n) can be implemented as "treat the low-order bit
of the argument as a Boolean".
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-29 00:08 +0000 |
| Message-ID | <10gddie$2tgu4$1@dont-email.me> |
| In reply to | #395558 |
On 28/11/2025 23:23, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 28/11/2025 02:33, Janis Papanagnou wrote: > [...] >>> You can of course add as many commodity features to "your language" >>> as you like. I seem to recall that one of the design principles of >>> "C" was to not add too many keywords. (Not sure whether 'A.odd' is >>> a function or keyword above [in "your language"].) >> >> It is a reserved word, which means it can't be used as either a >> top-level user identifier, or a member name. With extra effort, it >> could be used for both, but that needs some special syntax, such as >> Ada-style "A'odd"; I've never got around to it. >> >> In Pascal (where I copied it from) it is a reserved word. > > <OT>In Pascal, "odd" is not a reserved word. It's the name of a > predefined function.</OT> So what's a 'reserved word' then? To me it is something not available as a user-identifier because it has a special meaning in the language, which may be that of a predefined function among other things.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-29 03:12 +0000 |
| Message-ID | <10gdobn$1627r$1@paganini.bofh.team> |
| In reply to | #395559 |
bart <bc@freeuk.com> wrote:
> On 28/11/2025 23:23, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 28/11/2025 02:33, Janis Papanagnou wrote:
>> [...]
>>>> You can of course add as many commodity features to "your language"
>>>> as you like. I seem to recall that one of the design principles of
>>>> "C" was to not add too many keywords. (Not sure whether 'A.odd' is
>>>> a function or keyword above [in "your language"].)
>>>
>>> It is a reserved word, which means it can't be used as either a
>>> top-level user identifier, or a member name. With extra effort, it
>>> could be used for both, but that needs some special syntax, such as
>>> Ada-style "A'odd"; I've never got around to it.
>>>
>>> In Pascal (where I copied it from) it is a reserved word.
>>
>> <OT>In Pascal, "odd" is not a reserved word. It's the name of a
>> predefined function.</OT>
>
> So what's a 'reserved word' then? To me it is something not available as
> a user-identifier because it has a special meaning in the language,
Yes.
> which may be that of a predefined function among other things.
The point is that there is no need to reserve names of predefined
identifiers. Logically they may be defined in special scope and
any definition in program shadows predefined meaning. That
happens in Pascal (but not in C).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-28 19:38 -0800 |
| Message-ID | <871plhbja9.fsf@example.invalid> |
| In reply to | #395559 |
bart <bc@freeuk.com> writes:
> On 28/11/2025 23:23, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 28/11/2025 02:33, Janis Papanagnou wrote:
>> [...]
>>>> You can of course add as many commodity features to "your language"
>>>> as you like. I seem to recall that one of the design principles of
>>>> "C" was to not add too many keywords. (Not sure whether 'A.odd' is
>>>> a function or keyword above [in "your language"].)
>>>
>>> It is a reserved word, which means it can't be used as either a
>>> top-level user identifier, or a member name. With extra effort, it
>>> could be used for both, but that needs some special syntax, such as
>>> Ada-style "A'odd"; I've never got around to it.
>>>
>>> In Pascal (where I copied it from) it is a reserved word.
>> <OT>In Pascal, "odd" is not a reserved word. It's the name of a
>> predefined function.</OT>
>
> So what's a 'reserved word' then? To me it is something not available
> as a user-identifier because it has a special meaning in the language,
> which may be that of a predefined function among other things.
Right. The name "odd" is available as a user-defined identifier.
If you define something named "odd" in Pascal, it hides the
predefined function of that name.
You can think of Pascal's predefined functions as being declared
in an outer scope, surrounding the main program. Pascal's rules
for declarations in inner scopes hiding identifiers in outer scopes
are similar to C's.
(C has no predefined functions.)
If there's more to say about this, I suggest comp.lang.misc or
comp.lang.pascal.misc.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-29 11:24 +0000 |
| Message-ID | <10gel52$3ab2u$1@dont-email.me> |
| In reply to | #395564 |
On 29/11/2025 03:38, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 28/11/2025 23:23, Keith Thompson wrote: >>> bart <bc@freeuk.com> writes: >>>> On 28/11/2025 02:33, Janis Papanagnou wrote: >>> [...] >>>>> You can of course add as many commodity features to "your language" >>>>> as you like. I seem to recall that one of the design principles of >>>>> "C" was to not add too many keywords. (Not sure whether 'A.odd' is >>>>> a function or keyword above [in "your language"].) >>>> >>>> It is a reserved word, which means it can't be used as either a >>>> top-level user identifier, or a member name. With extra effort, it >>>> could be used for both, but that needs some special syntax, such as >>>> Ada-style "A'odd"; I've never got around to it. >>>> >>>> In Pascal (where I copied it from) it is a reserved word. >>> <OT>In Pascal, "odd" is not a reserved word. It's the name of a >>> predefined function.</OT> >> >> So what's a 'reserved word' then? To me it is something not available >> as a user-identifier because it has a special meaning in the language, >> which may be that of a predefined function among other things. > > Right. The name "odd" is available as a user-defined identifier. > If you define something named "odd" in Pascal, it hides the > predefined function of that name. I did test it with a toy Pascal compiler I have. Defining 'odd' as a variable didn't work, but that was for other reasons. > You can think of Pascal's predefined functions as being declared > in an outer scope, surrounding the main program. I took 'predefined functions' to mean 'built-in functions' (effectively, operators with function-like syntax), that cannot be overridden. So 'odd' is not a reserved word in Pascal; I was mistaken. (My opinion is that being able to shadow fundamental language features is undesirable. Being able to reuse them as user identifiers is another matter, but that would involve tricks with syntax or context to avoid ambiguity.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-29 14:45 +0100 |
| Message-ID | <10getdr$3dcuq$1@dont-email.me> |
| In reply to | #395565 |
On 29/11/2025 12:24, bart wrote: > On 29/11/2025 03:38, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >>> On 28/11/2025 23:23, Keith Thompson wrote: >>>> bart <bc@freeuk.com> writes: >>>>> On 28/11/2025 02:33, Janis Papanagnou wrote: >>>> [...] >>>>>> You can of course add as many commodity features to "your language" >>>>>> as you like. I seem to recall that one of the design principles of >>>>>> "C" was to not add too many keywords. (Not sure whether 'A.odd' is >>>>>> a function or keyword above [in "your language"].) >>>>> >>>>> It is a reserved word, which means it can't be used as either a >>>>> top-level user identifier, or a member name. With extra effort, it >>>>> could be used for both, but that needs some special syntax, such as >>>>> Ada-style "A'odd"; I've never got around to it. >>>>> >>>>> In Pascal (where I copied it from) it is a reserved word. >>>> <OT>In Pascal, "odd" is not a reserved word. It's the name of a >>>> predefined function.</OT> >>> >>> So what's a 'reserved word' then? To me it is something not available >>> as a user-identifier because it has a special meaning in the language, >>> which may be that of a predefined function among other things. >> >> Right. The name "odd" is available as a user-defined identifier. >> If you define something named "odd" in Pascal, it hides the >> predefined function of that name. > > I did test it with a toy Pascal compiler I have. Defining 'odd' as a > variable didn't work, but that was for other reasons. > > >> You can think of Pascal's predefined functions as being declared >> in an outer scope, surrounding the main program. > > I took 'predefined functions' to mean 'built-in functions' (effectively, > operators with function-like syntax), that cannot be overridden. > > So 'odd' is not a reserved word in Pascal; I was mistaken. > > (My opinion is that being able to shadow fundamental language features > is undesirable. Being able to reuse them as user identifiers is another > matter, but that would involve tricks with syntax or context to avoid > ambiguity.) > > The issue is where you draw the line of what is a "fundamental language feature", and what is not. For Pascal, "begin" is a fundamental language feature, part of the syntax. "odd" is not fundamental - it's just a function in the Pascal's equivalent of the C standard library. So no tricks or special syntax (like "stropping") are needed to re-use the identifier for other purposes. I agree that using words that are "fundamental" is not good. But if a language provides built-in functions in a global namespace, then it is a serious limitation if these cannot be shadowed or overridden. Basically, it means that you are always at risk of conflicts with existing code if later language versions add new functions. So if someone wrote Pascal code with a local variable called "even", and a later version introduced a built-in function "even", then it is critical that this is an overrideable or shadowable (if that is a real word!) identifier. That's why C is very conservative about adding new keywords, and uses reserved namespaces for the purpose - thus C99 added "_Bool", not "bool", to avoid conflict with existing code. Only now, over two decades later, did the committee feel that uses of the identifier "bool" other than as a typedef for _Bool (usually via <stdbool.h>) are so rare that C23 could finally have "bool" as a keyword for the type. And they still have challenges with good names for standard library functions - now in C23, many new ones have names with a "stdc_" prefix.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-29 14:40 +0000 |
| Message-ID | <10gf0k7$3emc1$1@dont-email.me> |
| In reply to | #395567 |
On 29/11/2025 13:45, David Brown wrote:
> On 29/11/2025 12:24, bart wrote:
>> On 29/11/2025 03:38, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>>> On 28/11/2025 23:23, Keith Thompson wrote:
>>>>> bart <bc@freeuk.com> writes:
>>>>>> On 28/11/2025 02:33, Janis Papanagnou wrote:
>>>>> [...]
>>>>>>> You can of course add as many commodity features to "your language"
>>>>>>> as you like. I seem to recall that one of the design principles of
>>>>>>> "C" was to not add too many keywords. (Not sure whether 'A.odd' is
>>>>>>> a function or keyword above [in "your language"].)
>>>>>>
>>>>>> It is a reserved word, which means it can't be used as either a
>>>>>> top-level user identifier, or a member name. With extra effort, it
>>>>>> could be used for both, but that needs some special syntax, such as
>>>>>> Ada-style "A'odd"; I've never got around to it.
>>>>>>
>>>>>> In Pascal (where I copied it from) it is a reserved word.
>>>>> <OT>In Pascal, "odd" is not a reserved word. It's the name of a
>>>>> predefined function.</OT>
>>>>
>>>> So what's a 'reserved word' then? To me it is something not available
>>>> as a user-identifier because it has a special meaning in the language,
>>>> which may be that of a predefined function among other things.
>>>
>>> Right. The name "odd" is available as a user-defined identifier.
>>> If you define something named "odd" in Pascal, it hides the
>>> predefined function of that name.
>>
>> I did test it with a toy Pascal compiler I have. Defining 'odd' as a
>> variable didn't work, but that was for other reasons.
>>
>>
>>> You can think of Pascal's predefined functions as being declared
>>> in an outer scope, surrounding the main program.
>>
>> I took 'predefined functions' to mean 'built-in
>> functions' (effectively, operators with function-like syntax), that
>> cannot be overridden.
>>
>> So 'odd' is not a reserved word in Pascal; I was mistaken.
>>
>> (My opinion is that being able to shadow fundamental language features
>> is undesirable. Being able to reuse them as user identifiers is
>> another matter, but that would involve tricks with syntax or context
>> to avoid ambiguity.)
>>
>>
>
> The issue is where you draw the line of what is a "fundamental language
> feature", and what is not. For Pascal, "begin" is a fundamental
> language feature, part of the syntax. "odd" is not fundamental - it's
> just a function in the Pascal's equivalent of the C standard library. So
> no tricks or special syntax (like "stropping") are needed to re-use the
> identifier for other purposes.
>
> I agree that using words that are "fundamental" is not good. But if a
> language provides built-in functions in a global namespace, then it is a
> serious limitation if these cannot be shadowed or overridden.
I see it as an advantage. I can do this in Python:
len = 42
print(len("abc"))
Now len() no longer works as expected. In Algo68 you can do this:
OP + = (INT a, b)INT: a - b;
print(2 + 3)
This prints -1. (Or, more subtly, you can redefine the precedence of '+'
to be the opposite side of '*'.)
With different scopes in effect, different parts of a program can see
different versions of what many might not realise are user-overrideable
features.
> Basically,
> it means that you are always at risk of conflicts with existing code if
> later language versions add new functions. So if someone wrote Pascal
> code with a local variable called "even", and a later version introduced
> a built-in function "even", then it is critical that this is an
> overrideable or shadowable (if that is a real word!) identifier.
If 'even' is implemented as though it can be defined via a
user-function) then shadowing is normally allowed (unless the language
likes to warn you about such things).
But if it's a true built-in that just happens to use function syntax,
then the user sees an error. Then they can choose to update their
codebase, when possible.
For somebody else's code, or for legacy code, that becomes harder, and
the implementation may need to strictly enforce language versions so
that such new features are disabled via the build info.
Alternately, such built-ins can use special syntax so they would never
clash with user-identifiers.
Note that such clashes can also occur when mixing libraries: maybe both
library A and B can export 'even', even when everything is defined in
user-code.
Then the language had better have a namespace feature to disasmbiguate
(which I have, but C doesn't)
> That's why C is very conservative about adding new keywords, and uses
> reserved namespaces for the purpose - thus C99 added "_Bool", not
> "bool", to avoid conflict with existing code. Only now, over two
> decades later, did the committee feel that uses of the identifier "bool"
> other than as a typedef for _Bool (usually via <stdbool.h>) are so rare
> that C23 could finally have "bool" as a keyword for the type. And they
> still have challenges with good names for standard library functions -
> now in C23, many new ones have names with a "stdc_" prefix.
>
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-29 17:15 +0100 |
| Message-ID | <10gf66l$3gtgp$1@dont-email.me> |
| In reply to | #395568 |
On 29/11/2025 15:40, bart wrote:
> On 29/11/2025 13:45, David Brown wrote:
>> On 29/11/2025 12:24, bart wrote:
>>> On 29/11/2025 03:38, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> On 28/11/2025 23:23, Keith Thompson wrote:
>>>>>> bart <bc@freeuk.com> writes:
>>>>>>> On 28/11/2025 02:33, Janis Papanagnou wrote:
>>>>>> [...]
>>>>>>>> You can of course add as many commodity features to "your language"
>>>>>>>> as you like. I seem to recall that one of the design principles of
>>>>>>>> "C" was to not add too many keywords. (Not sure whether 'A.odd' is
>>>>>>>> a function or keyword above [in "your language"].)
>>>>>>>
>>>>>>> It is a reserved word, which means it can't be used as either a
>>>>>>> top-level user identifier, or a member name. With extra effort, it
>>>>>>> could be used for both, but that needs some special syntax, such as
>>>>>>> Ada-style "A'odd"; I've never got around to it.
>>>>>>>
>>>>>>> In Pascal (where I copied it from) it is a reserved word.
>>>>>> <OT>In Pascal, "odd" is not a reserved word. It's the name of a
>>>>>> predefined function.</OT>
>>>>>
>>>>> So what's a 'reserved word' then? To me it is something not available
>>>>> as a user-identifier because it has a special meaning in the language,
>>>>> which may be that of a predefined function among other things.
>>>>
>>>> Right. The name "odd" is available as a user-defined identifier.
>>>> If you define something named "odd" in Pascal, it hides the
>>>> predefined function of that name.
>>>
>>> I did test it with a toy Pascal compiler I have. Defining 'odd' as a
>>> variable didn't work, but that was for other reasons.
>>>
>>>
>>>> You can think of Pascal's predefined functions as being declared
>>>> in an outer scope, surrounding the main program.
>>>
>>> I took 'predefined functions' to mean 'built-in
>>> functions' (effectively, operators with function-like syntax), that
>>> cannot be overridden.
>>>
>>> So 'odd' is not a reserved word in Pascal; I was mistaken.
>>>
>>> (My opinion is that being able to shadow fundamental language
>>> features is undesirable. Being able to reuse them as user identifiers
>>> is another matter, but that would involve tricks with syntax or
>>> context to avoid ambiguity.)
>>>
>>>
>>
>> The issue is where you draw the line of what is a "fundamental
>> language feature", and what is not. For Pascal, "begin" is a
>> fundamental language feature, part of the syntax. "odd" is not
>> fundamental - it's just a function in the Pascal's equivalent of the C
>> standard library. So no tricks or special syntax (like "stropping")
>> are needed to re-use the identifier for other purposes.
>>
>> I agree that using words that are "fundamental" is not good. But if a
>> language provides built-in functions in a global namespace, then it is
>> a serious limitation if these cannot be shadowed or overridden.
>
> I see it as an advantage. I can do this in Python:
>
> len = 42
> print(len("abc"))
>
> Now len() no longer works as expected. In Algo68 you can do this:
>
> OP + = (INT a, b)INT: a - b;
> print(2 + 3)
>
> This prints -1. (Or, more subtly, you can redefine the precedence of '+'
> to be the opposite side of '*'.)
>
> With different scopes in effect, different parts of a program can see
> different versions of what many might not realise are user-overrideable
> features.
>
I am not suggesting it is a good idea for a program to knowingly re-use
an identifier that is commonly used in the language for other things.
But sometimes there is a collision. The folks adding new functions or
features to a language or library do not usually know of all uses of
identifiers in existing code.
>
>> Basically, it means that you are always at risk of conflicts with
>> existing code if later language versions add new functions. So if
>> someone wrote Pascal code with a local variable called "even", and a
>> later version introduced a built-in function "even", then it is
>> critical that this is an overrideable or shadowable (if that is a real
>> word!) identifier.
>
> If 'even' is implemented as though it can be defined via a user-
> function) then shadowing is normally allowed (unless the language likes
> to warn you about such things).
>
> But if it's a true built-in that just happens to use function syntax,
> then the user sees an error. Then they can choose to update their
> codebase, when possible.
A choice between changing the codebase, or only being able to use old
tools or old language version is not a good choice for users.
Most modern languages support some kind of namespace, which solves this
problem. In C++, new functions are added to the std:: namespace which
will never be in conflict with user identifiers. Some of these will be
very similar to "true built-ins" in that the functions cannot be written
in the language itself, but require some kind of "compiler magic" to
work. That's okay - it doesn't matter to the user. (Behind the scenes,
a compiler might have the actual builtin with a secret name that users
should never see.)
>
> For somebody else's code, or for legacy code, that becomes harder, and
> the implementation may need to strictly enforce language versions so
> that such new features are disabled via the build info.
>
> Alternately, such built-ins can use special syntax so they would never
> clash with user-identifiers.
Namespaces are ideal for this. It's such a useful feature that it
should be available to users and third-party library writers, not just
the language and its standard libraries.
>
> Note that such clashes can also occur when mixing libraries: maybe both
> library A and B can export 'even', even when everything is defined in
> user-code.
>
Yes. No solution is ever going to prevent all identifier clashes. But
you can go a fair way to reducing the risk.
> Then the language had better have a namespace feature to disasmbiguate
> (which I have, but C doesn't)
>
Indeed. It's a serious limitation in C, and one reason for people
switching to C++. (Some people use C++ as "ABC" - "A better C". They
use namespaces, better "const", and a few other features, while avoiding
what they consider complex or potentially inefficient features.)
>
>> That's why C is very conservative about adding new keywords, and uses
>> reserved namespaces for the purpose - thus C99 added "_Bool", not
>> "bool", to avoid conflict with existing code. Only now, over two
>> decades later, did the committee feel that uses of the identifier
>> "bool" other than as a typedef for _Bool (usually via <stdbool.h>) are
>> so rare that C23 could finally have "bool" as a keyword for the type.
>> And they still have challenges with good names for standard library
>> functions - now in C23, many new ones have names with a "stdc_" prefix.
>>
>>
>
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-11-29 10:27 -0500 |
| Message-ID | <10gf3ci$1pe2v$1@dont-email.me> |
| In reply to | #395559 |
bart <bc@freeuk.com> wrote: > On 28/11/2025 23:23, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >>> On 28/11/2025 02:33, Janis Papanagnou wrote: >> [...] >>>> You can of course add as many commodity features to "your language" >>>> as you like. I seem to recall that one of the design principles of >>>> "C" was to not add too many keywords. (Not sure whether 'A.odd' is >>>> a function or keyword above [in "your language"].) >>> >>> It is a reserved word, which means it can't be used as either a >>> top-level user identifier, or a member name. With extra effort, it >>> could be used for both, but that needs some special syntax, such as >>> Ada-style "A'odd"; I've never got around to it. >>> >>> In Pascal (where I copied it from) it is a reserved word. >> >> <OT>In Pascal, "odd" is not a reserved word. It's the name of a >> predefined function.</OT> > > So what's a 'reserved word' then? To me it is something not available as > a user-identifier because it has a special meaning in the language, That's a general description, but at least in C, there's several different kinds of reserved identifiers, each kind specifies different restrictions on user code use of that identifier. Note: in C2023, the predefined Identifiers section says: "Any other predefined macro names: shall begin with a leading underscore followed by an uppercase letter; or, a second underscore...". For earlier versions of the standard, user code should avoid using such identifiers because they were reserved for all purposes, but that's no longer the case. Now, they should be avoided because they may be pre-defined by the implementation, which means that any attempt to use them might have unpredictable results. As a result, C no longer has any identifiers that are always reserved for any use, just ones that are reserved for particular uses under specified circumstances. > which may be that of a predefined function among other things. In C, identifiers with external linkage (which includes the names of all standard library functions) are reserved only as identifiers with external linkage, and only if the corresponding standard header is #included.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-29 16:29 -0800 |
| Message-ID | <87wm389xcc.fsf@example.invalid> |
| In reply to | #395569 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> Note: in C2023, the predefined Identifiers section says: "Any other
> predefined macro names: shall begin with a leading underscore followed
> by an uppercase letter; or, a second underscore...". For earlier
> versions of the standard, user code should avoid using such identifiers
> because they were reserved for all purposes, but that's no longer the
> case. Now, they should be avoided because they may be pre-defined by the
> implementation, which means that any attempt to use them might have
> unpredictable results.
That's in the "Predefined macro names" section (N3220 6.10.10.1).
The "Predefine identifiers" section (6.4.3.2) documents __func__.
There are no other predefined identifiers.
[...]
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-11-29 22:08 -0500 |
| Message-ID | <10ggcgc$3vdvh$2@dont-email.me> |
| In reply to | #395584 |
On 2025-11-29 19:29, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > [...] >> Note: in C2023, the predefined Identifiers section says: "Any other >> predefined macro names: shall begin with a leading underscore followed >> by an uppercase letter; or, a second underscore...". For earlier >> versions of the standard, user code should avoid using such identifiers >> because they were reserved for all purposes, but that's no longer the >> case. Now, they should be avoided because they may be pre-defined by the >> implementation, which means that any attempt to use them might have >> unpredictable results. > > That's in the "Predefined macro names" section (N3220 6.10.10.1). > > The "Predefine identifiers" section (6.4.3.2) documents __func__. > There are no other predefined identifiers. Aagh! Sorry.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-12-20 11:24 -0800 |
| Message-ID | <861pkpt0rz.fsf@linuxsc.com> |
| In reply to | #395569 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > bart <bc@freeuk.com> wrote: > >> On 28/11/2025 23:23, Keith Thompson wrote: >> >>> bart <bc@freeuk.com> writes: >>> >>>> On 28/11/2025 02:33, Janis Papanagnou wrote: >>> >>> [...] >>>>>>>> You can of course add as many commodity features to "your >>>>> language" as you like. I seem to recall that one of the design >>>>> principles of "C" was to not add too many keywords. (Not sure >>>>> whether 'A.odd' is a function or keyword above [in "your >>>>> language"].) >>>> >>>> It is a reserved word, which means it can't be used as either a >>>> top-level user identifier, or a member name. With extra effort, >>>> it could be used for both, but that needs some special syntax, >>>> such as Ada-style "A'odd"; I've never got around to it. >>>> >>>> In Pascal (where I copied it from) it is a reserved word. >>> >>> <OT>In Pascal, "odd" is not a reserved word. It's the name of a >>> predefined function.</OT> >> >> So what's a 'reserved word' then? To me it is something not >> available as a user-identifier because it has a special meaning in >> the language, > > That's a general description, but at least in C, there's several > different kinds of reserved identifiers, each kind specifies > different restrictions on user code use of that identifier. > > Note: in C2023, the [predefined macro names] section says: "Any other > predefined macro names: shall begin with a leading underscore > followed by an uppercase letter; or, a second underscore...". For > earlier versions of the standard, user code should avoid using such > identifiers because they were reserved for all purposes, but that's no > longer the case. Now, they should be avoided because they may be > pre-defined by the implementation, which means that any attempt to use > them might have unpredictable results. That's right in the sense that if the implementation is unknown then unexpected results may occur. However, if the implementation is known, then we can find out what results are expected by consulting the implementation's documentation for extensions, since any such macro name must qualify as an extension, and so much be documented. Note by the way that the description in N3220 section 6.10.10.1 paragraph 2 makes using #define or #undef be undefined behavior only for macro names in the subclause (and also a short list of other identifiers). Hence any other predefined macro name may be used, definedly, simply by using #undef and then #define for the macro name in question (in particular, under C23 rules, but not earlier versions of the C standard).
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-12-21 00:18 +0000 |
| Message-ID | <10i7ec6$3s49j$1@paganini.bofh.team> |
| In reply to | #395865 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> bart <bc@freeuk.com> wrote:
>>
>>> On 28/11/2025 23:23, Keith Thompson wrote:
>>>
>>>> bart <bc@freeuk.com> writes:
>>>>
>>>>> On 28/11/2025 02:33, Janis Papanagnou wrote:
>>>>
>>>> [...]
>>>>>>>>> You can of course add as many commodity features to "your
>>>>>> language" as you like. I seem to recall that one of the design
>>>>>> principles of "C" was to not add too many keywords. (Not sure
>>>>>> whether 'A.odd' is a function or keyword above [in "your
>>>>>> language"].)
>>>>>
>>>>> It is a reserved word, which means it can't be used as either a
>>>>> top-level user identifier, or a member name. With extra effort,
>>>>> it could be used for both, but that needs some special syntax,
>>>>> such as Ada-style "A'odd"; I've never got around to it.
>>>>>
>>>>> In Pascal (where I copied it from) it is a reserved word.
>>>>
>>>> <OT>In Pascal, "odd" is not a reserved word. It's the name of a
>>>> predefined function.</OT>
>>>
>>> So what's a 'reserved word' then? To me it is something not
>>> available as a user-identifier because it has a special meaning in
>>> the language,
>>
>> That's a general description, but at least in C, there's several
>> different kinds of reserved identifiers, each kind specifies
>> different restrictions on user code use of that identifier.
>>
>> Note: in C2023, the [predefined macro names] section says: "Any other
>> predefined macro names: shall begin with a leading underscore
>> followed by an uppercase letter; or, a second underscore...". For
>> earlier versions of the standard, user code should avoid using such
>> identifiers because they were reserved for all purposes, but that's no
>> longer the case. Now, they should be avoided because they may be
>> pre-defined by the implementation, which means that any attempt to use
>> them might have unpredictable results.
>
> That's right in the sense that if the implementation is unknown then
> unexpected results may occur. However, if the implementation is
> known, then we can find out what results are expected by consulting
> the implementation's documentation for extensions, since any such
> macro name must qualify as an extension, and so much be documented.
Hmm, looking at '/usr/include/string.h' on my machine I see definitions
of things like
__GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION
__need_size_t
and lot of similar things. I do not recall seeing any user
documentation listing them. Does this mean that gcc+glibc
is noncompilant in this aspect?
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-12-21 23:07 -0800 |
| Message-ID | <86h5tjro38.fsf@linuxsc.com> |
| In reply to | #395867 |
antispam@fricas.org (Waldek Hebisch) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> >>> bart <bc@freeuk.com> wrote: >>> >>>> On 28/11/2025 23:23, Keith Thompson wrote: >>>> >>>>> bart <bc@freeuk.com> writes: >>>>> >>>>>> On 28/11/2025 02:33, Janis Papanagnou wrote: >>>>> >>>>> [...] >>>>> >>>>>>>>>> You can of course add as many commodity features to "your >>>>>>> >>>>>>> language" as you like. I seem to recall that one of the design >>>>>>> principles of "C" was to not add too many keywords. (Not sure >>>>>>> whether 'A.odd' is a function or keyword above [in "your >>>>>>> language"].) >>>>>> >>>>>> It is a reserved word, which means it can't be used as either a >>>>>> top-level user identifier, or a member name. With extra effort, >>>>>> it could be used for both, but that needs some special syntax, >>>>>> such as Ada-style "A'odd"; I've never got around to it. >>>>>> >>>>>> In Pascal (where I copied it from) it is a reserved word. >>>>> >>>>> <OT>In Pascal, "odd" is not a reserved word. It's the name of a >>>>> predefined function.</OT> >>>> >>>> So what's a 'reserved word' then? To me it is something not >>>> available as a user-identifier because it has a special meaning in >>>> the language, >>> >>> That's a general description, but at least in C, there's several >>> different kinds of reserved identifiers, each kind specifies >>> different restrictions on user code use of that identifier. >>> >>> Note: in C2023, the [predefined macro names] section says: "Any other >>> predefined macro names: shall begin with a leading underscore >>> followed by an uppercase letter; or, a second underscore...". For >>> earlier versions of the standard, user code should avoid using such >>> identifiers because they were reserved for all purposes, but that's no >>> longer the case. Now, they should be avoided because they may be >>> pre-defined by the implementation, which means that any attempt to use >>> them might have unpredictable results. >> >> That's right in the sense that if the implementation is unknown then >> unexpected results may occur. However, if the implementation is >> known, then we can find out what results are expected by consulting >> the implementation's documentation for extensions, since any such >> macro name must qualify as an extension, and so much be documented. > > Hmm, looking at '/usr/include/string.h' on my machine I see definitions > of things like > > __GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION > __need_size_t > > and lot of similar things. I do not recall seeing any user > documentation listing them. Does this mean that gcc+glibc > is noncompilant in this aspect? I think it's reasonable to say that the appearance of a macro name being #define'd in a standard header qualifies as documenting the name being #define'd. As long as the #define is readable in an ordinary source file, there isn't any mystery about the name being used or what its definition is. I suppose that to satisfy the letter of the C standard, the accompanying document would need to incorporate the system header files by reference, but surely the header files satisfy the spirit of providing the required documentation. Implementation-defined values for things like CHAR_BIT and INT_MAX fall under the same rule for documentation as do extensions, yet as far as I know these values are defined only in system header files, and not in any separate document.
[toc] | [prev] | [next] | [standalone]
Page 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web