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 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-24 22:27 +0000 |
| Message-ID | <10g2m3v$2s5sa$1@dont-email.me> |
| In reply to | #395434 |
On 24/11/2025 20:26, David Brown wrote: > On 24/11/2025 19:35, bart wrote: >> There is just the poor gnu extension where 128-bit integers didn't >> have a literal form, and there was no way to print such values. >> > > How many times have you felt the need to write a 128-bit literal? And > how many times has that literal been in decimal I don't think there were hex literals either. > (it's not difficult to > put together a 128-bit value from two 64-bit values)? You really are > making a mountain out of a molehill here. Well, it seems that such literals now exist (with 'wb' suffix). So I guess somebody other than you decided that feature WAS worth adding! But you can't as yet print out such values; I guess you can't 'scanf' them either. These are necessary to perform I/O on such data from/to text files. I must say you have a very laidback attibute to language design: "Let's add this 128-bit type, but let's not bother providing a way to enter such values, or add any facilities to print them out. How often would somebody need to do that anyway? But if they really /have/ to, then there are plenty of hoops they can jump through to achieve it!" (In my implementation of 128-bit types, from 2021, I allowed full 128-bit decimal, hex and binary literals, and they could be printed in any base. But they weren't used enough and were dropped, in favour of an unlimited precision type in my other language. On interesting use-case for literals was short-strings; 128 bits allowed character literals up to 16 characters: 'ABCDEFGHIJKLMNOP'. I think C is still stuck at one, or 4 if you're lucky.) >> But now there is this huge leap, not only to 128/256/512/1024 bits, >> but to conceivably millions, plus the ability to specify any weird >> type you like, like 182 bits (eg. somebody makes a typo for >> _BitInt(128), but they silently get a viable type that happens to be a >> little less efficient!). >> > > And this huge leap also lets you have 128-bit, 256-bit, 512-bit, etc., And 821 bits. This is what I don't get. Why is THAT so important? Why couldn't 128/256/etc have been added first, and then those funny ones if the demand was still there? If the proposal had instead been simply to extend the 'u8 u16 u32 u64' set of types by a few more entries on the right, say 'u128 u256 u512', would anyone have been clamouring for types like 'u1187'? I doubt it. For sub-64-bit types on conventional hardware, I simply can't see the point, not if they are rounded up anyway. Either have a full range-based types like Ada, or not at all.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-24 18:10 -0800 |
| Message-ID | <878qfu3lru.fsf@example.invalid> |
| In reply to | #395436 |
bart <bc@freeuk.com> writes:
> On 24/11/2025 20:26, David Brown wrote:
[...]
>> And this huge leap also lets you have 128-bit, 256-bit, 512-bit,
>> etc.,
>
> And 821 bits. This is what I don't get. Why is THAT so important?
>
> Why couldn't 128/256/etc have been added first, and then those funny
> ones if the demand was still there?
Because a more general definition, allowing all widths up to some
maximum, is *simpler* than a definition with arbitrary restrictions.
And since it's already been implemented, what the heck are you
complaining about?
> If the proposal had instead been simply to extend the 'u8 u16 u32 u64'
> set of types by a few more entries on the right, say 'u128 u256 u512',
> would anyone have been clamouring for types like 'u1187'? I doubt it.
You do know that u8, u16, et al are not C types, right? (Yes, I know
what you mean by those names.)
> For sub-64-bit types on conventional hardware, I simply can't see the
> point, not if they are rounded up anyway. Either have a full
> range-based types like Ada, or not at all.
Great, so don't use them.
If the ISO C committee withdrew the current official 2023 standard
document and replaced it with one that imposes restrictions on _BitInt
types, and gcc and clang withdrew their implementations, would that
satisfy you?
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-25 21:25 +0100 |
| Message-ID | <10g53au$3onvh$1@dont-email.me> |
| In reply to | #395436 |
On 24/11/2025 23:27, bart wrote: > On 24/11/2025 20:26, David Brown wrote: >> On 24/11/2025 19:35, bart wrote: > >>> There is just the poor gnu extension where 128-bit integers didn't >>> have a literal form, and there was no way to print such values. >>> >> >> How many times have you felt the need to write a 128-bit literal? And >> how many times has that literal been in decimal > > I don't think there were hex literals either. > > >> (it's not difficult to put together a 128-bit value from two 64-bit >> values)? You really are making a mountain out of a molehill here. > > Well, it seems that such literals now exist (with 'wb' suffix). So I > guess somebody other than you decided that feature WAS worth adding! > > But you can't as yet print out such values; I guess you can't 'scanf' > them either. These are necessary to perform I/O on such data from/to > text files. > > I must say you have a very laidback attibute to language design: > > "Let's add this 128-bit type, but let's not bother providing a way to > enter such values, or add any facilities to print them out. How often > would somebody need to do that anyway? But if they really /have/ to, > then there are plenty of hoops they can jump through to achieve it!" > > (In my implementation of 128-bit types, from 2021, I allowed full 128- > bit decimal, hex and binary literals, and they could be printed in any > base. > > But they weren't used enough and were dropped, in favour of an unlimited > precision type in my other language. > > On interesting use-case for literals was short-strings; 128 bits allowed > character literals up to 16 characters: 'ABCDEFGHIJKLMNOP'. I think C is > still stuck at one, or 4 if you're lucky.) > I have no idea or opinion on why /you/ might want 128-bit or larger integer types. I believe there is very little use for "normal" numbers - things you might want to write as literals, calculate with, and read or write - that won't fit perfectly well within 64 bit types, and would not be better served by arbitrary sized integers. Arbitrary sized integers are a very different kettle of fish from large fixed-size integers, and are not something that would fit in the C language - they need a library. I can tell you why /I/ might find larger integer types useful. They include : * 128-bit for IPv6 address. These use a variety of styles for input and display, and thus would use specialised routines, not simple literals or printf-style IO. * Big units for passing data around with larger memory transfers, using SIMD registers. IO is irrelevant here. * Cryptography. IO is irrelevant here. But a variety of sizes are useful including 56, 80, 112, 128, 168, 192, 384, 512, 521, 2048, 3072, 4096, 7680, 8096 bits. There may be more common sizes - I'm just thinking of DES, 3DES, AES, SHA, ECC and RSA. Smaller sizes can be useful for holding RGB pixel values, audio data, etc. In none of these cases are bit-precise integer types essential. People have been doing cryptography for a long time without them. But they can be convenient, and help people write code that is simpler, clearer, or more directly expresses their intent. The only specific additional power you get from these is that you can do arithmetic on bigger types without having to write the code manually. I don't know if compilers currently do a good enough job for that to be suitable for multiplication and modulo of larger integers (addition is easy, but for big sizes, smarter multiplication techniques can be a significant performance gain). But those are just the uses /I/ see for them, in things /I/ work with. (I might also use them for FPGA programming in the future, but I'm not doing that at the moment.) However, unlike some people, I don't think the C language should pick features based purely on what I personally want to use, or what would be even sillier, what I personally think is easy to implement in a compiler. Other people will have other uses for different sizes. > >>> But now there is this huge leap, not only to 128/256/512/1024 bits, >>> but to conceivably millions, plus the ability to specify any weird >>> type you like, like 182 bits (eg. somebody makes a typo for >>> _BitInt(128), but they silently get a viable type that happens to be >>> a little less efficient!). >>> >> >> And this huge leap also lets you have 128-bit, 256-bit, 512-bit, etc., > > And 821 bits. This is what I don't get. Why is THAT so important? > > Why couldn't 128/256/etc have been added first, and then those funny > ones if the demand was still there? The folks behind the proposal provided both. The fact that you can write _BitInt(821) does not in any way hinder use of _BitInt(256). I really don't get your problem here. > > If the proposal had instead been simply to extend the 'u8 u16 u32 u64' > set of types by a few more entries on the right, say 'u128 u256 u512', > would anyone have been clamouring for types like 'u1187'? I doubt it. /You/ might not have wanted them, but other people would. > > For sub-64-bit types on conventional hardware, I simply can't see the > point, not if they are rounded up anyway. Either have a full range-based > types like Ada, or not at all. > Fortunately for the C world, you are not on the C committee - it doesn't matter if you can't see beyond the end of your nose.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-25 21:58 +0000 |
| Message-ID | <10g58pa$3r273$1@dont-email.me> |
| In reply to | #395478 |
On 25/11/2025 20:25, David Brown wrote:
> On 24/11/2025 23:27, bart wrote:
>> On interesting use-case for literals was short-strings; 128 bits
>> allowed character literals up to 16 characters: 'ABCDEFGHIJKLMNOP'. I
>> think C is still stuck at one, or 4 if you're lucky.)
>>
>
> I have no idea or opinion on why /you/ might want 128-bit or larger
> integer types. I believe there is very little use for "normal" numbers
> - things you might want to write as literals, calculate with, and read
> or write - that won't fit perfectly well within 64 bit types, and would
> not be better served by arbitrary sized integers.
> Arbitrary sized
> integers are a very different kettle of fish from large fixed-size
> integers, and are not something that would fit in the C language - they
> need a library.
Really? I wouldn't have thought there was any appreciable difference
between the code for multiplying two 100,000-bit BitInts, and that for
multiplying two abitrary-precision ints that happen to be 100,000 bits.
Maybe the latter is autoranging, and might give a 200,000-bit result.
Presumably the former doesn't use inline code, so it would be surprising
if each distinct size of BitInt had dedicated sets of routines for this.
So it sounds like they have to use a generic library anyway.
And sure enough, gcc-generated code contains stuff like this:
mov r8, rcx
mov edx, 50000 # (BitInt(50000)
mov rcx, rax
call __mulbitint3
So, BitInts are different in that they /don't/ need a library?
>
> I can tell you why /I/ might find larger integer types useful. They
> include :
>
> * 128-bit for IPv6 address. These use a variety of styles for input and
> display, and thus would use specialised routines, not simple literals or
> printf-style IO.
So, a better fit for a struct then? Here I'm curious as to what
BitInt(128) brings to the table.
> * Big units for passing data around with larger memory transfers, using
> SIMD registers. IO is irrelevant here.
Structs and arrays again spring to mind if you just want an anonymous
data block. (I wonder why it has to be bit-precise for byte-addressed
memory?)
> * Cryptography. IO is irrelevant here. But a variety of sizes are
> useful including 56, 80, 112, 128, 168, 192, 384, 512, 521, 2048, 3072,
> 4096, 7680, 8096 bits. There may be more common sizes - I'm just
> thinking of DES, 3DES, AES, SHA, ECC and RSA.
And I'm again curious as to what /non-numeric/ use a 200,000-bit BitInt
might be put to, that is not better served by an array or struct.
Maybe bit-sets? But there are no special features for accessing
individual bits.
That BigInt() defaults to a signed integer (twos complement?), even for
very large sizes suggests that /numeric/ applications are a primary use.
>
>
> Smaller sizes can be useful for holding RGB pixel values, audio data, etc.
Except that these are probably rounded up, to the next multiple of two.
So the benefit is minimal; it do something with those padding bits.
>> And 821 bits. This is what I don't get. Why is THAT so important?
>>
>> Why couldn't 128/256/etc have been added first, and then those funny
>> ones if the demand was still there?
>
> The folks behind the proposal provided both. The fact that you can
> write _BitInt(821) does not in any way hinder use of _BitInt(256). I
> really don't get your problem here.
You've heard of 'code smell'? Well, this is the same, but for features.
I've been doing this stuff long enough to recognise when a feature is
over-elaborate, over-specified and over-flexible. You need to know the
minimum you can get away with, not the maximum!
Let me guess, some committee members have been looking too long at how
C++ does things? That language is utterly incapable of creating anything
small and simple.
>>
>> If the proposal had instead been simply to extend the 'u8 u16 u32 u64'
>> set of types by a few more entries on the right, say 'u128 u256 u512',
>> would anyone have been clamouring for types like 'u1187'? I doubt it.
>
> /You/ might not have wanted them, but other people would.
OK, so why are you not allowed to have _BitInt(1)? That is, a 1-bit
signed integer. It might only have two values of 0 and -1; doesn't
nobody want that particular combination?
>>
>> For sub-64-bit types on conventional hardware, I simply can't see the
>> point, not if they are rounded up anyway. Either have a full range-
>> based types like Ada, or not at all.
>>
>
> Fortunately for the C world, you are not on the C committee - it doesn't
> matter if you can't see beyond the end of your nose.
Maybe unfortunately. C used to be a fairly simple language with a lot of
baggage; now it's a much heftier one with a lot of baggage!
At least, I've been able to add to my collection of C types that
represent an 8-bit byte:
signed char
unsigned char
int8_t
uint8_t
_BitInt(8)
unsigned _BitInt(8)
The last two are apparently incompatible with the char versions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-25 15:20 -0800 |
| Message-ID | <877bvdk8c4.fsf@example.invalid> |
| In reply to | #395484 |
bart <bc@freeuk.com> writes:
> On 25/11/2025 20:25, David Brown wrote:
[...]
>> Arbitrary sized integers are a very different kettle of fish from
>> large fixed-size integers, and are not something that would fit in
>> the C language - they need a library.
>
> Really? I wouldn't have thought there was any appreciable difference
> between the code for multiplying two 100,000-bit BitInts, and that for
> multiplying two abitrary-precision ints that happen to be 100,000
> bits.
It's not about the code that implements multiplication. In gcc, that's
done by calling a built-in function that can operate on arbitrary data
widths.
Think about memory management.
A _BitInt(128) object has a fixed size, like a struct. It can be
allocated locally ("on the stack"), passed to a function, returned
as a function result, used in expressions, etc. Likewise for
_BitInt(2048).
A hypothetical _BitInt(*) object would require an amount of storage
that varies with its current value. That storage would have to be
allocated using malloc() or equivalent, and deallocated using free()
or equivalent. C++ template classes with automatically invoked
constructors and destructors are great for that kind of thing.
C has no such mechanisms, and there's little support for adding
it just for this feature. (There are C container libraries.
I haven't used them, but they tend to require construction and
destruction to be explicit.)
Perhaps a future standard will provide a more flexible flavor of
_BitInt. It might allow the n in _BitInt(n) to be non-constant, or
empty, or "*", to denote an arbitrary-precision integer. But it's
hard to see how that could be done without adding other fundamental
features to the language. And a lot of people's response would be
that if you want C++, you know where to find it.
Similarly, C99 added complex types as a built-in language feature.
C++ added complex types as a template class, because C++ has language
features that support that kind of thing, including user-defined
literals.
If you can think of a way to add arbitrary-precision integers to C
without other radical changes to the language, let us know.
It could also be nice to be able to write code that deals with
multiple widths of _BitInt types, as we can do for arrays even
without VLAs. But C's treatment of arrays is messy, and I'm not
sure duplicating that mess for _BitInt types would be a great idea.
And I wouldn't want to lose the ability to pass _BitInt values
to functions.
[...]
> So, a better fit for a struct then? Here I'm curious as to what
> BitInt(128) brings to the table.
It brings a 128-bit integer type with constants and straightforward
assignment, comparison, and arithmetic operators.
[...]
> That BigInt() defaults to a signed integer (twos complement?), even
> for very large sizes suggests that /numeric/ applications are a
> primary use.
Yes, C23 requires two's-complement for signed integers. (It mandates
two's-complement representation, not wraparound behavior; signed
overflow is still UB).
[...]
> OK, so why are you not allowed to have _BitInt(1)? That is, a 1-bit
> signed integer. It might only have two values of 0 and -1; doesn't
> nobody want that particular combination?
I don't know. The language allows 1-bit signed bit-fields, so
_BitInt(1) would make some sense, but the language requires N to
be at least 1 for unsigned _BitInt and 2 for signed _BitInt.
It doesn't bother me too much, since I'm unlikely to have a
use for signed _BitInt(1). But it's an arbitrary restriction.
(And I thought you liked arbitrary restrictions.)
[...]
> At least, I've been able to add to my collection of C types that
> represent an 8-bit byte:
>
> signed char
> unsigned char
> int8_t
> uint8_t
> _BitInt(8)
> unsigned _BitInt(8)
>
> The last two are apparently incompatible with the char versions.
You forgot plain char, int_least8_t, and uint_least8_t. And of
course the char types are CHAR_BIT bits, not necessarily 8 bits.
It's mildly interesting that unsigned _BitInt(8) gives you a way to
define an octet even on systems with CHAR_BIT > 8. But of course an
unsigned _BitInt(8) object will still have a size of CHAR_BIT bits.
(Again, saving space on ordinary hardware isn't part of the rationale
for _BitInt types.)
--
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-26 02:08 +0000 |
| Message-ID | <10g5ne5$4i3$1@dont-email.me> |
| In reply to | #395485 |
On 25/11/2025 23:20, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 25/11/2025 20:25, David Brown wrote: > [...] >>> Arbitrary sized integers are a very different kettle of fish from >>> large fixed-size integers, and are not something that would fit in >>> the C language - they need a library. >> >> Really? I wouldn't have thought there was any appreciable difference >> between the code for multiplying two 100,000-bit BitInts, and that for >> multiplying two abitrary-precision ints that happen to be 100,000 >> bits. > > It's not about the code that implements multiplication. In gcc, that's > done by calling a built-in function that can operate on arbitrary data > widths. > > Think about memory management. Well, I was responding to a suggestion that BitInt support didn't need a library. But memory management is a good point. Actual, variable-sized bigints would be awkward in C if you want to use them in ordinary expressions. Although managing large fixed-sized types, which may also involve intermediate, transient values, can have their own problems. > Perhaps a future standard will provide a more flexible flavor of > _BitInt. It might allow the n in _BitInt(n) to be non-constant, or > empty, or "*", to denote an arbitrary-precision integer. But it's > hard to see how that could be done without adding other fundamental > features to the language. And a lot of people's response would be > that if you want C++, you know where to find it. I think I would have responded better to BitInt if presented as a 'bit-set', effectively a fixed-size bit-array, but passed by value. This is something that I'd considered myself at one time. Those would have logical operators, access to indvidual bits, but not arithmetic nor shifts, and no notion of twos complement. (In my implementation, they could also have been initialised like Pascal bitsets.) More significantly, an unbounded version could be passed by reference, with an accompanying length (I could also use slices that have the length) as happens with arrays in C. > Similarly, C99 added complex types as a built-in language feature. > C++ added complex types as a template class, because C++ has language > features that support that kind of thing, including user-defined > literals. > > If you can think of a way to add arbitrary-precision integers to C > without other radical changes to the language, let us know. I have considered adding my actual arbitrary precision library to my systems language. It would have been superfical (such types would not be nestable within other data structures), but would have been simpler to use than function calls. Some degree of automatic memory management would have been needed (initialise locals on function entry, free on exit, deal with intermediates), but not on the C++ scale due to the restrictions. But I rejected that as being too high-level a feature, and my use-cases more suitable for a scripting language. > It could also be nice to be able to write code that deals with > multiple widths of _BitInt types, as we can do for arrays even > without VLAs. But C's treatment of arrays is messy, and I'm not > sure duplicating that mess for _BitInt types would be a great idea. > And I wouldn't want to lose the ability to pass _BitInt values > to functions. > > [...] > >> So, a better fit for a struct then? Here I'm curious as to what >> BitInt(128) brings to the table. > > It brings a 128-bit integer type with constants and straightforward > assignment, comparison, and arithmetic operators. I was commenting on the ipv6 example, where structs give you that already, except arithmetic which makes little sense. > [...] > >> That BigInt() defaults to a signed integer (twos complement?), even >> for very large sizes suggests that /numeric/ applications are a >> primary use. > > Yes, C23 requires two's-complement for signed integers. (It mandates > two's-complement representation, not wraparound behavior; signed > overflow is still UB). Even though it will now likely be under software control? OK. >> At least, I've been able to add to my collection of C types that >> represent an 8-bit byte: >> >> signed char >> unsigned char >> int8_t >> uint8_t >> _BitInt(8) >> unsigned _BitInt(8) >> >> The last two are apparently incompatible with the char versions. > > You forgot plain char, I had char but took it out, as it's a outlier. > int_least8_t, and uint_least8_t. And 'fast' versions? I still don't know what any of these mean! No other languages seem to have bothered.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-25 19:06 -0800 |
| Message-ID | <87tsyhcx1k.fsf@example.invalid> |
| In reply to | #395486 |
bart <bc@freeuk.com> writes:
> On 25/11/2025 23:20, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 25/11/2025 20:25, David Brown wrote:
>> [...]
>>>> Arbitrary sized integers are a very different kettle of fish from
>>>> large fixed-size integers, and are not something that would fit in
>>>> the C language - they need a library.
>>>
>>> Really? I wouldn't have thought there was any appreciable difference
>>> between the code for multiplying two 100,000-bit BitInts, and that for
>>> multiplying two abitrary-precision ints that happen to be 100,000
>>> bits.
>> It's not about the code that implements multiplication. In gcc,
>> that's done by calling a built-in function that can operate on
>> arbitrary data widths. Think about memory management.
>
> Well, I was responding to a suggestion that BitInt support didn't need
> a library.
David didn't actually suggest that. He said that arbitrary-sized
integers would need a library (and such libraries exist), not that
fixed-size integers don't.
The point, I think, is that arbitrary-sized integers, without radical
changes to the language, would require a *visible* library while the
_BitInt types are built into the language. Yes, some operations are
implemented as function calls in some implementations. The same
could be true for just about any operation. Some implementations
have software floating-point. gcc implements a large struct
assignment by generating a call to memcmp. And so on.
> But memory management is a good point. Actual, variable-sized bigints
> would be awkward in C if you want to use them in ordinary expressions.
>
> Although managing large fixed-sized types, which may also involve
> intermediate, transient values, can have their own problems.
Again, any such problems have already been solved by the gcc and
llvm/clang implementations (aside from a clang problem with large
multiplication and division). "This feature would be too difficult to
implement" is a weak argument when implentations already exist.
BTW, clang has had this feature (originally called _ExtInt rather than
_BitInt) since 2019. Here's the git log entry. The committer is one of
the authors of the N2021 paper, so the similarities are unsurprising.
```
commit 61ba1481e200b5b35baa81ffcff81acb678e8508
Author: Erich Keane <erich.keane@intel.com>
Date: 2019-12-24 07:28:40 -0800
Implement _ExtInt as an extended int type specifier.
Introduction/Motivation:
LLVM-IR supports integers of non-power-of-2 bitwidth, in the iN syntax.
Integers of non-power-of-two aren't particularly interesting or useful
on most hardware, so much so that no language in Clang has been
motivated to expose it before.
However, in the case of FPGA hardware normal integer types where the
full bitwidth isn't used, is extremely wasteful and has severe
performance/space concerns. Because of this, Intel has introduced this
functionality in the High Level Synthesis compiler[0]
under the name "Arbitrary Precision Integer" (ap_int for short). This
has been extremely useful and effective for our users, permitting them
to optimize their storage and operation space on an architecture where
both can be extremely expensive.
We are proposing upstreaming a more palatable version of this to the
community, in the form of this proposal and accompanying patch. We are
proposing the syntax _ExtInt(N). We intend to propose this to the WG14
committee[1], and the underscore-capital seems like the active direction
for a WG14 paper's acceptance. An alternative that Richard Smith
suggested on the initial review was __int(N), however we believe that
is much less acceptable by WG14. We considered _Int, however _Int is
used as an identifier in libstdc++ and there is no good way to fall
back to an identifier (since _Int(5) is indistinguishable from an
unnamed initializer of a template type named _Int).
[0]https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html)
[1]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf
Differential Revision: https://reviews.llvm.org/D73967
```
[...]
> I think I would have responded better to BitInt if presented as a
> 'bit-set', effectively a fixed-size bit-array, but passed by
> value. This is something that I'd considered myself at one time.
>
> Those would have logical operators, access to indvidual bits, but not
> arithmetic nor shifts, and no notion of twos complement. (In my
> implementation, they could also have been initialised like Pascal
> bitsets.)
So rather than a new feature for wide integer types, you would
have preferred something that DOESN'T SUPPORT ARITHMETIC?? How is
that relevant to _BitInt? Bit vectors are great, but they aren't
integers.
This might interest you :
https://github.com/michaeldipperstein/bitarray
> More significantly, an unbounded version could be passed by reference,
> with an accompanying length (I could also use slices that have the
> length) as happens with arrays in C.
Right, like arrays of unsigned char.
[...]
>> It could also be nice to be able to write code that deals with
>> multiple widths of _BitInt types, as we can do for arrays even
>> without VLAs. But C's treatment of arrays is messy, and I'm not
>> sure duplicating that mess for _BitInt types would be a great idea.
>> And I wouldn't want to lose the ability to pass _BitInt values
>> to functions.
>> [...]
>>
>>> So, a better fit for a struct then? Here I'm curious as to what
>>> BitInt(128) brings to the table.
>> It brings a 128-bit integer type with constants and straightforward
>> assignment, comparison, and arithmetic operators.
>
> I was commenting on the ipv6 example, where structs give you that
> already, except arithmetic which makes little sense.
OK, I probably snipped too much context here. unsigned _BitInt(128)
could be a reasonable way to represent an ipv6 address. So could
unsigned char[16], or a struct containing an unsigned char[16].
[...]
>>> At least, I've been able to add to my collection of C types that
>>> represent an 8-bit byte:
>>>
>>> signed char
>>> unsigned char
>>> int8_t
>>> uint8_t
>>> _BitInt(8)
>>> unsigned _BitInt(8)
>>>
>>> The last two are apparently incompatible with the char versions.
>> You forgot plain char,
>
> I had char but took it out, as it's a outlier.
OK, whatever works for you.
>> int_least8_t, and uint_least8_t.
>
> And 'fast' versions? I still don't know what any of these mean! No
> other languages seem to have bothered.
The "fast" versions could be larger than 8 bits (though I'm mildly
surprised to see that [u]int8_fast_t types *are* 8 bits on several
compilers I just tried).
Of course C++ and Objective-C incorporate C's standard library.
You say you don't know what they mean. Do you *want* to know?
You can always read the standard's description if you're curious.
I never assume that saying you don't know something means that you
want to know about it.
--
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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-26 11:52 +0200 |
| Message-ID | <20251126115207.00007dc7@yahoo.com> |
| In reply to | #395487 |
On Tue, 25 Nov 2025 19:06:31 -0800 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > > BTW, clang has had this feature (originally called _ExtInt rather than > _BitInt) since 2019. Here's the git log entry. The committer is one > of the authors of the N2021 paper, so the similarities are > unsurprising. > > ``` > commit 61ba1481e200b5b35baa81ffcff81acb678e8508 > Author: Erich Keane <erich.keane@intel.com> > Date: 2019-12-24 07:28:40 -0800 > > Implement _ExtInt as an extended int type specifier. > > Introduction/Motivation: > LLVM-IR supports integers of non-power-of-2 bitwidth, in the iN > syntax. Integers of non-power-of-two aren't particularly interesting > or useful on most hardware, so much so that no language in Clang has > been motivated to expose it before. > > However, in the case of FPGA hardware normal integer types where > the full bitwidth isn't used, is extremely wasteful and has severe > performance/space concerns. Because of this, Intel has > introduced this functionality in the High Level Synthesis compiler[0] > under the name "Arbitrary Precision Integer" (ap_int for short). > This has been extremely useful and effective for our users, > permitting them to optimize their storage and operation space on an > architecture where both can be extremely expensive. > > We are proposing upstreaming a more palatable version of this to > the community, in the form of this proposal and accompanying patch. > We are proposing the syntax _ExtInt(N). We intend to propose this to > the WG14 committee[1], and the underscore-capital seems like the > active direction for a WG14 paper's acceptance. An alternative that > Richard Smith suggested on the initial review was __int(N), however > we believe that is much less acceptable by WG14. We considered _Int, > however _Int is used as an identifier in libstdc++ and there is no > good way to fall back to an identifier (since _Int(5) is > indistinguishable from an unnamed initializer of a template type > named _Int). > [0]https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html) > [1]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf > > Differential Revision: https://reviews.llvm.org/D73967 > ``` > > [...] > I like the feature in the form that it ended up, but I certainly dislike their motivation. [O.T. rant] High Level Synthesis, both by Altera (part of Intel in 2016-2024) and by Xilinx (part of AMD since 2022), is an archetypal snake oil. Bullshit doctors lure people into notion that they can save their time by not learning proper HDLs. But at the naive user than believed their crap end up spending more time rather than less. As far as Altera/Xilinx is concerned, short-term gain is that users make less efficient design, which mean that they have to by bigger, more expensive FPGA devices. But at the long term it is loss for FPGA ecosystem, because more people believe that FPGas are shite when in fact it's not FPGAs that are bad, but improper tools (HLS). [/O.T. rant]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-26 13:15 +0100 |
| Message-ID | <10g6r0p$bn6e$1@dont-email.me> |
| In reply to | #395486 |
On 26/11/2025 03:08, bart wrote:
> On 25/11/2025 23:20, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 25/11/2025 20:25, David Brown wrote:
>> [...]
>>>> Arbitrary sized integers are a very different kettle of fish from
>>>> large fixed-size integers, and are not something that would fit in
>>>> the C language - they need a library.
>>>
>>> Really? I wouldn't have thought there was any appreciable difference
>>> between the code for multiplying two 100,000-bit BitInts, and that for
>>> multiplying two abitrary-precision ints that happen to be 100,000
>>> bits.
>>
>> It's not about the code that implements multiplication. In gcc, that's
>> done by calling a built-in function that can operate on arbitrary data
>> widths.
>>
>> Think about memory management.
>
> Well, I was responding to a suggestion that BitInt support didn't need a
> library.
I did not say that. (You really need to get a better understanding of
basic logic.) I said that arbitrary sized integers need a library - I
did not say that fixed-sized integers do not need a library.
Perhaps more clearly, arbitrary sized integers need a user-visible
library in C. They need functions to allocate, deallocate, and copy the
integers, as well as converting to and from normal integers, at a bare
minimum.
It is normal in C implementations that some operations are done with
"hidden" library calls - functions in a "language support library" that
you do not call directly. On an x86 machine, "x / y" might generate a
divide instruction, while on a microcontroller it might generate a call
to a "__divide_int" function in an internal compiler-specific library
(with internal compiler-specific calling conventions). _BitInt support
can certainly make use of such libraries, just like anything else in C.
And it looks like the gcc implementation of _BitInt /does/ use such
libraries for big enough _BitInt types, while using inline code for
sizes that can be done reasonably efficiently. Clang, on the other
hand, apparently generates inline code no matter what size of _BitInt
you have. Those are implementation choices, and it's all hidden from
the user.
>
> But memory management is a good point. Actual, variable-sized bigints
> would be awkward in C if you want to use them in ordinary expressions.
>
Indeed.
> Although managing large fixed-sized types, which may also involve
> intermediate, transient values, can have their own problems.
You already support such types in C. If it is a problem, it is a
problem that every vaguely compliant C compiler has already solved.
struct Big { uint64_t xs[250000]; }
That type is passed around, copied and assigned by value, even though it
is 1 MB in size. _BigInt's don't add any new issues here.
>
>
>
>> Perhaps a future standard will provide a more flexible flavor of
>> _BitInt. It might allow the n in _BitInt(n) to be non-constant, or
>> empty, or "*", to denote an arbitrary-precision integer. But it's
>> hard to see how that could be done without adding other fundamental
>> features to the language. And a lot of people's response would be
>> that if you want C++, you know where to find it.
>
> I think I would have responded better to BitInt if presented as a
> 'bit-set', effectively a fixed-size bit-array, but passed by value.
> This is something that I'd considered myself at one time.
Certainly _BitInt's can be used as bitsets.
>
> Those would have logical operators, access to indvidual bits, but not
> arithmetic nor shifts, and no notion of twos complement. (In my
> implementation, they could also have been initialised like Pascal bitsets.)
>
_BitInt's have logical operators. You can get access to individual bits
from shifts and masks, just like for any other integer types.
How efficiently a given compiler handles these is another matter -
expect that early implementations will be correct but relatively
inefficient and gradually improve as _BitInt's get more popular.
> More significantly, an unbounded version could be passed by reference,
> with an accompanying length (I could also use slices that have the
> length) as happens with arrays in C.
_BitInt's have fixed sizes - if you want a variable size, use an array.
No one is claiming that _BitInt types are somehow the perfect tool for
any use-case.
>
>> Similarly, C99 added complex types as a built-in language feature.
>> C++ added complex types as a template class, because C++ has language
>> features that support that kind of thing, including user-defined
>> literals.
>>
>> If you can think of a way to add arbitrary-precision integers to C
>> without other radical changes to the language, let us know.
>
> I have considered adding my actual arbitrary precision library to my
> systems language. It would have been superfical (such types would not be
> nestable within other data structures), but would have been simpler to
> use than function calls.
>
> Some degree of automatic memory management would have been needed
> (initialise locals on function entry, free on exit, deal with
> intermediates), but not on the C++ scale due to the restrictions.
>
> But I rejected that as being too high-level a feature, and my use-cases
> more suitable for a scripting language.
Different languages can support different features in different ways. C
cannot support types that involve memory management in a
user-transparent manner - memory management is manual in C. In C++, it
would be entirely possible to make arbitrary precision integers with
automatic memory management. It would not even be particularly
difficult (except for efficient implementation of arithmetic operations
on large sizes), and not need any language changes. But that would not
negate the uses of _BitInt, which is (AFAIUI) on its way into C++.
>
>
>> It could also be nice to be able to write code that deals with
>> multiple widths of _BitInt types, as we can do for arrays even
>> without VLAs. But C's treatment of arrays is messy, and I'm not
>> sure duplicating that mess for _BitInt types would be a great idea.
>> And I wouldn't want to lose the ability to pass _BitInt values
>> to functions.
>>
>> [...]
>>
>>> So, a better fit for a struct then? Here I'm curious as to what
>>> BitInt(128) brings to the table.
>>
>> It brings a 128-bit integer type with constants and straightforward
>> assignment, comparison, and arithmetic operators.
>
> I was commenting on the ipv6 example, where structs give you that
> already, except arithmetic which makes little sense.
>
Shifting and masking would definitely be useful operations. I can't see
a point in adding or multiplying IPv6 addresses, but logical operations
would definitely be useful. Things like netmasks are not always on neat
octet boundaries.
>
>> [...]
>>
>>> That BigInt() defaults to a signed integer (twos complement?), even
>>> for very large sizes suggests that /numeric/ applications are a
>>> primary use.
>>
>> Yes, C23 requires two's-complement for signed integers. (It mandates
>> two's-complement representation, not wraparound behavior; signed
>> overflow is still UB).
>
> Even though it will now likely be under software control? OK.
>
They play by the same rules as all other integer types in C.
>>> At least, I've been able to add to my collection of C types that
>>> represent an 8-bit byte:
>>>
>>> signed char
>>> unsigned char
>>> int8_t
>>> uint8_t
>>> _BitInt(8)
>>> unsigned _BitInt(8)
>>>
>>> The last two are apparently incompatible with the char versions.
>>
>> You forgot plain char,
>
> I had char but took it out, as it's a outlier.
>
>> int_least8_t, and uint_least8_t.
>
> And 'fast' versions? I still don't know what any of these mean! No other
> languages seem to have bothered.
>
>
The "fast" versions are types that have a minimum given size, but might
be faster than the exact or least versions for typical operations.
So "int_fast32_t" is guaranteed to have at least 32 bits of precision,
but is allowed to be bigger if that is faster. On x86, it is 64 bits
because 64-bit arithmetic and register moves can often involve fewer
masking or sign-extension operations than 32-bit operations. (Because
of the oddities of the x86 world, it seems "int_fast8_t" is 8 bits
rather than 64 bits.)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-26 15:08 +0200 |
| Message-ID | <20251126150854.00000b85@yahoo.com> |
| In reply to | #395495 |
On Wed, 26 Nov 2025 13:15:21 +0100 David Brown <david.brown@hesbynett.no> wrote: > > I did not say that. (You really need to get a better understanding > of basic logic.) I said that arbitrary sized integers need a library > - I did not say that fixed-sized integers do not need a library. > > Perhaps more clearly, arbitrary sized integers need a user-visible > library in C. They need functions to allocate, deallocate, and copy > the integers, as well as converting to and from normal integers, at a > bare minimum. > Perhaps things will become even more clear if we make distinction between run-time library and compiler support library. In specific case of gcc, the latter is called libgcc. It is (almost) per architecture. (Almost) the same libgcc works on x86-64 Windows, Linux, BSD or Solaris. The same for other popular architectures. The former, on the other hand, is certainly different on different platforms with the same architecture, but sometimes can be different on the same platform/architecture. For example, newlib nowadays used almost exclusively on embedded platforms without real OS, but historically was invented for Linux, by people, not totally unlike Bart in their attitude, that hated code bloat of glibc.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-25 19:21 -0800 |
| Message-ID | <87pl95cwdc.fsf@example.invalid> |
| In reply to | #395485 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> bart <bc@freeuk.com> writes:
[...]
>> OK, so why are you not allowed to have _BitInt(1)? That is, a 1-bit
>> signed integer. It might only have two values of 0 and -1; doesn't
>> nobody want that particular combination?
>
> I don't know. The language allows 1-bit signed bit-fields, so
> _BitInt(1) would make some sense, but the language requires N to
> be at least 1 for unsigned _BitInt and 2 for signed _BitInt.
>
> It doesn't bother me too much, since I'm unlikely to have a
> use for signed _BitInt(1). But it's an arbitrary restriction.
[...]
I just learned that there's a proposal to allow _BitInt(1) in C2y.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3699.pdf
The current restriction apparently was for historical reasons.
Prior to C23, C didn't require two's complement for signed types,
and signed _BitInt(1) doesn't make much sense for one's complement
or sign-and-magnitude (it could only hold +0 and -0).
Yes, C23 added both _BitInt and the requirement for two's complement,
but preliminary implementations of _BitInt go back several years,
and the requirements didn't catch up. Stuff happens.
Incidentally, C23 requires BITINT_MAXWIDTH to be at least
ULLONG_WIDTH, which is at least 64. clang/llvm sets it to 128 for
some target systems.
<OT>
https://eisenwave.github.io/cpp-proposals/bitint.html
is a proposal to add C23-style bit-precise integers to C++.
</OT>
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-11-29 22:40 +0100 |
| Message-ID | <10gfp8a$sda3$4@solani.org> |
| In reply to | #395488 |
Am 26.11.25 um 04:21 schrieb Keith Thompson: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> bart <bc@freeuk.com> writes: > [...] >>> OK, so why are you not allowed to have _BitInt(1)? That is, a 1-bit >>> signed integer. It might only have two values of 0 and -1; doesn't >>> nobody want that particular combination? >> >> I don't know. The language allows 1-bit signed bit-fields, so >> _BitInt(1) would make some sense, but the language requires N to >> be at least 1 for unsigned _BitInt and 2 for signed _BitInt. >> >> It doesn't bother me too much, since I'm unlikely to have a >> use for signed _BitInt(1). But it's an arbitrary restriction. > [...] > > I just learned that there's a proposal to allow _BitInt(1) in C2y. > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3699.pdf > > The current restriction apparently was for historical reasons. > Prior to C23, C didn't require two's complement for signed types, > and signed _BitInt(1) doesn't make much sense for one's complement > or sign-and-magnitude (it could only hold +0 and -0). AFAIR, clang developers were opposed to signed _BitInt(1) arguing that even int:1 was a mistake, and that the behavior of not being able to store 1 into a singed integer type was confusing to users, and those types had no real use cases, and were nothing but a potential foot gun. Users since voiced their their disagreement on those points towards clang, and clang's resistance to _BitInt(1) disappeared.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-11-29 22:04 -0500 |
| Message-ID | <10ggc8e$3vdvh$1@dont-email.me> |
| In reply to | #395578 |
On 2025-11-29 16:40, Philipp Klaus Krause wrote: ... > store 1 into a singed integer type was confusing to users, and those How did it get singed? :-)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-26 08:55 +0100 |
| Message-ID | <10g6bpp$60nh$1@dont-email.me> |
| In reply to | #395484 |
On 25/11/2025 22:58, bart wrote: > On 25/11/2025 20:25, David Brown wrote: >> On 24/11/2025 23:27, bart wrote: > >>> On interesting use-case for literals was short-strings; 128 bits >>> allowed character literals up to 16 characters: 'ABCDEFGHIJKLMNOP'. I >>> think C is still stuck at one, or 4 if you're lucky.) >>> >> >> I have no idea or opinion on why /you/ might want 128-bit or larger >> integer types. I believe there is very little use for "normal" >> numbers - things you might want to write as literals, calculate with, >> and read or write - that won't fit perfectly well within 64 bit types, >> and would not be better served by arbitrary sized integers. > > >> Arbitrary sized integers are a very different kettle of fish from >> large fixed-size integers, and are not something that would fit in the >> C language - they need a library. > > Really? I wouldn't have thought there was any appreciable difference > between the code for multiplying two 100,000-bit BitInts, and that for > multiplying two abitrary-precision ints that happen to be 100,000 bits. > You are looking at things in completely the wrong way. Long before you start thinking of how to implement operations, think about what the types are at a fundamental level. A fixed-size integer is a value type of fixed, compile-time size. It is passed around as a value. Local instances can be put on a stack with compile-time fixed offsets (and thus using [sp + N] access modes in an implementation). The type has a single simple and obvious (albeit slightly implementation-dependent) bit representation. A _BitInt(32) will be identical at the low level to an int32_t. Bigger _BitInt types are just the same, only bigger. There is no difference in concept, or representation, whether the type is 32-bit or 32 million bits. An arbitrary sized integer is a dynamic type with variable size. The base object will hold information about pointers to data, sizes for that stored data - including both how much is in use, and how much is available. There are endless ways to make such types - you can support multiple allocation parts, or use a single contiguous allocation. You can store the data in binary, or some kind of packed decimal, or other formats. Passing them around might mean just passing around the base object, but sometimes you need to make deep copies. Operations might lead to heap memory allocations or deallocations. They are so /totally/ different that any similarities in the way you do a particular arithmetic operation are completely incidental. > Maybe the latter is autoranging, and might give a 200,000-bit result. > > Presumably the former doesn't use inline code, so it would be surprising > if each distinct size of BitInt had dedicated sets of routines for this. > So it sounds like they have to use a generic library anyway. > > And sure enough, gcc-generated code contains stuff like this: > > mov r8, rcx > mov edx, 50000 # (BitInt(50000) > mov rcx, rax > call __mulbitint3 > > So, BitInts are different in that they /don't/ need a library? > >> >> I can tell you why /I/ might find larger integer types useful. They >> include : >> >> * 128-bit for IPv6 address. These use a variety of styles for input >> and display, and thus would use specialised routines, not simple >> literals or printf-style IO. > > So, a better fit for a struct then? Here I'm curious as to what > BitInt(128) brings to the table. > A struct is certainly what I use today. But there may be times when it is convenient to hold the data in a single scalar object. Depending on the target device, registers, and operations, there might be registers that can hold a 128-bit scalar for passing it around, or for atomically accessing them. > >> * Big units for passing data around with larger memory transfers, >> using SIMD registers. IO is irrelevant here. > > Structs and arrays again spring to mind if you just want an anonymous > data block. (I wonder why it has to be bit-precise for byte-addressed > memory?) > If I have a processor that has 256-bit vector registers, then moving data by loading and storing 256-bit blocks is going to be more efficient than doing a loop of 16 byte moves. Today, I would use uint64_t for the task, as the biggest type available. Why does it have to be bit-precise? It must be bit-precise because I would want to move 256 bits - not 255 bits or 257 bits. > >> * Cryptography. IO is irrelevant here. But a variety of sizes are >> useful including 56, 80, 112, 128, 168, 192, 384, 512, 521, 2048, >> 3072, 4096, 7680, 8096 bits. There may be more common sizes - I'm >> just thinking of DES, 3DES, AES, SHA, ECC and RSA. > > And I'm again curious as to what /non-numeric/ use a 200,000-bit BitInt > might be put to, that is not better served by an array or struct. > I don't have a use for a 200,000 bit integer type at the moment. But I cannot imagine any reason why the language specifications should have arbitrary limits. Are you suggesting that the C standards show say "You can have _BitInt's up to 8096 because someone found a use for them, but you can't have size 8097 and above - and 200,000 is right out - because someone else can't imagine they are useful" ? An implementation can - indeed, must - set a limit to the sizes it supports. Implementations can have many reasons to do so. Some implementations might have quite low limits (the size of "long long int" is the minimum allowed for conformance), but then that implementation might not be so useful to some people. > Maybe bit-sets? But there are no special features for accessing > individual bits. > > That BigInt() defaults to a signed integer (twos complement?), even for > very large sizes suggests that /numeric/ applications are a primary use. > Obviously the C standards should have made "_BitInt" signed up to size 73 bits, and unsigned from then on. That would have been /so/ much clearer and simpler for everyone. >> >> >> Smaller sizes can be useful for holding RGB pixel values, audio data, >> etc. > > Except that these are probably rounded up, to the next multiple of two. > So the benefit is minimal; it do something with those padding bits. > I write C code. I want my C code to be clear and represent what I am handling, and then let the compiler do its job of generating efficient results. So if I am dealing with data that is 24-bit signed integer data, then _BitInt(24) (especially with a typedef name) is more accurate source code than "int" or "int32_t". >>> And 821 bits. This is what I don't get. Why is THAT so important? >>> >>> Why couldn't 128/256/etc have been added first, and then those funny >>> ones if the demand was still there? >> >> The folks behind the proposal provided both. The fact that you can >> write _BitInt(821) does not in any way hinder use of _BitInt(256). I >> really don't get your problem here. > > You've heard of 'code smell'? Well, this is the same, but for features. > Your nose is blocked. Or to be more accurate, you are so obsessed with the idea that your own language is "perfect" that you simply cannot accept that other languages might have good features that your language does not, or that other programmers might want features that your language does not have. > I've been doing this stuff long enough to recognise when a feature is > over-elaborate, over-specified and over-flexible. You need to know the > minimum you can get away with, not the maximum! NIH syndrome combined with megalomania. Other people do this stuff better than you. > > Let me guess, some committee members have been looking too long at how > C++ does things? That language is utterly incapable of creating anything > small and simple. > And yet C and C++ programmers outnumber programmers of Bart's own language by millions. No language - except for yours, of course - is perfect. But it seems C and C++ are both pretty good for getting the job done. > >>> >>> If the proposal had instead been simply to extend the 'u8 u16 u32 >>> u64' set of types by a few more entries on the right, say 'u128 u256 >>> u512', would anyone have been clamouring for types like 'u1187'? I >>> doubt it. >> >> /You/ might not have wanted them, but other people would. > > > > OK, so why are you not allowed to have _BitInt(1)? That is, a 1-bit > signed integer. It might only have two values of 0 and -1; doesn't > nobody want that particular combination? Apparently that one was ruled out. (I believe the C++ plans for _BitInt will allow it there - not because it is a useful type in itself, but because allowing it slightly simplifies generic programming with _BitInt types.) > > > > >>> >>> For sub-64-bit types on conventional hardware, I simply can't see the >>> point, not if they are rounded up anyway. Either have a full range- >>> based types like Ada, or not at all. >>> >> >> Fortunately for the C world, you are not on the C committee - it >> doesn't matter if you can't see beyond the end of your nose. > > Maybe unfortunately. C used to be a fairly simple language with a lot of > baggage; now it's a much heftier one with a lot of baggage! > > At least, I've been able to add to my collection of C types that > represent an 8-bit byte: > > signed char > unsigned char > int8_t > uint8_t > _BitInt(8) > unsigned _BitInt(8) > > The last two are apparently incompatible with the char versions. >
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-26 12:05 +0000 |
| Message-ID | <10g6qek$bfrp$1@dont-email.me> |
| In reply to | #395489 |
On 26/11/2025 07:55, David Brown wrote:
> On 25/11/2025 22:58, bart wrote:
>> On 25/11/2025 20:25, David Brown wrote:
>>> On 24/11/2025 23:27, bart wrote:
>>
>>>> On interesting use-case for literals was short-strings; 128 bits
>>>> allowed character literals up to 16 characters: 'ABCDEFGHIJKLMNOP'.
>>>> I think C is still stuck at one, or 4 if you're lucky.)
>>>>
>>>
>>> I have no idea or opinion on why /you/ might want 128-bit or larger
>>> integer types. I believe there is very little use for "normal"
>>> numbers - things you might want to write as literals, calculate with,
>>> and read or write - that won't fit perfectly well within 64 bit
>>> types, and would not be better served by arbitrary sized integers.
>>
>>
>>> Arbitrary sized integers are a very different kettle of fish from
>>> large fixed-size integers, and are not something that would fit in
>>> the C language - they need a library.
>>
>> Really? I wouldn't have thought there was any appreciable difference
>> between the code for multiplying two 100,000-bit BitInts, and that for
>> multiplying two abitrary-precision ints that happen to be 100,000 bits.
>>
>
> You are looking at things in completely the wrong way.
>
> Long before you start thinking of how to implement operations, think
> about what the types are at a fundamental level.
>
> A fixed-size integer is a value type of fixed, compile-time size. It is
> passed around as a value. Local instances can be put on a stack with
> compile-time fixed offsets (and thus using [sp + N] access modes in an
> implementation). The type has a single simple and obvious (albeit
> slightly implementation-dependent) bit representation. A _BitInt(32)
> will be identical at the low level to an int32_t. Bigger _BitInt types
> are just the same, only bigger. There is no difference in concept, or
> representation, whether the type is 32-bit or 32 million bits.
>
> An arbitrary sized integer is a dynamic type with variable size. The
> base object will hold information about pointers to data, sizes for that
> stored data - including both how much is in use, and how much is
> available. There are endless ways to make such types - you can support
> multiple allocation parts, or use a single contiguous allocation. You
> can store the data in binary, or some kind of packed decimal, or other
> formats. Passing them around might mean just passing around the base
> object, but sometimes you need to make deep copies. Operations might
> lead to heap memory allocations or deallocations.
>
> They are so /totally/ different that any similarities in the way you do
> a particular arithmetic operation are completely incidental.
But BitInts /will/ need runtime library support?
I've acknowledged in my last post that arbitrary precision would have
memory management issues, /if/ you wanted to add them to the language in
such a way that, if variables 'a b c d' had such a type, you can write:
a = b + c * d;
This is not what I had in mind; such arithmetic would use explicit
function calls with explicit management of intermediates (like GMP).
So from this point of view, fixed-size BitInts are better, but also a
higher level ability than I would have considered added to the language.
Even if BitInts were restricted to saner and smaller sizes, I'd consider
actual arithmetic on 128 bits up to a few K bits and above a specialist,
niche application.
But logic operations (== & | ^) on unsigned BitInts are more reasonable
(because they implement some features of bit-sets).
For arithmetic on considerably larger numbers, I still think arbitrary
precision is the best bet.
>> Structs and arrays again spring to mind if you just want an anonymous
>> data block. (I wonder why it has to be bit-precise for byte-addressed
>> memory?)
>>
>
> If I have a processor that has 256-bit vector registers, then moving
> data by loading and storing 256-bit blocks is going to be more efficient
> than doing a loop of 16 byte moves. Today, I would use uint64_t for the
> task, as the biggest type available. Why does it have to be bit-
> precise? It must be bit-precise because I would want to move 256 bits -
> not 255 bits or 257 bits.
By bit-precise I mean being able to specify 255 and 257 bits! Memory is
usually expression in bytes or words; not bits.
>
>>
>>> * Cryptography. IO is irrelevant here. But a variety of sizes are
>>> useful including 56, 80, 112, 128, 168, 192, 384, 512, 521, 2048,
>>> 3072, 4096, 7680, 8096 bits. There may be more common sizes - I'm
>>> just thinking of DES, 3DES, AES, SHA, ECC and RSA.
>>
>> And I'm again curious as to what /non-numeric/ use a 200,000-bit
>> BitInt might be put to, that is not better served by an array or struct.
>>
>
> I don't have a use for a 200,000 bit integer type at the moment. But I
> cannot imagine any reason why the language specifications should have
> arbitrary limits. Are you suggesting that the C standards show say "You
> can have _BitInt's up to 8096 because someone found a use for them, but
> you can't have size 8097 and above - and 200,000 is right out - because
> someone else can't imagine they are useful" ?
And yet, integer widths have been roughly capped at double a machine
word size for decades - until 64 bits came along and then few even
bothered with double-width.
Nobody thought how easy it would be to just have an integer of whatever
size you like - you just generate whatever code is necessary to make it
happen. We could have had BitInts on 32- and even 16-bit machines if
only somebody had thought of it!
>
> An implementation can - indeed, must - set a limit to the sizes it
> supports. Implementations can have many reasons to do so. Some
> implementations might have quite low limits (the size of "long long int"
> is the minimum allowed for conformance), but then that implementation
> might not be so useful to some people.
>
>> Maybe bit-sets? But there are no special features for accessing
>> individual bits.
>>
>> That BigInt() defaults to a signed integer (twos complement?), even
>> for very large sizes suggests that /numeric/ applications are a
>> primary use.
>>
>
> Obviously the C standards should have made "_BitInt" signed up to size
> 73 bits, and unsigned from then on. That would have been /so/ much
> clearer and simpler for everyone.
Or unsigned could have been the default.
>>>
>>>
>>> Smaller sizes can be useful for holding RGB pixel values, audio data,
>>> etc.
>>
>> Except that these are probably rounded up, to the next multiple of
>> two. So the benefit is minimal; it do something with those padding bits.
>>
>
> I write C code. I want my C code to be clear and represent what I am
> handling, and then let the compiler do its job of generating efficient
> results. So if I am dealing with data that is 24-bit signed integer
> data, then _BitInt(24) (especially with a typedef name) is more accurate
> source code than "int" or "int32_t".
Suddenly everybody is dealing with signed values of 12 and 24 bits!
I actually had exactly that feature:
int*3 a # from 1980s; a 3-byte or 24-bit signed type
int:24 b # from 1990s; a 24-bit signed type
Or at least, I had the syntax. Those odd values would have been
rejected, as I didn't have support for them, or a way to emulate them
(which is what BitInt(24) appears to do).
So I got rid of the feature and ended up with int32 and then i32. (I
think Zig allows types like i24 and i123456, presumably built upon
LLVM's integer types which go up to 2**23 or 2**24 bits.)
>> You've heard of 'code smell'? Well, this is the same, but for features.
>>
>
> Your nose is blocked. Or to be more accurate, you are so obsessed with
> the idea that your own language is "perfect" that you simply cannot
> accept that other languages might have good features that your language
> does not, or that other programmers might want features that your
> language does not have.
>
>> I've been doing this stuff long enough to recognise when a feature is
>> over-elaborate, over-specified and over-flexible. You need to know the
>> minimum you can get away with, not the maximum!
>
> NIH syndrome combined with megalomania. Other people do this stuff
> better than you.
I've noticed that other languages tend to go overboard with things, and
now it's happening to C.
I made a decision to keep my systems language at a certain level
regarding such things as the type system, while having lots of
convenient micro-features:
print int@(x+y).[52..62]
This type-puns a float64 r-value expression into an int, and extracts
that bitfield (which is the unsigned exponent field when float64 uses
iee754).
I'd be interested to see how you can do this better, using general
language features (adding a dedicated .exponent property to floats would
be cheating!).
>>
>> Let me guess, some committee members have been looking too long at how
>> C++ does things? That language is utterly incapable of creating
>> anything small and simple.
>>
>
> And yet C and C++ programmers outnumber programmers of Bart's own
> language by millions. No language - except for yours, of course - is
> perfect. But it seems C and C++ are both pretty good for getting the
> job done.
My systems language DOES have lots of very nice micro-features compared
to C. And usually they are presented in a tidy fashion. I don't think
there's any argument about that. (Look at C's ugly X-macros for example.)
My language is not perfect; a big thing it's missing is Pascal-style
enumeration types that are type-safe, that would detect a lot of errors.
But as a systems language, it is much more enticing than C.
(Today I need to start porting a 20Kloc application in my language, to
C; proper C not machine transpiling. I'm not looking forward to all that
typing!)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-26 15:49 +0100 |
| Message-ID | <10g742m$ev96$2@dont-email.me> |
| In reply to | #395494 |
On 26/11/2025 13:05, bart wrote: > On 26/11/2025 07:55, David Brown wrote: >> On 25/11/2025 22:58, bart wrote: >>> On 25/11/2025 20:25, David Brown wrote: >>>> On 24/11/2025 23:27, bart wrote: >>> >>>>> On interesting use-case for literals was short-strings; 128 bits >>>>> allowed character literals up to 16 characters: 'ABCDEFGHIJKLMNOP'. >>>>> I think C is still stuck at one, or 4 if you're lucky.) >>>>> >>>> >>>> I have no idea or opinion on why /you/ might want 128-bit or larger >>>> integer types. I believe there is very little use for "normal" >>>> numbers - things you might want to write as literals, calculate >>>> with, and read or write - that won't fit perfectly well within 64 >>>> bit types, and would not be better served by arbitrary sized integers. >>> >>> >>>> Arbitrary sized integers are a very different kettle of fish from >>>> large fixed-size integers, and are not something that would fit in >>>> the C language - they need a library. >>> >>> Really? I wouldn't have thought there was any appreciable difference >>> between the code for multiplying two 100,000-bit BitInts, and that >>> for multiplying two abitrary-precision ints that happen to be 100,000 >>> bits. >>> >> >> You are looking at things in completely the wrong way. >> >> Long before you start thinking of how to implement operations, think >> about what the types are at a fundamental level. >> >> A fixed-size integer is a value type of fixed, compile-time size. It >> is passed around as a value. Local instances can be put on a stack >> with compile-time fixed offsets (and thus using [sp + N] access modes >> in an implementation). The type has a single simple and obvious >> (albeit slightly implementation-dependent) bit representation. A >> _BitInt(32) will be identical at the low level to an int32_t. Bigger >> _BitInt types are just the same, only bigger. There is no difference >> in concept, or representation, whether the type is 32-bit or 32 >> million bits. >> >> An arbitrary sized integer is a dynamic type with variable size. The >> base object will hold information about pointers to data, sizes for >> that stored data - including both how much is in use, and how much is >> available. There are endless ways to make such types - you can >> support multiple allocation parts, or use a single contiguous >> allocation. You can store the data in binary, or some kind of packed >> decimal, or other formats. Passing them around might mean just >> passing around the base object, but sometimes you need to make deep >> copies. Operations might lead to heap memory allocations or >> deallocations. >> >> They are so /totally/ different that any similarities in the way you >> do a particular arithmetic operation are completely incidental. > > But BitInts /will/ need runtime library support? No, not if an implementation generates the code inline (as clang appears to do). An implementation /may/ use helper functions from a language support library - gcc does that, depending on the sizes of the _BitInt and the operations you are doing. That is no different from all sorts of other things in the language, and is not some external runtime library. Your code will not be calling "bigint.dll" or anything like that. > > I've acknowledged in my last post that arbitrary precision would have > memory management issues, /if/ you wanted to add them to the language in > such a way that, if variables 'a b c d' had such a type, you can write: > > a = b + c * d; > Arbitrary precision integers have memory management issues no matter how you want to use them. They need dynamic memory. Either the language has some kind of automatic memory management (reference counting, RAII, garbage collection, etc.), or it must be done manually. It does not matter if you use operator notation or function-call notation - except that you cannot use operator notation with manual memory management. > This is not what I had in mind; such arithmetic would use explicit > function calls with explicit management of intermediates (like GMP). > > So from this point of view, fixed-size BitInts are better, but also a > higher level ability than I would have considered added to the language. _BitInt's are certainly better in that they are scalar types with value semantics and no need for any dynamic memory. Of course arbitrary precision integers have other advantages. Although for some use-cases either would work, each can be significantly more appropriate for different situations. To my mind, the need for dynamic memory would mean arbitrary precision integers are not appropriate for C - either at the core language level, or as part of the standard library. I think it is reasonable to have different opinions as to how well fixed-size _BitInts are appropriate to have in the C core language, though as they are now in C23, the point is now moot. > > Even if BitInts were restricted to saner and smaller sizes, I'd consider > actual arithmetic on 128 bits up to a few K bits and above a specialist, > niche application. > Fair enough. > But logic operations (== & | ^) on unsigned BitInts are more reasonable > (because they implement some features of bit-sets). > > For arithmetic on considerably larger numbers, I still think arbitrary > precision is the best bet. > > Also fair enough. I don't think anyone is likely to be multiplying million-bit _BitInts in real code. But I don't think it is appropriate for the language standard to pick some arbitrary size and say "below that is fine, above that is too big and programmers should use something else". I don't think it is appropriate for compiler implementers either. (They may pick limits based on how they implement things internally - that's not an arbitrary limit.) Different people have different needs, and no particular limit fits all use-cases. >>> Structs and arrays again spring to mind if you just want an anonymous >>> data block. (I wonder why it has to be bit-precise for byte-addressed >>> memory?) >>> >> >> If I have a processor that has 256-bit vector registers, then moving >> data by loading and storing 256-bit blocks is going to be more >> efficient than doing a loop of 16 byte moves. Today, I would use >> uint64_t for the task, as the biggest type available. Why does it >> have to be bit- precise? It must be bit-precise because I would want >> to move 256 bits - not 255 bits or 257 bits. > > By bit-precise I mean being able to specify 255 and 257 bits! Memory is > usually expression in bytes or words; not bits. > "Bit-precise" means "exactly the bit count I specify". I agree that for moving memory around, I would pick a bit size that is a multiple of 8, and very likely a power of 2. >> >>> >>>> * Cryptography. IO is irrelevant here. But a variety of sizes are >>>> useful including 56, 80, 112, 128, 168, 192, 384, 512, 521, 2048, >>>> 3072, 4096, 7680, 8096 bits. There may be more common sizes - I'm >>>> just thinking of DES, 3DES, AES, SHA, ECC and RSA. >>> >>> And I'm again curious as to what /non-numeric/ use a 200,000-bit >>> BitInt might be put to, that is not better served by an array or struct. >>> >> >> I don't have a use for a 200,000 bit integer type at the moment. But >> I cannot imagine any reason why the language specifications should >> have arbitrary limits. Are you suggesting that the C standards show >> say "You can have _BitInt's up to 8096 because someone found a use for >> them, but you can't have size 8097 and above - and 200,000 is right >> out - because someone else can't imagine they are useful" ? > > And yet, integer widths have been roughly capped at double a machine > word size for decades - until 64 bits came along and then few even > bothered with double-width. > > Nobody thought how easy it would be to just have an integer of whatever > size you like - you just generate whatever code is necessary to make it > happen. We could have had BitInts on 32- and even 16-bit machines if > only somebody had thought of it! > We certainly could have had these. And people /have/ thought about it. There are endless examples of libraries and "home-made" big integer types. The reason we have them /now/ is that some people have felt they were useful enough for their purposes that they bothered doing the work to implement them in clang and then write proposals to add them to the C standards. Getting something like this into standard C takes time, expertise, effort and money - commodities that are usually far less easily available than ideas and imagination. > >> >> An implementation can - indeed, must - set a limit to the sizes it >> supports. Implementations can have many reasons to do so. Some >> implementations might have quite low limits (the size of "long long >> int" is the minimum allowed for conformance), but then that >> implementation might not be so useful to some people. >> >>> Maybe bit-sets? But there are no special features for accessing >>> individual bits. >>> >>> That BigInt() defaults to a signed integer (twos complement?), even >>> for very large sizes suggests that /numeric/ applications are a >>> primary use. >>> >> >> Obviously the C standards should have made "_BitInt" signed up to size >> 73 bits, and unsigned from then on. That would have been /so/ much >> clearer and simpler for everyone. > > Or unsigned could have been the default. > That would have been possible, but pointlessly out of step with all other integer types in C. > >>>> >>>> >>>> Smaller sizes can be useful for holding RGB pixel values, audio >>>> data, etc. >>> >>> Except that these are probably rounded up, to the next multiple of >>> two. So the benefit is minimal; it do something with those padding bits. >>> >> >> I write C code. I want my C code to be clear and represent what I am >> handling, and then let the compiler do its job of generating efficient >> results. So if I am dealing with data that is 24-bit signed integer >> data, then _BitInt(24) (especially with a typedef name) is more >> accurate source code than "int" or "int32_t". > > Suddenly everybody is dealing with signed values of 12 and 24 bits! > I don't think I would count Michael and I as "everybody". But it is certainly true that data from hardware sensors is often of a resolution that does not fit exactly in a standard integer type size, and _BitInt - signed or unsigned - can be a clear way to work with these values. > I actually had exactly that feature: > > int*3 a # from 1980s; a 3-byte or 24-bit signed type > int:24 b # from 1990s; a 24-bit signed type > > Or at least, I had the syntax. Those odd values would have been > rejected, as I didn't have support for them, or a way to emulate them > (which is what BitInt(24) appears to do). > > So I got rid of the feature and ended up with int32 and then i32. (I > think Zig allows types like i24 and i123456, presumably built upon > LLVM's integer types which go up to 2**23 or 2**24 bits.) > > >>> You've heard of 'code smell'? Well, this is the same, but for features. >>> >> >> Your nose is blocked. Or to be more accurate, you are so obsessed >> with the idea that your own language is "perfect" that you simply >> cannot accept that other languages might have good features that your >> language does not, or that other programmers might want features that >> your language does not have. >> >>> I've been doing this stuff long enough to recognise when a feature is >>> over-elaborate, over-specified and over-flexible. You need to know >>> the minimum you can get away with, not the maximum! >> >> NIH syndrome combined with megalomania. Other people do this stuff >> better than you. > > I've noticed that other languages tend to go overboard with things, and > now it's happening to C. > What seems to happen is that you read a little bit about a feature, then go bananas about how terrible it is because it is different from your own language - without learning about the feature, its use-cases, or why it was added to the language. When you are called out, and when - usually through many, many tea-spoon explanations - you understand the feature, you stick to your guns and continue to complain about it no matter how silly you sound. It's okay to think that simpler is sometimes better, or that you disagree with some of the newer features in C. People have different opinions on the direction newer C standards have taken. But if you want to critique a feature, do so on the basis of an understanding of the feature, an understanding of why it was added and what people might use it for, and an understanding of what pros and cons it has compared to alternatives. "I'm a genius language designer and I don't have this feature and I don't want to use it" is not a rational argument. > I made a decision to keep my systems language at a certain level > regarding such things as the type system, while having lots of > convenient micro-features: > > print int@(x+y).[52..62] > > This type-puns a float64 r-value expression into an int, and extracts > that bitfield (which is the unsigned exponent field when float64 uses > iee754). > > I'd be interested to see how you can do this better, using general > language features (adding a dedicated .exponent property to floats would > be cheating!). > What an absurd thing to ask for. You have a special feature in your language for writing obscure things that are rarely if ever useful in normal coding. Of course you can write the same effect in C, in a simple function a few lines long. And that's the way it should be - obscure things should not take up cognitive space that makes common things harder. > >>> >>> Let me guess, some committee members have been looking too long at >>> how C++ does things? That language is utterly incapable of creating >>> anything small and simple. >>> >> >> And yet C and C++ programmers outnumber programmers of Bart's own >> language by millions. No language - except for yours, of course - is >> perfect. But it seems C and C++ are both pretty good for getting the >> job done. > > My systems language DOES have lots of very nice micro-features compared > to C. And usually they are presented in a tidy fashion. I don't think > there's any argument about that. (Look at C's ugly X-macros for example.) > > My language is not perfect; a big thing it's missing is Pascal-style > enumeration types that are type-safe, that would detect a lot of errors. > > But as a systems language, it is much more enticing than C. And that is presumably why it is so much more popular than C. > > (Today I need to start porting a 20Kloc application in my language, to > C; proper C not machine transpiling. I'm not looking forward to all that > typing!)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-26 15:44 +0000 |
| Message-ID | <10g779l$h980$1@dont-email.me> |
| In reply to | #395501 |
On 26/11/2025 14:49, David Brown wrote:
> On 26/11/2025 13:05, bart wrote:
>> On 26/11/2025 07:55, David Brown wrote:
>>> NIH syndrome combined with megalomania. Other people do this stuff
>>> better than you.
>> I made a decision to keep my systems language at a certain level
>> regarding such things as the type system, while having lots of
>> convenient micro-features:
>>
>> print int@(x+y).[52..62]
>>
>> This type-puns a float64 r-value expression into an int, and extracts
>> that bitfield (which is the unsigned exponent field when float64 uses
>> iee754).
>>
>> I'd be interested to see how you can do this better, using general
>> language features (adding a dedicated .exponent property to floats
>> would be cheating!).
>>
>
> What an absurd thing to ask for.
You said, "Other people do this stuff better than you". Presumably,
devising language features. So I gave an example of a small task, and
asked which features those people would devise, or what solution they
would use.
> You have a special feature in your
> language for writing obscure things that are rarely if ever useful in
> normal coding.
Yes, I call them 'micro-features'.
The examples showed rvalue type-punning and bitfield extraction, which
were recent examples in this thread.
In C, the solution for my example might look like this:
double temp = x+y;
printf("%llu", ((*(uint64_t*)&temp)>>52) & 2047);
Rather more fiddly and error prone, and it needs an auxiliary statement
that makes it awkward to embed into an expression. (I also had to think
twice about that format code.)
BTW here is how my C transpiler translated it, so it /can/ be done
without explicit temporaries:
mminc$m_print_u64(msysc$m_getdotslice((i64)msysc$m_tp_r64toi64((x +
y)),(i64)52,(i64)62),NULL);
> Of course you can write the same effect in C, in a
> simple function a few lines long.
Yes, everyone can invent their own solutions. (I've just taken that a
few steps further with an entire language.)
> And that's the way it should be -
> obscure things should not take up cognitive space that makes common
> things harder.
But _BitInt(12) was also used as an example of saving a few lines of
code or having to write a function or macro (there, to sign-extend the
low-N bits of an integer value, when N is known at compile-time).
>> But as a systems language, it is much more enticing than C.
>
> And that is presumably why it is so much more popular than C.
If it was generally available then I think quite a few would prefer it.
As it is I enjoy the benefits myself.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-26 17:37 +0100 |
| Message-ID | <10g7aci$icq7$1@dont-email.me> |
| In reply to | #395502 |
On 26/11/2025 16:44, bart wrote:
> On 26/11/2025 14:49, David Brown wrote:
>> On 26/11/2025 13:05, bart wrote:
>>> On 26/11/2025 07:55, David Brown wrote:
>
>>>> NIH syndrome combined with megalomania. Other people do this stuff
>>>> better than you.
>
>>> I made a decision to keep my systems language at a certain level
>>> regarding such things as the type system, while having lots of
>>> convenient micro-features:
>>>
>>> print int@(x+y).[52..62]
>>>
>>> This type-puns a float64 r-value expression into an int, and extracts
>>> that bitfield (which is the unsigned exponent field when float64 uses
>>> iee754).
>>>
>>> I'd be interested to see how you can do this better, using general
>>> language features (adding a dedicated .exponent property to floats
>>> would be cheating!).
>>>
>>
>> What an absurd thing to ask for.
>
> You said, "Other people do this stuff better than you". Presumably,
> devising language features. So I gave an example of a small task, and
> asked which features those people would devise, or what solution they
> would use.
>
The "other people" I referred to are the folks behind the C language,
not me.
>> You have a special feature in your language for writing obscure
>> things that are rarely if ever useful in normal coding.
>
> Yes, I call them 'micro-features'.
>
> The examples showed rvalue type-punning and bitfield extraction, which
> were recent examples in this thread.
>
> In C, the solution for my example might look like this:
>
> double temp = x+y;
> printf("%llu", ((*(uint64_t*)&temp)>>52) & 2047);
>
No, that's not how a C solution would work. People who know C would
know that. As a challenge for you, see if you can spot your mistake.
(And of course if anyone wanted to do this stuff in real code, they'd
wrap things in a static inline "bit_range_extract" function.)
> Rather more fiddly and error prone, and it needs an auxiliary statement
> that makes it awkward to embed into an expression. (I also had to think
> twice about that format code.)
>
> BTW here is how my C transpiler translated it, so it /can/ be done
> without explicit temporaries:
>
> mminc$m_print_u64(msysc$m_getdotslice((i64)msysc$m_tp_r64toi64((x +
> y)),(i64)52,(i64)62),NULL);
>
Avoiding explicit temporaries is not a goal to aspire to - unless you
are trying to squeeze performance from a poorly optimising compiler.
>
>> Of course you can write the same effect in C, in a simple function a
>> few lines long.
>
> Yes, everyone can invent their own solutions. (I've just taken that a
> few steps further with an entire language.)
>
>> And that's the way it should be - obscure things should not take up
>> cognitive space that makes common things harder.
>
> But _BitInt(12) was also used as an example of saving a few lines of
> code or having to write a function or macro (there, to sign-extend the
> low-N bits of an integer value, when N is known at compile-time).
>
No, what was shown was how _BitInt(12) could let people write clearer C
code than C without _BitInt. There was no comparison to other languages
or other features.
>
>>> But as a systems language, it is much more enticing than C.
>>
>> And that is presumably why it is so much more popular than C.
>
> If it was generally available then I think quite a few would prefer it.
Sure. Keep telling yourself that.
> As it is I enjoy the benefits myself.
>
That I /do/ believe - and I genuinely think it is great that you enjoy it.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-26 18:42 +0000 |
| Message-ID | <10g7hm2$lpsu$1@dont-email.me> |
| In reply to | #395503 |
On 26/11/2025 16:37, David Brown wrote:
> On 26/11/2025 16:44, bart wrote:
> The "other people" I referred to are the folks behind the C language,
> not me.
OK. The people who chose to make 'break' do two jobs, unfortunately in
parts of the language that can overlap in use; those people! (I guess
you mean the more recent lot.)
>> In C, the solution for my example might look like this:
>>
>> double temp = x+y;
>> printf("%llu", ((*(uint64_t*)&temp)>>52) & 2047);
>>
>
> No, that's not how a C solution would work. People who know C would
> know that. As a challenge for you, see if you can spot your mistake.
This was my point. (Although I can't see the problem, making it even
more pertinent.)
>
> (And of course if anyone wanted to do this stuff in real code, they'd
> wrap things in a static inline "bit_range_extract" function.)
Also my point: everyone will invent their own incompatible solutions for
this fundamental stuff.
You forgot about the type-punning part, which I guess needs yet another
inlined function,
>> Rather more fiddly and error prone, and it needs an auxiliary
>> statement that makes it awkward to embed into an expression. (I also
>> had to think twice about that format code.)
>>
>> BTW here is how my C transpiler translated it, so it /can/ be done
>> without explicit temporaries:
>>
>> mminc$m_print_u64(msysc$m_getdotslice((i64)msysc$m_tp_r64toi64((x
>> + y)),(i64)52,(i64)62),NULL);
>>
>
> Avoiding explicit temporaries is not a goal to aspire to - unless you
> are trying to squeeze performance from a poorly optimising compiler.
The memory temp involved a declaration which needs to exist outside of
the expression in standard C. While type-punning in C either means
writing to a union, or using & and applying a cast.
(My type-punning works on rvalues and will work on values in registers.)
> No, what was shown was how _BitInt(12) could let people write clearer C
> code than C without _BitInt. There was no comparison to other languages
> or other features.
But when it came my example, it could trivially be done with inline
functions, just like this could.
>>
>>>> But as a systems language, it is much more enticing than C.
>>>
>>> And that is presumably why it is so much more popular than C.
>>
>> If it was generally available then I think quite a few would prefer it.
>
> Sure. Keep telling yourself that.
Well, it would be a minority. Grown-up languages with decent syntax
exist such as Ada and Fortran; those are not that popular. People prefer
brace-based languages such as C, Java, Go, Zig, Rust.
Anything without braces isn't taken as seriously, eg. scripting languages.
>
>> As it is I enjoy the benefits myself.
>>
>
> That I /do/ believe - and I genuinely think it is great that you enjoy it.
>
I've had several opportunities to retire my language and switch to C.
Each time, I rejected that and chose to perservere with mine, despite
the extra problems of working with a language used by only one person on
the planet.
Then, because I genuinely considered it better, and now because I enjoy
working at it and with it. Using C feels like driving a model T.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-26 21:43 +0100 |
| Message-ID | <10g7oqf$ojir$1@dont-email.me> |
| In reply to | #395505 |
On 26/11/2025 19:42, bart wrote:
> On 26/11/2025 16:37, David Brown wrote:
>> On 26/11/2025 16:44, bart wrote:
>
>> The "other people" I referred to are the folks behind the C language,
>> not me.
>
> OK. The people who chose to make 'break' do two jobs, unfortunately in
> parts of the language that can overlap in use; those people! (I guess
> you mean the more recent lot.)
>
>>> In C, the solution for my example might look like this:
>>>
>>> double temp = x+y;
>>> printf("%llu", ((*(uint64_t*)&temp)>>52) & 2047);
>>>
>>
>> No, that's not how a C solution would work. People who know C would
>> know that. As a challenge for you, see if you can spot your mistake.
>
> This was my point. (Although I can't see the problem, making it even
> more pertinent.)
>
So you can claim to have a "better" solution than C, without knowing how
to write it correctly in C?
>>
>> (And of course if anyone wanted to do this stuff in real code, they'd
>> wrap things in a static inline "bit_range_extract" function.)
>
> Also my point: everyone will invent their own incompatible solutions for
> this fundamental stuff.
It is not remotely fundamental. Extracting groups of bits from the
representation of a type, especially a floating point type, is a niche
operation. (It can be an important operation - such as for software
floating point routines. But the people who write those are few, and
they know what they are doing.)
>
> You forgot about the type-punning part, which I guess needs yet another
> inlined function,
I didn't forget about anything. I didn't write the incorrect C code.
>
>>> Rather more fiddly and error prone, and it needs an auxiliary
>>> statement that makes it awkward to embed into an expression. (I also
>>> had to think twice about that format code.)
>>>
>>> BTW here is how my C transpiler translated it, so it /can/ be done
>>> without explicit temporaries:
>>>
>>>
>>> mminc$m_print_u64(msysc$m_getdotslice((i64)msysc$m_tp_r64toi64((x +
>>> y)),(i64)52,(i64)62),NULL);
>>>
>>
>> Avoiding explicit temporaries is not a goal to aspire to - unless you
>> are trying to squeeze performance from a poorly optimising compiler.
>
> The memory temp involved a declaration which needs to exist outside of
> the expression in standard C. While type-punning in C either means
> writing to a union, or using & and applying a cast.
>
"Type punning" refers to using a union to access or reinterpret the
underlying bit representation. Using references and a cast to do so is
UB, except when using pointers to character types. Neither involves
actually putting data into memory or the stack unless you are using a
compiler that can't optimise well - and then it is just a matter of less
efficient generated code.
> (My type-punning works on rvalues and will work on values in registers.)
>
>> No, what was shown was how _BitInt(12) could let people write clearer
>> C code than C without _BitInt. There was no comparison to other
>> languages or other features.
>
> But when it came my example, it could trivially be done with inline
> functions, just like this could.
>
Sure.
>
>
>>>
>>>>> But as a systems language, it is much more enticing than C.
>>>>
>>>> And that is presumably why it is so much more popular than C.
>>>
>>> If it was generally available then I think quite a few would prefer it.
>>
>> Sure. Keep telling yourself that.
>
> Well, it would be a minority. Grown-up languages with decent syntax
> exist such as Ada and Fortran; those are not that popular. People prefer
> brace-based languages such as C, Java, Go, Zig, Rust.
>
> Anything without braces isn't taken as seriously, eg. scripting languages.
>
What a /very/ strange way to distinguish or classify languages. And
what a bizarre way to generalise what people think, as though all
programmers share the same opinions.
>>
>>> As it is I enjoy the benefits myself.
>>>
>>
>> That I /do/ believe - and I genuinely think it is great that you enjoy
>> it.
>>
>
> I've had several opportunities to retire my language and switch to C.
> Each time, I rejected that and chose to perservere with mine, despite
> the extra problems of working with a language used by only one person on
> the planet.
>
> Then, because I genuinely considered it better, and now because I enjoy
> working at it and with it. Using C feels like driving a model T.
>
[toc] | [prev] | [next] | [standalone]
Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web