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 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-22 02:51 -0800 |
| Message-ID | <87ecomx013.fsf@example.invalid> |
| In reply to | #395877 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> antispam@fricas.org (Waldek Hebisch) writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
>>>> 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.
I disagree. I don't think it's reasonable to say that.
Headers are not documentation. They're often barely human-readable,
and the system headers aren't necessarily even files.
> 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.
System headers can be arbitrarily complex, with #includes for other
system-specific headers, nests of #ifs and #ifdefs, and so on.
> 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.
gcc's documentation does have a "C Implementation-Defined Behavior"
section. It doesn't mention CHAR_BIT by name, but it does document
"The number of bits in a byte" as "Determined by ABI". I didn't
find anything similar for INT_MAX.
I find it implausible that the standard intended to require
implementations to document all macros defined in standard headers,
for example _STDIO_H, the include guard macro for <stdio.h> in glibc.
C17 says:
All identifiers that begin with an underscore and either an
uppercase letter or another under- score are always reserved for
any use, except those identifiers which are lexically identical
to keywords.
C23 dropped that wording. I'm not convinced that all the
implications of that change were resolved properly (but I haven't
studied it thoroughly).
--
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 | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2025-12-22 19:23 +0000 |
| Message-ID | <20251222111640.565@kylheku.com> |
| In reply to | #395880 |
On 2025-12-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> antispam@fricas.org (Waldek Hebisch) writes: >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: > [...] >>>>> 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. > > I disagree. I don't think it's reasonable to say that. > > Headers are not documentation. It makes no sense for a file to be a document, just because it is part of the implementation, ipso facto. A binary executable contains text written in a machine language that we can read and understand---some people without the aid of a disassembler, even. It does not therefore follow that a compiler executable is documentation. No artifact delivered by the implementor is part of the documentation unless it is designated as such. A header file is documentation if the implementor indicates it as a document, otherwise not. And then, it may be that only certain designated and delimited parts of the header file are indicated as documentation. For instance, some other document may direct the reader to read the block comments in a certain header file. Then only block comments are documentation, and not any definitions outside of comments. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-01-07 03:01 -0800 |
| Message-ID | <86v7hdptys.fsf@linuxsc.com> |
| In reply to | #395880 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> antispam@fricas.org (Waldek Hebisch) writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: > > [...] > >>>>> 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. > > I disagree. I don't think it's reasonable to say that. Some people think it's reasonable. It's okay if you don't. > Headers are not documentation. They're often barely human-readable, > and the system headers aren't necessarily even files. Yes, I might have said "standard header file", with the understanding that the files in question are encoded in regular ascii. There isn't any requirement that the document(s) be easy to read. >> 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. > > System headers can be arbitrarily complex, with #includes for other > system-specific headers, nests of #ifs and #ifdefs, and so on. As long as they define all implementation-defined characteristics (and I suppose can be understood by humans), how complex they are doesn't matter. That's a QOI issue, not a conformance issue. >> 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. > > gcc's documentation does have a "C Implementation-Defined Behavior" > section. It doesn't mention CHAR_BIT by name, but it does document > "The number of bits in a byte" as "Determined by ABI". I didn't > find anything similar for INT_MAX. > > I find it implausible that the standard intended to require > implementations to document all macros defined in standard headers, The language in the C standard is clearcut: "An implementation shall be accompanied by a document that defines all implementation-defined and locale-specified characteristics and all extensions." If gcc (together with glibc) doesn't provide such a document, that defines ALL implementation-defined characteristics, etc, and system header files don't count, then that implementation is not conforming. See also my followup to James Kuyper in a closely related sub-thread.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-20 18:22 -0800 |
| Message-ID | <87v7i0fub0.fsf@example.invalid> |
| In reply to | #395865 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
>> 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).
I don't *think* that all implementation-specific predefined macros have
to be documented -- at least, I'd be surprised if that were the intent.
For example, I don't think an implementation is required to document its
use of _STDIO_H (the include guard header in the glibc implementation of
<stdio.h>).
Though it's not normative, N3220 J.5.1 (Common extensions) says:
Examples of such extensions are new keywords, extra library
functions declared in standard headers, or predefined macros with
names that do not begin with an underscore.
--
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 | 2026-01-06 21:57 -0800 |
| Message-ID | <86zf6qothu.fsf@linuxsc.com> |
| In reply to | #395869 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: > > [...] > >>> 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). > > I don't *think* that all implementation-specific predefined macros have > to be documented -- at least, I'd be surprised if that were the intent. > > For example, I don't think an implementation is required to document its > use of _STDIO_H (the include guard header in the glibc implementation of > <stdio.h>). > > Though it's not normative, N3220 J.5.1 (Common extensions) says: > > Examples of such extensions are new keywords, extra library > functions declared in standard headers, or predefined macros with > names that do not begin with an underscore. I gave a clarifying response to this question in my recent followup to the post from James Kuyper.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-12-20 21:27 -0500 |
| Message-ID | <10i7luj$2e4g0$1@dont-email.me> |
| In reply to | #395865 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: ... >> 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. J.5 identifies as extensions only "... predefined macros with names that do not begin with an underscore." (J.5, J.5.13) They are not identified as implementation-defined, so there is no obligation to document them. Portable code must,of course simply avoid all such identifiers.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-01-06 21:51 -0800 |
| Message-ID | <864ioyq8bn.fsf@linuxsc.com> |
| In reply to | #395870 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: > > ... > >>> 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. > > J.5 identifies as extensions only "... predefined macros with names that > do not begin with an underscore." (J.5, J.5.13) That doesn't invalidate what I said. And anyway Annex J is only informative, not normative. > They are not identified as implementation-defined, so there is no > obligation to document them. Let me clarify my earlier comment. An implementation is free to accept almost anything at all, as long as a diagnostic is issued. But any usage[*] that would otherwise be a syntax error or violate a constraint, if accepted without issuing a diagnostic, must be an extension and so must be documented. [*] an ordinary use, not a declaring or defining use.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2025-12-21 02:27 +0000 |
| Message-ID | <20251220181805.887@kylheku.com> |
| In reply to | #395865 |
On 2025-12-20, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > 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). If that interpretation is accurate, it is a serious problem. The implementation must be prepared for the situation that any of its internal macros are undefined, or undefined and redefined. That means that other macros cannot rely on those macros. Some documented macro foo() cannot rely on a __foo_impl() macro because the program could #undef that. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-12-21 22:48 -0800 |
| Message-ID | <86ldivroyu.fsf@linuxsc.com> |
| In reply to | #395871 |
Kaz Kylheku <046-301-5902@kylheku.com> writes: > On 2025-12-20, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> 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). > > If that interpretation is accurate, it is a serious problem. Yes, very serious. I suspect the change is simply an oversight on the part of those responsible for the wording in the C23 standard. > The implementation must be prepared for the situation that any of its > internal macros are undefined, or undefined and redefined. > > That means that other macros cannot rely on those macros. > Some documented macro foo() cannot rely on a __foo_impl() > macro because the program could #undef that. Probably there are other ways to work around the problem, but it does seem better just to avoid the problem altogether by forbidding definitions (or #undef) of any reserved identifiers, including macro names.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-11-29 03:26 +0100 |
| Message-ID | <10gdll9$2652m$1@dont-email.me> |
| In reply to | #395548 |
On 28/11/2025 12.49, bart wrote: > On 28/11/2025 02:33, Janis Papanagnou wrote: > >> 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. (If you know in what areas you commonly make mistakes you can work on that! - Just a suggestion to think about.) > >> 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. As far as I recall, in Pascal it's a predefined function! - The difference is that you cannot use reserved words as identifiers. (It's similar, but not necessarily, with keywords; depending on the language.) That was basically also the background of my explanation; to my knowledge "C" didn't want to introduce too many reserved words that as a consequence then cannot be used as "language entity" names (like variables, function names, etc.) any more. - That's why introducing simple high-level functions unnecessarily may be deprecated. > >> 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'. But it's the same with 'odd'; you can trivially write it as an boolean or as an arithmetic expression, whatever one prefers. And that also doesn't explain why 'odd' is considered a "relic" by Marcel. (I can only explain that opinion as I've done above.) The point in Algol 68 is, though, even more relaxed; since you have stropping there the conflicts of keywords with identifiers aren't what they are in other languages. Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-11-29 03:32 +0100 |
| Message-ID | <10gdm04$2652n$1@dont-email.me> |
| In reply to | #395561 |
On 29/11/2025 03.26, Janis Papanagnou wrote: > ... > > That was basically also the background of my explanation; to my > knowledge "C" didn't want to introduce too many reserved words > that as a consequence then cannot be used as "language entity" > names (like variables, function names, etc.) any more. - That's > why introducing simple high-level functions unnecessarily may be > deprecated. Please ignore the last sentence. - I was speaking about reserved words or keywords and not about function names in the context of the paragraph. - So it depends in what way you introduce elements like 'odd'. As a "C" function it wouldn't matter much. In case of "your language" - where you say it's a keyword! - it would matter, though! Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-29 12:24 +0000 |
| Message-ID | <10geolb$3ab2u$2@dont-email.me> |
| In reply to | #395562 |
On 29/11/2025 02:32, Janis Papanagnou wrote:
> On 29/11/2025 03.26, Janis Papanagnou wrote:
>> ...
>>
>> That was basically also the background of my explanation; to my
>> knowledge "C" didn't want to introduce too many reserved words
>> that as a consequence then cannot be used as "language entity"
>> names (like variables, function names, etc.) any more. - That's
>> why introducing simple high-level functions unnecessarily may be
>> deprecated.
>
> Please ignore the last sentence. - I was speaking about reserved
> words or keywords and not about function names in the context of
> the paragraph. - So it depends in what way you introduce elements
> like 'odd'. As a "C" function it wouldn't matter much. In case of
> "your language" - where you say it's a keyword! - it would matter,
> though!
My syntax actually has a stropping mechanism, but it is applied to
user-identifiers.
That's for when you really want to use a reserved as an identifier, for
example if porting code from another language, or machine translation.
So this is possible:
int `odd := 3
if `odd.odd then
It is also case-preserving (syntax is usually case-insensitive):
int `int, `INT, `Int # three different variables
And (I've just discovered this), it be used when identifiers either
start with a digit, or are numbers:
int `1234 := 1235
But this is generally ugly and undesirable; you only do this as a last
resort. (The feature is most heavily used in machine-generated assembly.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-11-28 09:48 -0500 |
| Message-ID | <10gccn6$1pe2t$1@dont-email.me> |
| In reply to | #395531 |
On 2025-11-27 12: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" ? Probably a typo for A % 2. Note to bart: A%2 has a value of -1 for odd negative numbers. In many contexts (#if, !, &&, ||, ?:, if(), for(), while(), do while(), assert(), or static_assert()), all that matters is that it's not equal to 0. However, any time you're looking at the actual value, A&1 and A%2 are not equivalent.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-28 11:41 +0100 |
| Message-ID | <10gbu8h$2a9uq$1@dont-email.me> |
| In reply to | #395530 |
On 27/11/2025 18:13, bart wrote: > On 27/11/2025 13:02, David Brown wrote: >> On 27/11/2025 13:20, bart wrote: > I'm snipping most of this, because I don't think we are getting anywhere except down angry rabbit holes. Most of what we both have written has been said many times before, and I don't want to re-hash old fights. They bring out the worst in both of us, and we both get frustrated and annoyed. I'd rather reset the conversation before it gets out of hand, and go back to exchanging opinions and ideas, and helping out. >>> (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. You are not the first person to mix that up on godbolt.org, with a different language and/or compiler from what you thought you had. I usually make a point of explicitly specifying the standard in the command line arguments - that means there is no doubt about what I am asking for. And if you specify a C standard with g++, you will get an error message (unless you also use "-x c" to tell g++ that you have C code). My standard options are : -std=c17 -Wall -Wextra -Wpedantic -O2 Of course I will vary the standard according to need - so for looking at _BitInt, I have -std=c23. I sometimes use -std=gnu17 or similar when I specifically want to use gcc extensions - in which case "-Wpedantic" is basically pointless. And for C++, I use appropriate C++ standards. Note that without an explicit "-std=" option, gcc will use a "gnuXX" version that depends on the compiler version. Thus gcc extensions are accepted by default. "-Wall -Wextra" enable lots of warnings. For real work, I have fine-tuned warning sets - I don't want all of these sets, and I want some warnings that are not in these sets, but they give a good starting point for code snippets on godbolt. "-Wpedantic" gives warnings on deviations from the standard. It will give you warnings if you accidentally use a gcc extension (such as using compound literals in C++). I don't think gcc is perfectly conforming with "-std=c?? -Wpedantic", but it is as close as any other compiler I have seen, and is IMHO the best starting point for checks. And I almost always have -O2. -O3 can sometimes lead to overwhelming amounts of extra inline code that make the assembly hard to follow. -O0 generates unreadably bad assembly. -O1 is easier to follow. But for me, -O2 is generally the sweet spot. I have no real interest in using a compiler that doesn't do decent optimisation - if I am happy with slow code, I'll use Python.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-28 19:46 +0000 |
| Message-ID | <10gcu73$2nrb3$1@dont-email.me> |
| In reply to | #395545 |
On 28/11/2025 10:41, David Brown wrote:
> But for
> me, -O2 is generally the sweet spot. I have no real interest in using a
> compiler that doesn't do decent optimisation - if I am happy with slow
> code, I'll use Python.
>
That's like saying that if you can't go at 100mph, you're happy to walk!
There's no compromise at all?
I've taken a task (decode JPEG) which uses the same algorithm across
three languages, and applied it to the same input. These are the
runtimes, expressed in relative MPH:
Drive 1 mile:
gcc -O3 C 108 mph 33s
gcc -O2 C 100 mph 36s
mm M 77 mph (my lang) 47s
bcc C 55 mph (my product) 1m 05s
tcc C 25 mph 2m 24s
CPython Python 0.8 mph 1h 15m 00s
Actually, forget walking: you'd rather crawl on your hands on knees!
(The figure for PyPy for this task, which has lots of long loops to get
stuck into, is 19 mph, but the speedup is generally unpredictable.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-28 21:58 +0100 |
| Message-ID | <10gd2cs$2pa1g$1@dont-email.me> |
| In reply to | #395555 |
On 28/11/2025 20:46, bart wrote: > On 28/11/2025 10:41, David Brown wrote: > > >> But for me, -O2 is generally the sweet spot. I have no real >> interest in using a compiler that doesn't do decent optimisation - if >> I am happy with slow code, I'll use Python. >> > > That's like saying that if you can't go at 100mph, you're happy to walk! > > There's no compromise at all? My work is mainly on microcontrollers, where efficient code is critical (x86 processors are good at running unoptimised code quickly, microcontrollers are not). And some of my work is programming on PC's, where it is rarely important - it makes more sense to use a language targeting faster development time than faster runtime. (The bulk of the time spent when running Python code is in libraries, OS calls, waiting for disks, IO, networks, etc.) I'm sure plenty of people have use for "medium speed" languages, but I don't see it for what I do. Actually, the same goes for travelling. I'm happy to go out for a walk, but if I am trying to get somewhere at a distance, I'll drive. I've never thought "what I really want here to go to the shops is a car with a max speed of 30 mph". > > I've taken a task (decode JPEG) which uses the same algorithm across > three languages, and applied it to the same input. These are the > runtimes, expressed in relative MPH: > > Drive 1 mile: > gcc -O3 C 108 mph 33s > gcc -O2 C 100 mph 36s > mm M 77 mph (my lang) 47s > bcc C 55 mph (my product) 1m 05s > tcc C 25 mph 2m 24s > CPython Python 0.8 mph 1h 15m 00s > > Actually, forget walking: you'd rather crawl on your hands on knees! > > (The figure for PyPy for this task, which has lots of long loops to get > stuck into, is 19 mph, but the speedup is generally unpredictable.) > > I don't write jpeg decoders on PC's. I very rarely write code that has to be fast on a PC. (It has happened occasionally - but usually then I use existing fast code like numpy to do the heavy lifting.) On the few occasions that I write C or C++ code on PC's, I use optimisation. For one thing, it gives better static error checking. And while I probably am not too bothered about the speed differences, it's just hard for me to purposefully and pointlessly pessimise code.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-27 15:59 -0800 |
| Message-ID | <87ecpjhvse.fsf@example.invalid> |
| In reply to | #395523 |
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);
>> }
>> 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.)
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.
--
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-28 00:11 +0000 |
| Message-ID | <10gapc8$1tj26$1@dont-email.me> |
| In reply to | #395536 |
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);
>>> }
>>> 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.)
>
> 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.
>
I said in a followup that I'd been using a C++ compiler by mistake (this
was on Godbolt).
That gcc's C++ compiler accepted the code wasn't helpful.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-27 16:39 -0800 |
| Message-ID | <87a507htwo.fsf@example.invalid> |
| In reply to | #395537 |
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 said in a followup that I'd been using a C++ compiler by mistake
> (this was on Godbolt).
>
> That gcc's C++ compiler accepted the code wasn't helpful.
But not surprising, since as you know gcc (and likewise g++) is
not fully conforming by default. If you're compiling code with the
purpose of making a point about the language, invoke the compiler
in standard-conforming mode. And if a compiler "doesn't like"
the code you feed it, at least show us the diagnostic messages.
--
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-28 01:49 +0000 |
| Message-ID | <10gav3o$1vfij$1@dont-email.me> |
| In reply to | #395538 |
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.
[toc] | [prev] | [next] | [standalone]
Page 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web