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 1 of 13 [1] 2 3 … 13 Next page →
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2025-10-22 09:45 -0300 |
| Subject | _BitInt(N) |
| Message-ID | <10dajlh$ko3c$1@dont-email.me> |
Is anyone using or planning to use this new C23 feature? What could be the motivation?
[toc] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-10-22 11:42 -0500 |
| Message-ID | <10db1p3$ongg$1@dont-email.me> |
| In reply to | #394650 |
On 10/22/2025 7:45 AM, Thiago Adams wrote: > > > Is anyone using or planning to use this new C23 feature? > What could be the motivation? > In my project, with my own compiler, I have made some use of it... Otherwise: Probably not until either it gets adopted by MSVC or I move off of Windows, whichever comes first at this rate. If MS keeps up the same speedy rate of C feature adoption (as they have for previous standards), might appear sometime around 2040. >
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2025-10-22 14:23 -0300 |
| Message-ID | <10db3up$piu1$1@dont-email.me> |
| In reply to | #394657 |
On 10/22/2025 1:42 PM, BGB wrote: > On 10/22/2025 7:45 AM, Thiago Adams wrote: >> >> >> Is anyone using or planning to use this new C23 feature? >> What could be the motivation? >> > > In my project, with my own compiler, I have made some use of it... > > Otherwise: > Probably not until either it gets adopted by MSVC or I move off of > Windows, whichever comes first at this rate. > > If MS keeps up the same speedy rate of C feature adoption (as they have > for previous standards), might appear sometime around 2040. > > >> > MSVC is funny, they add some C23 features without documenting or announcing them. You can look at it another way... MSVC is helping C not evolve too fast :D
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2025-10-22 14:25 -0300 |
| Message-ID | <10db41e$pjrf$1@dont-email.me> |
| In reply to | #394658 |
On 10/22/2025 2:23 PM, Thiago Adams wrote: > On 10/22/2025 1:42 PM, BGB wrote: >> On 10/22/2025 7:45 AM, Thiago Adams wrote: >>> >>> >>> Is anyone using or planning to use this new C23 feature? >>> What could be the motivation? >>> >> >> In my project, with my own compiler, I have made some use of it... >> The use case I have for _BitInt(N) N is dynamic, so I am not planning to use it.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-10-22 14:03 -0500 |
| Message-ID | <10dba0c$ongg$2@dont-email.me> |
| In reply to | #394659 |
On 10/22/2025 12:25 PM, Thiago Adams wrote:
> On 10/22/2025 2:23 PM, Thiago Adams wrote:
>> On 10/22/2025 1:42 PM, BGB wrote:
>>> On 10/22/2025 7:45 AM, Thiago Adams wrote:
>>>>
>>>>
>>>> Is anyone using or planning to use this new C23 feature?
>>>> What could be the motivation?
>>>>
>>>
>>> In my project, with my own compiler, I have made some use of it...
>>>
>
> The use case I have for _BitInt(N) N is dynamic, so I am not planning
> to use it.
>
In my compiler, only constant N is allowed.
N is allowed over a range of 1 to 16383, though anything large is
generally implemented with runtime calls:
1..64: Mapped to integer operations.
65..128: Mapped to 128-bit integer operations.
Optional partial support in my ISA.
Rest is runtime calls.
129..256: Runtime calls for 256-bit integer ops.
257+: Runtime calls for generic large integers.
Storage is padded to a multiple of 128 bits, with 16-byte alignment.
In my compiler:
Largest fully-supported integer type is 128 bits.
__int128, __uint128, unsigned __int128
Partial handling exists for 256-bit values, but they are not exposed as
their own types. Stuff for very large integers is mostly untested.
Ironically, while it does support large integer constants, its support
for very large integer constants generally involves representing them
inside the compiler as string literals (Base85 encoded).
IIRC, there is a limit of 128 bits for decimal literals though (so going
larger is only really possible with hexadecimal).
Contrast, say:
GCC: Refuses to support integer types over 64 bits on most targets tested;
Clang: Sorta works, but has a lot of limitations, like the inability to
have 128-bit integer literals.
Also maybe fun is the wonk that UTF-8 string literals in BGBCC are
effectively double-encoded. Though, actual scheme is a little more
complicated:
00: Escaped as 2-byte (C0-80).
01..7F: As-is
0080..00FF: Encodes Bytes 0x80..0xFF;
0100..06FF: Pass Through
0700..077F: Encodes 00..7F byte followed by 00.
0780..07FF: Encodes 0080..00FF.
0800..7FFF: Pass Through
8000..FFFF: Interpreted as a 2-byte pair (80..FF followed by 00..FF).
Some of this is an attempt to reduce the relative inefficiency of the
double-encoding scheme (the naive approach would effectively double the
encoded size of each codepoint, whereas this scheme as a worse case of
1.5x but on-average closer to 1x).
The above scheme might also slightly compact data expressed in string
literals if it happens to resemble these patterns (happens to match
UTF-8 byte sequences).
As noted, the ASCII byte followed by 00 is to try to avoid bloat for
string literals like "S\0o\0m\0e\0 \0S\0t\0r\0i\0n\0g\0\0" (sometimes
seen, most often in old code originally written for the Win32 API; in
the era when MS thought it was a good idea to move parts of the Win32
API over to UCS-2 / UTF-16 but not yet bothering to add UCS-2 string
literals to MSVC...).
For UTF-16 literals, it is basically M-UTF-8.
Note that non-BMP codepoints are:
Double encoded, for UTF-8 literals;
Encoded as surrogate pairs for UTF-16 (or UTF-32) literals.
Where, for the base-level encoding, values above 010000 may instead
potentially encode intra-string LZ matches (as a way to compactify large
string literals and text blobs). Though, this is optional and not
enabled ATM IIRC (not always 100% stable; and edge cases here may turn
large strings into confetti).
Though, for large numbers or similar encoded via strings, generally the
most space-efficient way ATM is Base85 or similar.
...
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-11-23 12:46 +0100 |
| Message-ID | <10fus62$hl69$1@solani.org> |
| In reply to | #394650 |
Am 22.10.25 um 14:45 schrieb Thiago Adams: > > > Is anyone using or planning to use this new C23 feature? > What could be the motivation? > > Saving memory by using the smallest multiple-of-8 N that will do. Also being able to use bit-fields wider than int. Saving memory for two reasons: * On small embedded systems where there is very little memory * For code that needs to be very fast on big systems to make data structures fit into cache Philipp
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-23 13:32 +0000 |
| Message-ID | <10fv2dm$3can9$1@paganini.bofh.team> |
| In reply to | #395383 |
Philipp Klaus Krause <pkk@spth.de> wrote:
> Am 22.10.25 um 14:45 schrieb Thiago Adams:
>>
>>
>> Is anyone using or planning to use this new C23 feature?
>> What could be the motivation?
>>
>>
>
> Saving memory by using the smallest multiple-of-8 N that will do.
IIUC nothing in the standard says that it is smallest multiple-of-8.
Using gcc-15.1 on AMD-64 is get 'sizeof(_BitInt(22))' equal to 4,
while the number cound fit in 3 bytes.
> Also
> being able to use bit-fields wider than int.
For me main gain is reasonably standard syntax for integers bigger
that 64 bits.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-23 13:59 +0000 |
| Message-ID | <10fv40v$1f7a2$1@dont-email.me> |
| In reply to | #395386 |
On 23/11/2025 13:32, Waldek Hebisch wrote: > Philipp Klaus Krause <pkk@spth.de> wrote: >> Am 22.10.25 um 14:45 schrieb Thiago Adams: >>> >>> >>> Is anyone using or planning to use this new C23 feature? >>> What could be the motivation? >>> >>> >> >> Saving memory by using the smallest multiple-of-8 N that will do. > > IIUC nothing in the standard says that it is smallest multiple-of-8. > Using gcc-15.1 on AMD-64 is get 'sizeof(_BitInt(22))' equal to 4, > while the number cound fit in 3 bytes. The rationale mentions a use-case where there is a custom processor that might actually have a 22-bit hardware types. Implementing such odd-size types on regular 8/16/32/64-bit hardware is full of problems if you want to do it without padding (in order to get the savings). On even with padding (to get the desired overflow semantics). Such as working out how pointers to them will work. >> Also >> being able to use bit-fields wider than int. > > For me main gain is reasonably standard syntax for integers bigger > that 64 bits. Standard syntax I guess would be something like int128_t and int256_t. Such wider integers tend to be powers of two. But there are two problems with _BitInt: * Any odd sizes are allowed, such as _BitInt(391) * There appears to be no upper limit on size, so _BitInt(2997901) is a valid type So what is the result type of multiplying values of those two types? Integer sizes greater than 1K or 2K bits should use an arbitrary precision type (which is how large _BitInts will likely be implemented anyway), where the precision is a runtime attribute.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-23 17:06 +0200 |
| Message-ID | <20251123170654.000056a9@yahoo.com> |
| In reply to | #395387 |
On Sun, 23 Nov 2025 13:59:59 +0000
bart <bc@freeuk.com> wrote:
> On 23/11/2025 13:32, Waldek Hebisch wrote:
> > Philipp Klaus Krause <pkk@spth.de> wrote:
> >> Am 22.10.25 um 14:45 schrieb Thiago Adams:
> >>>
> >>>
> >>> Is anyone using or planning to use this new C23 feature?
> >>> What could be the motivation?
> >>>
> >>>
> >>
> >> Saving memory by using the smallest multiple-of-8 N that will do.
> >
> > IIUC nothing in the standard says that it is smallest multiple-of-8.
> > Using gcc-15.1 on AMD-64 is get 'sizeof(_BitInt(22))' equal to 4,
> > while the number cound fit in 3 bytes.
>
> The rationale mentions a use-case where there is a custom processor
> that might actually have a 22-bit hardware types.
>
> Implementing such odd-size types on regular 8/16/32/64-bit hardware
> is full of problems if you want to do it without padding (in order to
> get the savings). On even with padding (to get the desired overflow
> semantics).
>
> Such as working out how pointers to them will work.
>
>
> >> Also
> >> being able to use bit-fields wider than int.
> >
> > For me main gain is reasonably standard syntax for integers bigger
> > that 64 bits.
>
> Standard syntax I guess would be something like int128_t and
> int256_t. Such wider integers tend to be powers of two.
>
> But there are two problems with _BitInt:
>
> * Any odd sizes are allowed, such as _BitInt(391)
>
> * There appears to be no upper limit on size, so _BitInt(2997901) is
> a valid type
>
Upper limit is implementation-defined.
On both existing implementations the limit (on 64-bit targets) appears
to be 2**16 or 2**16-1. I don't remember which one.
> So what is the result type of multiplying values of those two types?
>
I think, traditional C rules for integer types apply here as well: type
of result is the same as type of wider operand. It is arithmetically
unsatisfactory, but consistent with the rest of language.
And practically sufficient, because C programmers are already accustomed
to write statements like:
uint64_t foo(uint32_t x, uint16 y) { return (uint64_t)x*y; }
So it would be natural for them to write:
_BitInt(1536) foo(_BitInt(1024) x, _BitInt(512) y) {
return _BitInt(1536)x*y;
}
Since the pattern is so common already, optimizing compiler is likely to
understand the meaning and generate only necessary calculations.
Or, at least, to not generate too much of unnecessary calculations.
> Integer sizes greater than 1K or 2K bits should use an arbitrary
> precision type (which is how large _BitInts will likely be
> implemented anyway), where the precision is a runtime attribute.
>
I think, the Standard is written in such way that implementing _BitInt
as an arbitrary precision numbers, i.e. with number of bits held as part
of the data, is not allowed. Of course, Language Support Library can be
(and hopefully is, at least for gcc; clang is messy a.t.m.) based on
arbitrary precision core routines, but the API used by compiler should
be similar to GMP's mpn_xxx family of functions rather than GMP's
mpz_xxx family, i.e. # of bits as separate parameters from data arrays
rather than combined.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-24 10:29 +0100 |
| Message-ID | <10g18hq$28nc2$1@dont-email.me> |
| In reply to | #395388 |
On 23/11/2025 16:06, Michael S wrote:
> On Sun, 23 Nov 2025 13:59:59 +0000
> bart <bc@freeuk.com> wrote:
>
>> On 23/11/2025 13:32, Waldek Hebisch wrote:
>>> Philipp Klaus Krause <pkk@spth.de> wrote:
>>>> Am 22.10.25 um 14:45 schrieb Thiago Adams:
>>>>>
>>>>>
>>>>> Is anyone using or planning to use this new C23 feature?
>>>>> What could be the motivation?
>>>>>
>>>>>
>>>>
>>>> Saving memory by using the smallest multiple-of-8 N that will do.
>>>
>>> IIUC nothing in the standard says that it is smallest multiple-of-8.
>>> Using gcc-15.1 on AMD-64 is get 'sizeof(_BitInt(22))' equal to 4,
>>> while the number cound fit in 3 bytes.
>>
>> The rationale mentions a use-case where there is a custom processor
>> that might actually have a 22-bit hardware types.
>>
>> Implementing such odd-size types on regular 8/16/32/64-bit hardware
>> is full of problems if you want to do it without padding (in order to
>> get the savings). On even with padding (to get the desired overflow
>> semantics).
>>
>> Such as working out how pointers to them will work.
>>
>>
>>>> Also
>>>> being able to use bit-fields wider than int.
>>>
>>> For me main gain is reasonably standard syntax for integers bigger
>>> that 64 bits.
>>
>> Standard syntax I guess would be something like int128_t and
>> int256_t. Such wider integers tend to be powers of two.
>>
>> But there are two problems with _BitInt:
>>
>> * Any odd sizes are allowed, such as _BitInt(391)
>>
>> * There appears to be no upper limit on size, so _BitInt(2997901) is
>> a valid type
>>
>
> Upper limit is implementation-defined.
> On both existing implementations the limit (on 64-bit targets) appears
> to be 2**16 or 2**16-1. I don't remember which one.
>
>
>> So what is the result type of multiplying values of those two types?
>>
>
> I think, traditional C rules for integer types apply here as well: type
> of result is the same as type of wider operand. It is arithmetically
> unsatisfactory, but consistent with the rest of language.
There is one key difference between the _BitInt() types and other
integer types - with _BitInt(), there are no automatic promotions to
other integer types. Thus if you are using _BitInt() operands in an
arithmetic expression, these are not promoted to "int" or "unsigned int"
even if they are smaller (lower rank). If you mix _BitInt()'s of
different sizes, then the smaller one is first converted to the larger
type. And if _BitInt(N) is mixed with unsigned _BitInt(N), that will
mean the signed operand is converted to an unsigned _BitInt(N) -
something that I think is "arithmetically unsatisfactory", as you put it.
> And practically sufficient, because C programmers are already accustomed
> to write statements like:
> uint64_t foo(uint32_t x, uint16 y) { return (uint64_t)x*y; }
>
> So it would be natural for them to write:
> _BitInt(1536) foo(_BitInt(1024) x, _BitInt(512) y) {
> return _BitInt(1536)x*y;
> }
>
> Since the pattern is so common already, optimizing compiler is likely to
> understand the meaning and generate only necessary calculations.
> Or, at least, to not generate too much of unnecessary calculations.
>
>> Integer sizes greater than 1K or 2K bits should use an arbitrary
>> precision type (which is how large _BitInts will likely be
>> implemented anyway), where the precision is a runtime attribute.
>>
>
> I think, the Standard is written in such way that implementing _BitInt
> as an arbitrary precision numbers, i.e. with number of bits held as part
> of the data, is not allowed.
Correct. _BitInt(N) is a signed integer type with precisely N value
bits. It can have padding bits if necessary (according to the target
ABI), but it can't have any other information.
> Of course, Language Support Library can be
> (and hopefully is, at least for gcc; clang is messy a.t.m.) based on
> arbitrary precision core routines, but the API used by compiler should
> be similar to GMP's mpn_xxx family of functions rather than GMP's
> mpz_xxx family, i.e. # of bits as separate parameters from data arrays
> rather than combined.
>
Yes, exactly. At the call site, the size of the _BitInt type is always
a known compile-time constant, so it can easily be passed on. Thus :
_BitInt(N) x;
_BitInt(M) y;
_BitInt(NM) z = x * y;
can be implemented as something like :
__bit_int_signed_mult(NM, (unsigned char *) &z,
N, (const unsigned char *) &x,
M, (const unsigned char *) &y);
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-24 11:17 +0000 |
| Message-ID | <10g1erh$2b2cf$1@dont-email.me> |
| In reply to | #395400 |
On 24/11/2025 09:29, David Brown wrote:
> On 23/11/2025 16:06, Michael S wrote:
>> On Sun, 23 Nov 2025 13:59:59 +0000
>> bart <bc@freeuk.com> wrote:
>>> So what is the result type of multiplying values of those two types?
>>>
>>
>> I think, traditional C rules for integer types apply here as well: type
>> of result is the same as type of wider operand. It is arithmetically
>> unsatisfactory, but consistent with the rest of language.
>
> There is one key difference between the _BitInt() types and other
> integer types - with _BitInt(), there are no automatic promotions to
> other integer types. Thus if you are using _BitInt() operands in an
> arithmetic expression, these are not promoted to "int" or "unsigned int"
> even if they are smaller (lower rank). If you mix _BitInt()'s of
> different sizes, then the smaller one is first converted to the larger
> type.
>> I think, the Standard is written in such way that implementing _BitInt
>> as an arbitrary precision numbers, i.e. with number of bits held as part
>> of the data, is not allowed.
> Correct. _BitInt(N) is a signed integer type with precisely N value
> bits. It can have padding bits if necessary (according to the target
> ABI), but it can't have any other information.
>
>> Of course, Language Support Library can be
>> (and hopefully is, at least for gcc; clang is messy a.t.m.) based on
>> arbitrary precision core routines, but the API used by compiler should
>> be similar to GMP's mpn_xxx family of functions rather than GMP's
>> mpz_xxx family, i.e. # of bits as separate parameters from data arrays
>> rather than combined.
>>
>
> Yes, exactly. At the call site, the size of the _BitInt type is always
> a known compile-time constant, so it can easily be passed on. Thus :
>
> _BitInt(N) x;
> _BitInt(M) y;
> _BitInt(NM) z = x * y;
So what is NM here; is it N*M (the potential maximum size of the
result), or max(N, M)?
It sounds like the max precision you get will be the latter.
> can be implemented as something like :
>
> __bit_int_signed_mult(NM, (unsigned char *) &z,
> N, (const unsigned char *) &x,
> M, (const unsigned char *) &y);
>
>
How would you write a generic user function that operates on any size
BitInt? For example:
_BitInt(?) bi_square(_BitInt(?));
Even if you passed the size as a parameter, there would be a problem
with the BitInt type.
This assumes BitInts are passed and returned by value, but even using
BitInt* wouldn't help.
This sets it apart from arrays, where you also define very large, fixed
size arrays, but can use a T(*)[] type to write generic functions, that
take an additional length parameter.
This will be for a particular T, but for BitInt, T is also fixed; it
happens to be an implicit bit type.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-24 05:12 -0800 |
| Message-ID | <875xaz4lsj.fsf@example.invalid> |
| In reply to | #395401 |
bart <bc@freeuk.com> writes:
> On 24/11/2025 09:29, David Brown wrote:
>> On 23/11/2025 16:06, Michael S wrote:
>>> On Sun, 23 Nov 2025 13:59:59 +0000
>>> bart <bc@freeuk.com> wrote:
>
>>>> So what is the result type of multiplying values of those two types?
>>>>
>>>
>>> I think, traditional C rules for integer types apply here as well: type
>>> of result is the same as type of wider operand. It is arithmetically
>>> unsatisfactory, but consistent with the rest of language.
>> There is one key difference between the _BitInt() types and other
>> integer types - with _BitInt(), there are no automatic promotions to
>> other integer types. Thus if you are using _BitInt() operands in an
>> arithmetic expression, these are not promoted to "int" or "unsigned
>> int" even if they are smaller (lower rank). If you mix _BitInt()'s
>> of different sizes, then the smaller one is first converted to the
>> larger type.
>
>>> I think, the Standard is written in such way that implementing _BitInt
>>> as an arbitrary precision numbers, i.e. with number of bits held as part
>>> of the data, is not allowed.
>
>> Correct. _BitInt(N) is a signed integer type with precisely N value
>> bits. It can have padding bits if necessary (according to the
>> target ABI), but it can't have any other information.
>>
>>> Of course, Language Support Library can be
>>> (and hopefully is, at least for gcc; clang is messy a.t.m.) based on
>>> arbitrary precision core routines, but the API used by compiler should
>>> be similar to GMP's mpn_xxx family of functions rather than GMP's
>>> mpz_xxx family, i.e. # of bits as separate parameters from data arrays
>>> rather than combined.
>>>
>> Yes, exactly. At the call site, the size of the _BitInt type is
>> always a known compile-time constant, so it can easily be passed
>> on. Thus :
>> _BitInt(N) x;
>> _BitInt(M) y;
>> _BitInt(NM) z = x * y;
>
> So what is NM here; is it N*M (the potential maximum size of the
> result), or max(N, M)?
I made the same mistake in my previous post, but corrected it before
posting it. The required size for the product in N+M bits, not N*M.
For example, N=32, M=64 -> NM=96.
[...]
> How would you write a generic user function that operates on any size
> BitInt? For example:
>
> _BitInt(?) bi_square(_BitInt(?));
I don't think you can. Each _BitInt(N) type is distinct.
You could have a function that operates on arguments of type
[unsigned] _BitInt(BITINT_MAXWIDTH) and depend on implicit
conversions, but that's likely to be horribly inefficient.
Or you can replace BITINT_MAXWIDTH by the maximum width you happen to
need in your application.
[...]
--
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-24 14:49 +0100 |
| Message-ID | <10g1nol$2f8lb$1@dont-email.me> |
| In reply to | #395401 |
On 24/11/2025 12:17, bart wrote: > On 24/11/2025 09:29, David Brown wrote: >> On 23/11/2025 16:06, Michael S wrote: >>> On Sun, 23 Nov 2025 13:59:59 +0000 >>> bart <bc@freeuk.com> wrote: > >>>> So what is the result type of multiplying values of those two types? >>>> >>> >>> I think, traditional C rules for integer types apply here as well: type >>> of result is the same as type of wider operand. It is arithmetically >>> unsatisfactory, but consistent with the rest of language. >> >> There is one key difference between the _BitInt() types and other >> integer types - with _BitInt(), there are no automatic promotions to >> other integer types. Thus if you are using _BitInt() operands in an >> arithmetic expression, these are not promoted to "int" or "unsigned >> int" even if they are smaller (lower rank). If you mix _BitInt()'s of >> different sizes, then the smaller one is first converted to the larger >> type. > >>> I think, the Standard is written in such way that implementing _BitInt >>> as an arbitrary precision numbers, i.e. with number of bits held as part >>> of the data, is not allowed. > >> Correct. _BitInt(N) is a signed integer type with precisely N value >> bits. It can have padding bits if necessary (according to the target >> ABI), but it can't have any other information. >> >>> Of course, Language Support Library can be >>> (and hopefully is, at least for gcc; clang is messy a.t.m.) based on >>> arbitrary precision core routines, but the API used by compiler should >>> be similar to GMP's mpn_xxx family of functions rather than GMP's >>> mpz_xxx family, i.e. # of bits as separate parameters from data arrays >>> rather than combined. >>> >> >> Yes, exactly. At the call site, the size of the _BitInt type is >> always a known compile-time constant, so it can easily be passed on. >> Thus : >> >> _BitInt(N) x; >> _BitInt(M) y; >> _BitInt(NM) z = x * y; > > So what is NM here; is it N*M (the potential maximum size of the > result), or max(N, M)? No, it is whatever you want it to be. I didn't want to use the next letter after N because _BitInt(O) could easily be misunderstood. But of course NM could be misunderstood too. Perhaps N1, N2 and N3 would have been better choices than N, M and NM. You pick the size of "z" here according to your needs for your code. The multiplication will be done, logically, at max(N, M) bits. The result will then be converted to NM bits. Like always in C, the semantics of the calculation is entirely independent of the type of the variable you assign the results to. And like always in C, the compiler may take advantage of knowledge of the assigned type in order to give more efficient code, as long as it does not stray from giving the same value as if it took the code literally. So if you want the full range of values of x and y to be usable here, then NM would have to be N * M. But you would also need a cast, such as "_BitInt(NM) z = (_BitInt(NM)) x * y;", just as you do if you want to multiply two 32-bit ints as a 64-bit operation. Alternatively, you might know more about the values that might be in x and y, and have a smaller NM (though you still need a cast if it is greater than both N and M). Or you might be using unsigned types and want the wrapping / masking behaviour. The point was not what size NM is, but that it is known to the compiler at the time of writing the expression. > > It sounds like the max precision you get will be the latter. > > >> can be implemented as something like : >> >> __bit_int_signed_mult(NM, (unsigned char *) &z, >> N, (const unsigned char *) &x, >> M, (const unsigned char *) &y); >> >> > > > How would you write a generic user function that operates on any size > BitInt? For example: > > _BitInt(?) bi_square(_BitInt(?)); > You can't. _BitInt(N) and _BitInt(M) are distinct types, for differing N and M. You can't write a generic user function in C that implements "T foo(T)" where T can be "int", "short", "long int", or other types. C simply does not have type-generic functions. You /can/ write generic macros that handle different _BitInt types, but that would quickly get painful given that you'd need a case for each size of _BitInt you wanted for the _Generic macro. If you want generics, you are better off with a language that supports generics, such as C++. > Even if you passed the size as a parameter, there would be a problem > with the BitInt type. Yes. But you could use a void* pointer for more generic parameters. However, _BitInt types are for "bit-precise integer types". They are for specific fixed sizes, not for arbitrary precision integers. They are not ideally suited for tasks for which they were not designed - that's hardly surprising. > > This assumes BitInts are passed and returned by value, but even using > BitInt* wouldn't help. Yes, they are passed around as values - they are integer types and are passed around like other integer types. (Implementations may use stack blocks and pointers for passing the values around if they are too big for registers, just as implementations can do with any value type. That's an implementation detail - logically, they are passed and returned as values.) > > This sets it apart from arrays, where you also define very large, fixed > size arrays, but can use a T(*)[] type to write generic functions, that > take an additional length parameter. _BitInt's are fixed-size integer types, not arrays. Again, it is not then surprising that they are different from arrays. > > This will be for a particular T, but for BitInt, T is also fixed; it > happens to be an implicit bit type. > _BitInt's are not arrays, they are scalars - they are integer types. There is no concept of a type "_BitInt" - they always have compile-time fixed sizes, such as "_BitInt(12)". So the idea of passing around generic _BitInt's makes no more sense than passing around any other kind of generic integer types. (Of course you can have an array of _BitInt's of any given size.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-24 17:23 -0800 |
| Message-ID | <87h5ui3nx8.fsf@example.invalid> |
| In reply to | #395417 |
David Brown <david.brown@hesbynett.no> writes:
> On 24/11/2025 12:17, bart wrote:
>> On 24/11/2025 09:29, David Brown wrote:
[...]
> So if you want the full range of values of x and y to be usable here,
> then NM would have to be N * M. But you would also need a cast, such
> as "_BitInt(NM) z = (_BitInt(NM)) x * y;", just as you do if you want
> to multiply two 32-bit ints as a 64-bit operation.
N + M, not N * M.
> Alternatively, you might know more about the values that might be in x
> and y, and have a smaller NM (though you still need a cast if it is
> greater than both N and M). Or you might be using unsigned types and
> want the wrapping / masking behaviour.
>
> The point was not what size NM is, but that it is known to the
> compiler at the time of writing the expression.
>
>> It sounds like the max precision you get will be the latter.
>>
>>> can be implemented as something like :
>>>
>>> __bit_int_signed_mult(NM, (unsigned char *) &z,
>>> N, (const unsigned char *) &x,
>>> M, (const unsigned char *) &y);
>>>
>>>
>> How would you write a generic user function that operates on any
>> size BitInt? For example:
>> _BitInt(?) bi_square(_BitInt(?));
>>
>
> You can't. _BitInt(N) and _BitInt(M) are distinct types, for
> differing N and M. You can't write a generic user function in C that
> implements "T foo(T)" where T can be "int", "short", "long int", or
> other types. C simply does not have type-generic functions.
Sort of. C23 defines the term "generic function" (N3220 7.26.5.1,
string search functions). For example, strchr() can take a const void*
argument and return a const void* result, or it can take a void*
argument and return a void* result. (C++ does this by having two
overloaded strchr() functions.)
These "generic functions" are (almost certainly) implemented as macros
that use _Generic. If you bypass the macro definition, you get the
function that can take a const char* and return a char*.
So C doesn't have type-generic functions, but it does have feature that
let you implement things that act like type-generic functions.
> You /can/ write generic macros that handle different _BitInt types,
> but that would quickly get painful given that you'd need a case for
> each size of _BitInt you wanted for the _Generic macro.
Indeed. A _Generic selection that handles all the ordinary non-extended
integer types needs to handle 12 cases if I'm counting correctly, which
is feasible. But the addition of bit-precise types adds
BITINT_MAXWIDTH*2-1 new distinct predefined types, and a generic
selection would need one case for each.
However, you could have a function that takes a void*, a size, and a
width as arguments and operates on a _BitInt(?) or unsigned _BitInt(?)
type. In fact, gcc has internal functions like that for multiplication
and division. (You mentioned something like that in text that I've
snipped.)
[...]
>> This assumes BitInts are passed and returned by value, but even
>> using BitInt* wouldn't help.
>
> Yes, they are passed around as values - they are integer types and are
> passed around like other integer types. (Implementations may use
> stack blocks and pointers for passing the values around if they are
> too big for registers, just as implementations can do with any value
> type. That's an implementation detail - logically, they are passed and
> returned as values.)
Yes, and in general a _BitInt argument has to be copied to the
corresponding parameter, since a change to the parameter can't affect
the value of the argument.
But passing huge _BitInts by value is no more problematic than passing
huge structs by value.
[...]
--
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 07:56 +0100 |
| Message-ID | <10g3juu$3688o$1@dont-email.me> |
| In reply to | #395447 |
On 25/11/2025 02:23, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 24/11/2025 12:17, bart wrote: >>> On 24/11/2025 09:29, David Brown wrote: > [...] >> So if you want the full range of values of x and y to be usable here, >> then NM would have to be N * M. But you would also need a cast, such >> as "_BitInt(NM) z = (_BitInt(NM)) x * y;", just as you do if you want >> to multiply two 32-bit ints as a 64-bit operation. > > N + M, not N * M. Of course. (I /really/ should have picked a different third identifier...) > >> Alternatively, you might know more about the values that might be in x >> and y, and have a smaller NM (though you still need a cast if it is >> greater than both N and M). Or you might be using unsigned types and >> want the wrapping / masking behaviour. >> >> The point was not what size NM is, but that it is known to the >> compiler at the time of writing the expression. >> >>> It sounds like the max precision you get will be the latter. >>> >>>> can be implemented as something like : >>>> >>>> __bit_int_signed_mult(NM, (unsigned char *) &z, >>>> N, (const unsigned char *) &x, >>>> M, (const unsigned char *) &y); >>>> >>>> >>> How would you write a generic user function that operates on any >>> size BitInt? For example: >>> _BitInt(?) bi_square(_BitInt(?)); >>> >> >> You can't. _BitInt(N) and _BitInt(M) are distinct types, for >> differing N and M. You can't write a generic user function in C that >> implements "T foo(T)" where T can be "int", "short", "long int", or >> other types. C simply does not have type-generic functions. > > Sort of. C23 defines the term "generic function" (N3220 7.26.5.1, > string search functions). For example, strchr() can take a const void* > argument and return a const void* result, or it can take a void* > argument and return a void* result. (C++ does this by having two > overloaded strchr() functions.) > > These "generic functions" are (almost certainly) implemented as macros > that use _Generic. If you bypass the macro definition, you get the > function that can take a const char* and return a char*. > > So C doesn't have type-generic functions, but it does have feature that > let you implement things that act like type-generic functions. > Yes. It has also had type-generic maths functions for a good while. But it doesn't have a general generic function mechanism other than _Generic macros. >> You /can/ write generic macros that handle different _BitInt types, >> but that would quickly get painful given that you'd need a case for >> each size of _BitInt you wanted for the _Generic macro. > > Indeed. A _Generic selection that handles all the ordinary non-extended > integer types needs to handle 12 cases if I'm counting correctly, which > is feasible. But the addition of bit-precise types adds > BITINT_MAXWIDTH*2-1 new distinct predefined types, and a generic > selection would need one case for each. > > However, you could have a function that takes a void*, a size, and a > width as arguments and operates on a _BitInt(?) or unsigned _BitInt(?) > type. In fact, gcc has internal functions like that for multiplication > and division. (You mentioned something like that in text that I've > snipped.) > You could, yes. I started thinking about how you might make one that didn't require the user to manually include the bitcount of the _BitInt to use it, but I couldn't figure out a good way. You can get a start, from using sizeof on the _BitInt parameter, but I can't think of a way to get bitcount exactly (even using _Generic's). > [...] > >>> This assumes BitInts are passed and returned by value, but even >>> using BitInt* wouldn't help. >> >> Yes, they are passed around as values - they are integer types and are >> passed around like other integer types. (Implementations may use >> stack blocks and pointers for passing the values around if they are >> too big for registers, just as implementations can do with any value >> type. That's an implementation detail - logically, they are passed and >> returned as values.) > > Yes, and in general a _BitInt argument has to be copied to the > corresponding parameter, since a change to the parameter can't affect > the value of the argument. The workings of C parameter passing were unfortunately cut in stone before anyone thought of passing large types as parameters. In hindsight it's easy to see it could have been better to say that function parameters are implicitly "const" and attempting to modify them is UB - just make a local copy if you want to make a change. But it's too late now! > > But passing huge _BitInts by value is no more problematic than passing > huge structs by value. > Exactly, yes.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-29 19:36 +0000 |
| Message-ID | <10gfhv9$19h1h$1@paganini.bofh.team> |
| In reply to | #395417 |
David Brown <david.brown@hesbynett.no> wrote:
> On 24/11/2025 12:17, bart wrote:
>> On 24/11/2025 09:29, David Brown wrote:
>>> On 23/11/2025 16:06, Michael S wrote:
>>>> On Sun, 23 Nov 2025 13:59:59 +0000
>>>> bart <bc@freeuk.com> wrote:
>>
>>>>> So what is the result type of multiplying values of those two types?
>>>>>
>>>>
>>>> I think, traditional C rules for integer types apply here as well: type
>>>> of result is the same as type of wider operand. It is arithmetically
>>>> unsatisfactory, but consistent with the rest of language.
>>>
>>> There is one key difference between the _BitInt() types and other
>>> integer types - with _BitInt(), there are no automatic promotions to
>>> other integer types. Thus if you are using _BitInt() operands in an
>>> arithmetic expression, these are not promoted to "int" or "unsigned
>>> int" even if they are smaller (lower rank). If you mix _BitInt()'s of
>>> different sizes, then the smaller one is first converted to the larger
>>> type.
>>
>>>> I think, the Standard is written in such way that implementing _BitInt
>>>> as an arbitrary precision numbers, i.e. with number of bits held as part
>>>> of the data, is not allowed.
>>
>>> Correct. _BitInt(N) is a signed integer type with precisely N value
>>> bits. It can have padding bits if necessary (according to the target
>>> ABI), but it can't have any other information.
>>>
>>>> Of course, Language Support Library can be
>>>> (and hopefully is, at least for gcc; clang is messy a.t.m.) based on
>>>> arbitrary precision core routines, but the API used by compiler should
>>>> be similar to GMP's mpn_xxx family of functions rather than GMP's
>>>> mpz_xxx family, i.e. # of bits as separate parameters from data arrays
>>>> rather than combined.
>>>>
>>>
>>> Yes, exactly. At the call site, the size of the _BitInt type is
>>> always a known compile-time constant, so it can easily be passed on.
>>> Thus :
>>>
>>> _BitInt(N) x;
>>> _BitInt(M) y;
>>> _BitInt(NM) z = x * y;
>>
>> So what is NM here; is it N*M (the potential maximum size of the
>> result), or max(N, M)?
>
> No, it is whatever you want it to be. I didn't want to use the next
> letter after N because _BitInt(O) could easily be misunderstood. But of
> course NM could be misunderstood too. Perhaps N1, N2 and N3 would have
> been better choices than N, M and NM.
>
> You pick the size of "z" here according to your needs for your code.
> The multiplication will be done, logically, at max(N, M) bits. The
> result will then be converted to NM bits. Like always in C, the
> semantics of the calculation is entirely independent of the type of the
> variable you assign the results to. And like always in C, the compiler
> may take advantage of knowledge of the assigned type in order to give
> more efficient code, as long as it does not stray from giving the same
> value as if it took the code literally.
>
> So if you want the full range of values of x and y to be usable here,
> then NM would have to be N * M. But you would also need a cast, such as
> "_BitInt(NM) z = (_BitInt(NM)) x * y;", just as you do if you want to
> multiply two 32-bit ints as a 64-bit operation.
>
> Alternatively, you might know more about the values that might be in x
> and y, and have a smaller NM (though you still need a cast if it is
> greater than both N and M). Or you might be using unsigned types and
> want the wrapping / masking behaviour.
>
> The point was not what size NM is, but that it is known to the compiler
> at the time of writing the expression.
>
>>
>> It sounds like the max precision you get will be the latter.
>>
>>
>>> can be implemented as something like :
>>>
>>> __bit_int_signed_mult(NM, (unsigned char *) &z,
>>> N, (const unsigned char *) &x,
>>> M, (const unsigned char *) &y);
>>>
>>>
>>
>>
>> How would you write a generic user function that operates on any size
>> BitInt? For example:
>>
>> _BitInt(?) bi_square(_BitInt(?));
>>
>
> You can't. _BitInt(N) and _BitInt(M) are distinct types, for differing
> N and M. You can't write a generic user function in C that implements
> "T foo(T)" where T can be "int", "short", "long int", or other types. C
> simply does not have type-generic functions.
>
> You /can/ write generic macros that handle different _BitInt types, but
> that would quickly get painful given that you'd need a case for each
> size of _BitInt you wanted for the _Generic macro.
>
> If you want generics, you are better off with a language that supports
> generics, such as C++.
>
>> Even if you passed the size as a parameter, there would be a problem
>> with the BitInt type.
>
> Yes. But you could use a void* pointer for more generic parameters.
>
> However, _BitInt types are for "bit-precise integer types". They are
> for specific fixed sizes, not for arbitrary precision integers. They
> are not ideally suited for tasks for which they were not designed -
> that's hardly surprising.
>
>>
>> This assumes BitInts are passed and returned by value, but even using
>> BitInt* wouldn't help.
>
> Yes, they are passed around as values - they are integer types and are
> passed around like other integer types. (Implementations may use stack
> blocks and pointers for passing the values around if they are too big
> for registers, just as implementations can do with any value type.
> That's an implementation detail - logically, they are passed and
> returned as values.)
>
>>
>> This sets it apart from arrays, where you also define very large, fixed
>> size arrays, but can use a T(*)[] type to write generic functions, that
>> take an additional length parameter.
>
> _BitInt's are fixed-size integer types, not arrays. Again, it is not
> then surprising that they are different from arrays.
>
>>
>> This will be for a particular T, but for BitInt, T is also fixed; it
>> happens to be an implicit bit type.
>>
>
> _BitInt's are not arrays, they are scalars - they are integer types.
> There is no concept of a type "_BitInt" - they always have compile-time
> fixed sizes, such as "_BitInt(12)". So the idea of passing around
> generic _BitInt's makes no more sense than passing around any other kind
> of generic integer types. (Of course you can have an array of _BitInt's
> of any given size.)
There are languages which pass generic types, but C is not one
of them. So idea of passing around generic _BitInt's makes sense,
but this is not included in C.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-30 11:56 +0100 |
| Message-ID | <10gh7sj$8ooq$1@dont-email.me> |
| In reply to | #395573 |
On 29/11/2025 20:36, Waldek Hebisch wrote: > David Brown <david.brown@hesbynett.no> wrote: >> _BitInt's are not arrays, they are scalars - they are integer types. >> There is no concept of a type "_BitInt" - they always have compile-time >> fixed sizes, such as "_BitInt(12)". So the idea of passing around >> generic _BitInt's makes no more sense than passing around any other kind >> of generic integer types. (Of course you can have an array of _BitInt's >> of any given size.) > > There are languages which pass generic types, but C is not one > of them. So idea of passing around generic _BitInt's makes sense, > but this is not included in C. > By "pass around generic types", do you mean that you can write a function that handles different types in the same parameter spot, and have the function do different things for different passed-in types? C has at least three ways to handle such things : 1. Variadic functions and the <stdarg.h> macros. "printf" is a prime example of a function that can take parameters of many different types. 2. Passing arbitrary data via "void *" pointers. People do it all the time. 3. _Generic macros. These are not functions, but can pass off control to different type-specific functions depending on the type of the arguments. You can use any of these methods with _BitInts, but they are all missing something significant in comparison to the support you would (and I expect will) get in C++ with a template-based std::bit_int<N>, or in higher level languages like Python (if it had an equivalent of a set of _BitInt types). I therefore expect to be able to do more interesting things with _BitInt types in C++ than in C, and do so in much simpler ways than equivalents in C. My point was that to do "something with generic _BitInt's" you have to have to deal with a range of types, not one type with a range of sizes or bit-counts.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-30 15:50 +0000 |
| Message-ID | <10ghp3v$1ickn$1@paganini.bofh.team> |
| In reply to | #395603 |
David Brown <david.brown@hesbynett.no> wrote:
> On 29/11/2025 20:36, Waldek Hebisch wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>
>>> _BitInt's are not arrays, they are scalars - they are integer types.
>>> There is no concept of a type "_BitInt" - they always have compile-time
>>> fixed sizes, such as "_BitInt(12)". So the idea of passing around
>>> generic _BitInt's makes no more sense than passing around any other kind
>>> of generic integer types. (Of course you can have an array of _BitInt's
>>> of any given size.)
>>
>> There are languages which pass generic types, but C is not one
>> of them. So idea of passing around generic _BitInt's makes sense,
>> but this is not included in C.
>>
>
> By "pass around generic types", do you mean that you can write a
> function that handles different types in the same parameter spot, and
> have the function do different things for different passed-in types? C
> has at least three ways to handle such things :
>
> 1. Variadic functions and the <stdarg.h> macros. "printf" is a prime
> example of a function that can take parameters of many different types.
>
> 2. Passing arbitrary data via "void *" pointers. People do it all the time.
>
> 3. _Generic macros. These are not functions, but can pass off control
> to different type-specific functions depending on the type of the arguments.
>
>
> You can use any of these methods with _BitInts, but they are all missing
> something significant in comparison to the support you would (and I
> expect will) get in C++ with a template-based std::bit_int<N>, or in
> higher level languages like Python (if it had an equivalent of a set of
> _BitInt types).
>
> I therefore expect to be able to do more interesting things with _BitInt
> types in C++ than in C, and do so in much simpler ways than equivalents
> in C.
>
> My point was that to do "something with generic _BitInt's" you have to
> have to deal with a range of types, not one type with a range of sizes
> or bit-counts.
In case of _BitInt the relevant thing are parametrized types, especially
Extended Pascal schema types. Typically each tuple of parameters
creates a new type, distinct from types created using different
tuples. That may sound like C++ templates, but unlike templates
in Pascal types are logically created at runtime. That is there
is no need to specify all needed possibilities at compile time.
And unlike languages with reference semantics in Pascal such
types can be passed by value and parameters may affect size of
the type.
There are languages where parametrized types have more capabilities
than in Pascal, but Pascal is IMO good example as it is otherwise
reasonably comparable to C.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-24 05:06 -0800 |
| Message-ID | <87a50b4m1y.fsf@example.invalid> |
| In reply to | #395400 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Yes, exactly. At the call site, the size of the _BitInt type is
> always a known compile-time constant, so it can easily be passed on.
> Thus :
>
> _BitInt(N) x;
> _BitInt(M) y;
> _BitInt(NM) z = x * y;
>
> can be implemented as something like :
>
> __bit_int_signed_mult(NM, (unsigned char *) &z,
> N, (const unsigned char *) &x,
> M, (const unsigned char *) &y);
That looks like it's supposed to avoid overflow (I'm assuming NM is N + M), but
it wouldn't work. The type of a C expression is almost always determined
by the expression itself, regardless of the context in which it appears.
The type of x * y is _BitInt(max(N, M)), not _BitInt(N+M), so it can
overflow even if the full result would fit into z.
You can do this instead (not tested):
_BitInt(N) x;
_BitInt(M) y;
_Bit_Int(N+M) z = (_BitInt(N+M))x * y;
(I'm assuming N+M is sufficient, but I might have missed an off-by-one
error somewhere.)
--
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-24 15:27 +0200 |
| Message-ID | <20251124152736.00002d8d@yahoo.com> |
| In reply to | #395411 |
On Mon, 24 Nov 2025 05:06:33 -0800 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] > > Yes, exactly. At the call site, the size of the _BitInt type is > > always a known compile-time constant, so it can easily be passed on. > > Thus : > > > > _BitInt(N) x; > > _BitInt(M) y; > > _BitInt(NM) z = x * y; > > > > can be implemented as something like : > > > > __bit_int_signed_mult(NM, (unsigned char *) &z, > > N, (const unsigned char *) &x, > > M, (const unsigned char *) &y); > > That looks like it's supposed to avoid overflow (I'm assuming NM is N > + M), but it wouldn't work. The type of a C expression is almost > always determined by the expression itself, regardless of the context > in which it appears. The type of x * y is _BitInt(max(N, M)), not > _BitInt(N+M), so it can overflow even if the full result would fit > into z. > > You can do this instead (not tested): > > _BitInt(N) x; > _BitInt(M) y; > _Bit_Int(N+M) z = (_BitInt(N+M))x * y; > > (I'm assuming N+M is sufficient, but I might have missed an off-by-one > error somewhere.) > You missed nothing. N+M is both sufficient and necessary. The latter because of -(2**(N-1)) * -(2**(M-1)).
[toc] | [prev] | [next] | [standalone]
Page 1 of 13 [1] 2 3 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web