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 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-12-01 14:41 +0000 |
| Message-ID | <10gk9e7$1cggk$2@dont-email.me> |
| In reply to | #395623 |
On 01/12/2025 04:10, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> On 01/12/2025 00:08, Waldek Hebisch wrote:
>>> bart <bc@freeuk.com> wrote:
>>>>
>>>> Yet what I said is pretty much true. Nobody care about BitInt until they
>>>> became aware of, and now it's must-have.
>>>
>>> Well, you were told many times that regulars here know deficiencies
>>> of C. "Nobody care about BitInt" in the sense that before _BitInt
>>> people will say "this can not be expressed directly in C, you need
>>> such and such workaround". People did not loudly complain
>>> knowing that complaints would achive nothing. But say doing
>>> language comparisons they could note that C lack such a feature.
>>>
>>> There is also a psychological phenomenon: computers even in crude
>>> form are quite useful. So people were willing to jump hops to
>>> use them. But when better/easier approach is available people
>>> wery strongly resist going to old ways. So, once w got _BitInt
>>> you will not be able to take it back.
>>
>>
>> I've been claiming that _BitInt was a poor fit for a language at the
>> level of C which lacks some more fundamental features.
>>
>> But I think I was wrong: the way _BitInt has been devised and presented
>> is actually completely in line with the haphazard way C has evolved up
>> to now.
>>
>> I made the mistake in this thread of thinking that people cared about
>> measured language design; obviously if they're using C, they don't.
>>
>> unsigned char* p;
>> uint8_t* q; // only exists when stdint.h used
>> unsigned _BitInt(8)* r;
>> char* s;
>>
>> p and q are probably compatible. p and r are not; q and r and not. s is
>> incompatible with p, q, r even if it is unsigned.
>
> Do you understand that uint8_t and _BitInt(8) are different types?
Well, apparently they aren't. It's not immediately obvious why, but as I
explained above, I realise this is entirely in keeping with how C works.
> And the difference is not an accident, but they have different
> properties (uint8_t in expressions promotes to int, _BitInt(8)
> is not subject to this promotion).
This is another little rule that is not obvious, and out of keeping with
how other types work. Yet add _BitInt(8) to _BitInt(16), and one side
/is/ promoted.
My example was just to highlight the plethora of type denotations that
exist, even for the same machine type. The rules for type-compatibility
and promotions (and the ugly syntax) is just icing on top.
This ungainly way to evolve a language is how C works (just look at all
the things wrong with how stdint.h types were handled).
The following table for example shows the rules for mixed sign
arithmetic: S means the result (32 or 64 bits) has signed type, and u
means it is unsigned:
u8 u16 u32 u64 i8 i16 i32 i64
u8 S S u u S S S S
u16 S S u u S S S S
u32 u u u u u u u S
u64 u u u u u u u u
i8 S S u u S S S S
i16 S S u u S S S S
i32 S S u u S S S S
i64 S S S u S S S S
But of course, every C programmer knows this and doesn't need such a chart!
Here, i8 + u8 gives a signed result; but 'unsigned _BitInt(8 ) +
_Bitint(8)' apparently gives an unsigned result (tested using _Generic).
So another plus point for staying close to the C spirit!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-12-01 16:24 +0100 |
| Message-ID | <10gkbuo$1dvtp$1@dont-email.me> |
| In reply to | #395633 |
On 01/12/2025 15:41, bart wrote: > On 01/12/2025 04:10, Waldek Hebisch wrote: >> bart <bc@freeuk.com> wrote: >>> On 01/12/2025 00:08, Waldek Hebisch wrote: >>>> bart <bc@freeuk.com> wrote: >>>>> >>>>> Yet what I said is pretty much true. Nobody care about BitInt until >>>>> they >>>>> became aware of, and now it's must-have. >>>> >>>> Well, you were told many times that regulars here know deficiencies >>>> of C. "Nobody care about BitInt" in the sense that before _BitInt >>>> people will say "this can not be expressed directly in C, you need >>>> such and such workaround". People did not loudly complain >>>> knowing that complaints would achive nothing. But say doing >>>> language comparisons they could note that C lack such a feature. >>>> >>>> There is also a psychological phenomenon: computers even in crude >>>> form are quite useful. So people were willing to jump hops to >>>> use them. But when better/easier approach is available people >>>> wery strongly resist going to old ways. So, once w got _BitInt >>>> you will not be able to take it back. >>> >>> >>> I've been claiming that _BitInt was a poor fit for a language at the >>> level of C which lacks some more fundamental features. >>> >>> But I think I was wrong: the way _BitInt has been devised and presented >>> is actually completely in line with the haphazard way C has evolved up >>> to now. >>> >>> I made the mistake in this thread of thinking that people cared about >>> measured language design; obviously if they're using C, they don't. >>> >>> unsigned char* p; >>> uint8_t* q; // only exists when stdint.h used >>> unsigned _BitInt(8)* r; >>> char* s; >>> >>> p and q are probably compatible. p and r are not; q and r and not. s is >>> incompatible with p, q, r even if it is unsigned. >> >> Do you understand that uint8_t and _BitInt(8) are different types? > > Well, apparently they aren't. It's not immediately obvious why, but as I > explained above, I realise this is entirely in keeping with how C works. > C - like many languages - has a variety of types for different purposes, and with different combinations of characteristics. Some separate types share one or more of these characteristics. Characteristics of types include whether they hold integers, floating point values, or pointers, whether they are signed or unsigned, what implicit conversions take place and in what circumstances, what size their bit representation is, what range they cover, what operations can be applied, and so on. Just because two types happen to share the same size in bytes does not in any way imply they are, or should be, the same type. Even if they have many characteristics in common, they can still be different types. And even when they are /actually/ the same type - such as when one is a typedef of another - it is not difficult to keep them separate in code and use the appropriate type for appropriate use. "size_t" will typically be a typedef for "unsigned long long int", "unsigned long int", or "unsigned int" - but you don't mix it with those types. If you had been paying attention in this thread, you /would/ find it immediately obvious why "uint8_t" and "_BitInt(8)" /must/ be different types. And if you had a basic understanding of the way the language works (rather than just a superficial idea of how some of it can be used), you'd understand that these would be different types even if they followed the same integer promotion rules. >> And the difference is not an accident, but they have different >> properties (uint8_t in expressions promotes to int, _BitInt(8) >> is not subject to this promotion). > > This is another little rule that is not obvious, and out of keeping with > how other types work. Yet add _BitInt(8) to _BitInt(16), and one side > /is/ promoted. > No, _BitInt's never use integer promotion. Perhaps you mean that they are included in the rules for "usual arithmetic conversions" ? These are different from the "integer promotion" rules. One would think that someone who claims to have implemented a C compiler would be familiar with the types of implicit conversions required by the language. > My example was just to highlight the plethora of type denotations that > exist, even for the same machine type. The rules for type-compatibility > and promotions (and the ugly syntax) is just icing on top. > C is not an abstraction for a processor. It is a programming language. It does not differentiate between types nearly as much as I would like, but it still does so more than an untyped language like assembly. > This ungainly way to evolve a language is how C works (just look at all > the things wrong with how stdint.h types were handled). > > The following table for example shows the rules for mixed sign > arithmetic: S means the result (32 or 64 bits) has signed type, and u > means it is unsigned: > > u8 u16 u32 u64 i8 i16 i32 i64 > > u8 S S u u S S S S > u16 S S u u S S S S > u32 u u u u u u u S > u64 u u u u u u u u > > i8 S S u u S S S S > i16 S S u u S S S S > i32 S S u u S S S S > i64 S S S u S S S S > > But of course, every C programmer knows this and doesn't need such a chart! C programmers know that C does not have types of these names. And I expect most C programmers figure things out using the very simple and consistent rules of the language. Whenever an "int" could be used, if a value of standard integer type is smaller than "int" it gets promoted to "int". Then for any operation that needs two operands of the same type, the smaller type gets converted to the bigger type - and if you mix unsigned and signed, they get converted to unsigned. You might not think that these are the best rules to choose for a language (I certainly don't - they were picked for backwards compatibility more than anything else), but they really are not difficult to understand or learn. No one needs a chart. > > Here, i8 + u8 gives a signed result; but 'unsigned _BitInt(8 ) + > _Bitint(8)' apparently gives an unsigned result (tested using _Generic). > Or you could learn the very simple rules, and then you would know without testing. > So another plus point for staying close to the C spirit! > Yes, _BitInt's try to follow as simple rules as practical, fitting with existing C but providing new and useful features. /That/ is the C spirit.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-12-01 17:19 +0000 |
| Message-ID | <10gkin9$1he3f$1@dont-email.me> |
| In reply to | #395634 |
On 01/12/2025 15:24, David Brown wrote: > On 01/12/2025 15:41, bart wrote: > No, _BitInt's never use integer promotion. Perhaps you mean that they > are included in the rules for "usual arithmetic conversions" ? These > are different from the "integer promotion" rules. One would think that > someone who claims to have implemented a C compiler would be familiar > with the types of implicit conversions required by the language. I implement C via an IL. The IL doesn't use any automatic promotions. There is only one instruction WIDEN to zero- or sign-extend any value. So I think in those terms. >> My example was just to highlight the plethora of type denotations that >> exist, even for the same machine type. The rules for type- >> compatibility and promotions (and the ugly syntax) is just icing on top. >> > > C is not an abstraction for a processor. It is a programming language. > It does not differentiate between types nearly as much as I would like, It seems to be doing a good job! > but it still does so more than an untyped language like assembly. There is type-specific stuff going on, but it's done via the choices of instruction. My IL supports the usual set of 8/16/32/64-bit-based types, and type-info is a separate attribute for each instruction. There is no direct provision for sub-byte/sub-word types, and the only type bigger than a word (putting aside a reserved set of vector types), is an anonymous data-block type, specified as so many bytes in size. So you can see how an arbitrary [unsigned] _BitInt(N) bit-precise type would be a poor fit, and a bit of a nightmare to implement on top. It's unnatural. The IL is designed to be one abstraction level higher than typical machine architectures, and you don't really want HLL-specific features in it. This is related to my remark about LLVM and its building-in of such types. But LLVM is some 3-4 magnitudes bigger in scale than what I do, and famously slow and cumbersome in operation. >> This ungainly way to evolve a language is how C works (just look at >> all the things wrong with how stdint.h types were handled). >> >> The following table for example shows the rules for mixed sign >> arithmetic: S means the result (32 or 64 bits) has signed type, and u >> means it is unsigned: >> >> u8 u16 u32 u64 i8 i16 i32 i64 > C programmers know that C does not have types of these names. Unforunately, if I'd used 'unsigned long long int' and so on, the chart becomes impossibly large. While with 'uint64_t' etc, such types don't exist at all in C, unless a particular header is used (and they might still result in line-wrapping). Fortunately I'm 100% certain that no one reading this is scratching their heads about what those types could possible mean. > And I > expect most C programmers figure things out using the very simple and > consistent rules of the language. The chart demonstratates a number of inconsistencies. >> Here, i8 + u8 gives a signed result; but 'unsigned _BitInt(8 ) + >> _Bitint(8)' apparently gives an unsigned result (tested using _Generic). >> > > Or you could learn the very simple rules, and then you would know > without testing. So you're not commenting on the fact that mixed 8-bit arithmetic has opposite signedness between existing types and _BitInt types. (My language also has rules, but the equivalent chart is simpler: every entry has 'S' except for u64/u64 (and I'm working on that!). While with my decimal big-number library, all numbers are signed so the issue doesn't come up at all.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-12-01 19:33 +0100 |
| Message-ID | <10gkn0v$1io6u$1@dont-email.me> |
| In reply to | #395637 |
On 01/12/2025 18:19, bart wrote: > On 01/12/2025 15:24, David Brown wrote: >> On 01/12/2025 15:41, bart wrote: > >> No, _BitInt's never use integer promotion. Perhaps you mean that they >> are included in the rules for "usual arithmetic conversions" ? These >> are different from the "integer promotion" rules. One would think >> that someone who claims to have implemented a C compiler would be >> familiar with the types of implicit conversions required by the language. > > I implement C via an IL. The IL doesn't use any automatic promotions. > There is only one instruction WIDEN to zero- or sign-extend any value. > > So I think in those terms. > It doesn't matter how you think. What matters if you are making something you can reasonably call a "C compiler", is that you implement C as it is defined. It's fair enough not to be entirely compliant to the standards, but you need to get the basics right. If you are implementing only a partial sort-of-C compiler, with a view to acting as a limited tool for a specific close subset of C, then it's fine to change or skip rules. Perhaps your tool is never called upon to do arithmetic on types that are not of size "int" or above, or perhaps you actively decide to have different rules. That's okay - but it would be misleading to call it a "C compiler". > >>> My example was just to highlight the plethora of type denotations >>> that exist, even for the same machine type. The rules for type- >>> compatibility and promotions (and the ugly syntax) is just icing on top. >>> >> >> C is not an abstraction for a processor. It is a programming >> language. It does not differentiate between types nearly as much as I >> would like, > > It seems to be doing a good job! Yes, C is a very successful and useful programming language. Just because /I/ would prefer a language that made greater distinction between types, does not mean C would be better at its job if it did so. Strong typing is not for everyone. > >> but it still does so more than an untyped language like assembly. > > There is type-specific stuff going on, but it's done via the choices of > instruction. We are talking about C, here in a C newsgroup. > > My IL supports the usual set of 8/16/32/64-bit-based types, and type- > info is a separate attribute for each instruction. > > There is no direct provision for sub-byte/sub-word types, and the only > type bigger than a word (putting aside a reserved set of vector types), > is an anonymous data-block type, specified as so many bytes in size. > > So you can see how an arbitrary [unsigned] _BitInt(N) bit-precise type > would be a poor fit, and a bit of a nightmare to implement on top. It's > unnatural. > The thing you have to remember about implementations, is that nobody really cares how hard it is to implement a particular C feature. The C standards folk care that it is /possible/ to implement it, not if it happens to be easy or difficult for any particular compiler (especially an obscure private sort-of-C compiler that is only used by one person). They do provide some escape hatches for implementers who feel a particular feature is too difficult to make for the amount of use it would get from their users - a number of C features are optional, and for _BitInt, you can limit the size to just 64 bits. > The IL is designed to be one abstraction level higher than typical > machine architectures, and you don't really want HLL-specific features > in it. > > This is related to my remark about LLVM and its building-in of such > types. But LLVM is some 3-4 magnitudes bigger in scale than what I do, > and famously slow and cumbersome in operation. > The _BitInt feature is not designed arount LLVM. You are mistaken in believing so. It took inspiration from clang's _ExtInt feature and how it could be used, not how it was implemented. >>> This ungainly way to evolve a language is how C works (just look at >>> all the things wrong with how stdint.h types were handled). >>> >>> The following table for example shows the rules for mixed sign >>> arithmetic: S means the result (32 or 64 bits) has signed type, and u >>> means it is unsigned: >>> >>> u8 u16 u32 u64 i8 i16 i32 i64 > >> C programmers know that C does not have types of these names. > > Unforunately, if I'd used 'unsigned long long int' and so on, the chart > becomes impossibly large. The chart was pointless in the first place. But if you want to have types like that in C, they are called "uint8_t", etc. You know this. You only use these silly abbreviations for provocation, so that you can yet again blather on about how some other irrelevant language uses them and somehow feel smug about it all. > > While with 'uint64_t' etc, such types don't exist at all in C, unless a > particular header is used (and they might still result in line-wrapping). They exist in the C standard regardless of any headers, because the C standard - the definition of the C language - is independent of any program. > > Fortunately I'm 100% certain that no one reading this is scratching > their heads about what those types could possible mean. > >> And I expect most C programmers figure things out using the very >> simple and consistent rules of the language. > > The chart demonstratates a number of inconsistencies. > No, it does not - at least, not inconsistencies in C. It may demonstrate inconsistencies in your understanding and misunderstanding of the language. >>> Here, i8 + u8 gives a signed result; but 'unsigned _BitInt(8 ) + >>> _Bitint(8)' apparently gives an unsigned result (tested using _Generic). >>> >> >> Or you could learn the very simple rules, and then you would know >> without testing. > > So you're not commenting on the fact that mixed 8-bit arithmetic has > opposite signedness between existing types and _BitInt types. > No. As I said, the rules are clear and simple. Anyone so incapable of learning that they have trouble with them, is likely to have a great deal of difficulty doing much programming. (And again, I point out that I do not think the C rules here are the best options for a programming language. But that is my personal opinion, and it does not affect my ability to understand the rules and write correct C code using them.) > (My language also has rules, but the equivalent chart is simpler: every > entry has 'S' except for u64/u64 (and I'm working on that!). > That would be an alternative set of rules that would also be easy to learn. And it would be, IMHO, at least as bad as C's choices. There is no set of rules that can handle mixed signed arithmetic well and implicitly without expanding type sizes. Your language is different from C's, not better. > While with my decimal big-number library, all numbers are signed so the > issue doesn't come up at all.) >
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-12-01 20:14 +0000 |
| Message-ID | <10gksv6$1lpve$1@dont-email.me> |
| In reply to | #395638 |
On 01/12/2025 18:33, David Brown wrote:
> On 01/12/2025 18:19, bart wrote:
> If you are implementing only a partial sort-of-C compiler, with a view
> to acting as a limited tool for a specific close subset of C, then it's
> fine to change or skip rules. Perhaps your tool is never called upon to
> do arithmetic on types that are not of size "int" or above, or perhaps
> you actively decide to have different rules. That's okay - but it would
> be misleading to call it a "C compiler".
I call it a C-subset compiler, for a standard somewhere between C90 and
C99. It's a C subset that my transpiler projects used to generate.
It seems to cover enough of the language to compile projects like
sqlite3, Lua, Tcc, Clox, stb_image, LibJPEG, and for any programs /I/
might write.
>>
>>> but it still does so more than an untyped language like assembly.
>>
>> There is type-specific stuff going on, but it's done via the choices
>> of instruction.
>
> We are talking about C, here in a C newsgroup.
Sure; that's why you mentioned assembly.
> The thing you have to remember about implementations, is that nobody
> really cares how hard it is to implement a particular C feature. The C
> standards folk care that it is /possible/ to implement it, not if it
> happens to be easy or difficult for any particular compiler (especially
> an obscure private sort-of-C compiler that is only used by one person).
> They do provide some escape hatches for implementers who feel a
> particular feature is too difficult to make for the amount of use it
> would get from their users - a number of C features are optional, and
> for _BitInt, you can limit the size to just 64 bits.
So they do care.
>> This is related to my remark about LLVM and its building-in of such
>> types. But LLVM is some 3-4 magnitudes bigger in scale than what I do,
>> and famously slow and cumbersome in operation.
>>
>
> The _BitInt feature is not designed arount LLVM. You are mistaken in
> believing so. It took inspiration from clang's _ExtInt feature and how
> it could be used, not how it was implemented.
See this article about ExtInt:
https://blog.llvm.org/2020/04/the-new-clang-extint-feature-provides.html
These are quotes:
"I finally committed a patch to implement the extended-integer type
class, _ExtInt after nearly two and a half years of design and
implementation."
"provides a language interface for LLVM's extremely powerful integer
type class."
(From the N2472 link in the article:)
"The LLVM compiler provides support for iN types in the intermediate
representation, so it is straightforward to implement in this compiler"
So the existence of LLVM's bigint types appear to be a significant
factor which led to ExtInt and then to BitInt.
(But it's not clear what that 2 1/2 years was spent doing, unless it is
what they mean by 'straightforward'.)
> But if you want to have types like that in C, they are called "uint8_t",
> etc. You know this. You only use these silly abbreviations for
> provocation,
No, because everyone knows what they mean, across languages too.
so that you can yet again blather on about how some other
> irrelevant language uses them and somehow feel smug about it all.
You're damn right about feeling smug about being able to write:
proc F(u64 a, b, c, d)
where I can instantly see that this takes 4 parameters that share the
same type, and not:
void F(uint64_t a, uint64_t b, uint64_t c, uint64_t d)
or worse (presumably what people had to before C99):
void F(unsigned long long int a, unsigned long long int b, unsigned
long long int c, unsigned long long int d)
> They exist in the C standard regardless of any headers, because the C
> standard - the definition of the C language - is independent of any
> program.
Sure, that's why I can write code like this, without stdint.h:
int32_t abc; // "error: unknown type name 'int32_t'"
Or with stdint.h:
int int32_t; // within a block scope
int64_t int64_t;
typedef uint8_t int16_t;
So it IS dependent on a particular program. At least I have to hand it
to C to be able to write such nonsense.
>>
>> Fortunately I'm 100% certain that no one reading this is scratching
>> their heads about what those types could possible mean.
>>
>>> And I expect most C programmers figure things out using the very
>>> simple and consistent rules of the language.
>>
>> The chart demonstratates a number of inconsistencies.
>>
>
> No, it does not - at least, not inconsistencies in C. It may
> demonstrate inconsistencies in your understanding and misunderstanding
> of the language.
The inconsistencies are to do with the irregular pattern of those S and
u letters.
> No. As I said, the rules are clear and simple. Anyone so incapable of
> learning that they have trouble with them, is likely to have a great
> deal of difficulty doing much programming.
There are two approaches to creating a product like an application, or a
programming language (or lots of things actually). This is the bad way:
* Not caring about how complicated, badly designed and inconsistent it
is, and telling people to RTFM if they complain, or simply being
insulting about the abilities
Remember that people have their own work to do and your product is just
a tool.
> (And again, I point out that I do not think the C rules here are the
> best options for a programming language. But that is my personal
> opinion, and it does not affect my ability to understand the rules and
> write correct C code using them.)
Maybe you should have been more vocal about it. /You're/ the one who's
using it every day. I'm more of an observer.
>> (My language also has rules, but the equivalent chart is simpler:
>> every entry has 'S' except for u64/u64 (and I'm working on that!).
>>
>
> That would be an alternative set of rules that would also be easy to
> learn. And it would be, IMHO, at least as bad as C's choices. There is
> no set of rules that can handle mixed signed arithmetic well and
> implicitly without expanding type sizes. Your language is different
> from C's, not better.
I make the i64 type dominant. i64 can completely represent the values of
all other smaller integer types, signed and unsigned, except for u64.
Some i64/u64 combinations are disallowed (because they can give
unintuitive results).
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-12-02 01:04 +0000 |
| Message-ID | <10gldu9$23jf3$1@paganini.bofh.team> |
| In reply to | #395634 |
David Brown <david.brown@hesbynett.no> wrote:
> On 01/12/2025 15:41, bart wrote:
>> On 01/12/2025 04:10, Waldek Hebisch wrote:
>
> C - like many languages - has a variety of types for different purposes,
> and with different combinations of characteristics. Some separate types
> share one or more of these characteristics. Characteristics of types
> include whether they hold integers, floating point values, or pointers,
> whether they are signed or unsigned, what implicit conversions take
> place and in what circumstances, what size their bit representation is,
> what range they cover, what operations can be applied, and so on.
>
> Just because two types happen to share the same size in bytes does not
> in any way imply they are, or should be, the same type. Even if they
> have many characteristics in common, they can still be different types.
>
> And even when they are /actually/ the same type - such as when one is a
> typedef of another - it is not difficult to keep them separate in code
> and use the appropriate type for appropriate use. "size_t" will
> typically be a typedef for "unsigned long long int", "unsigned long
> int", or "unsigned int" - but you don't mix it with those types.
>
> If you had been paying attention in this thread, you /would/ find it
> immediately obvious why "uint8_t" and "_BitInt(8)" /must/ be different
> types. And if you had a basic understanding of the way the language
> works (rather than just a superficial idea of how some of it can be
> used), you'd understand that these would be different types even if they
> followed the same integer promotion rules.
I see nothing in the standard that prevents '_BitInt(64)' and 'long'
to be the same type. And AFICS promotion rules are the only thing
which prevents 'uint8_t' and '_BitInt(8)' to be the same type.
Maybe I missed something, but I have read posts that appeared here
and I saw nothing indicating otherwise.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-01 18:21 -0800 |
| Message-ID | <87sedt39pv.fsf@example.invalid> |
| In reply to | #395647 |
antispam@fricas.org (Waldek Hebisch) writes:
[...]
> I see nothing in the standard that prevents '_BitInt(64)' and 'long'
> to be the same type. And AFICS promotion rules are the only thing
> which prevents 'uint8_t' and '_BitInt(8)' to be the same type.
> Maybe I missed something, but I have read posts that appeared here
> and I saw nothing indicating otherwise.
My initial reaction is that *obviously* _BitInt(64) and long are
distinct types. But what's obvious isn't always true.
Nevertheless ...
Looking through N3220 6.2.5 (Types), it specifies several groups of
types: standard signed integer types, bit-precise signed integer
type, extended signed integer types, and their corresponding
unsigned types. It's "obvious" that these sets are meant to be
disjoint, but it doesn't actually say so.
But section 6.3.1.1 defines the concept of *integer conversion rank*.
In particular :
The rank of any standard integer type shall be greater than
the rank of any extended integer type with the same width or
bit-precise integer type with the same width.
So even if long has a width of 64 bits and exactly the same
representation as _BitInt(64), it has a greater integer conversion
rank, so it can't be the same type.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-01 12:34 -0800 |
| Message-ID | <87tsya7xhe.fsf@example.invalid> |
| In reply to | #395633 |
bart <bc@freeuk.com> writes:
> On 01/12/2025 04:10, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>>> On 01/12/2025 00:08, Waldek Hebisch wrote:
>>>> bart <bc@freeuk.com> wrote:
>>>>>
>>>>> Yet what I said is pretty much true. Nobody care about BitInt until they
>>>>> became aware of, and now it's must-have.
They're a must-have if you want a conforming C23 implementation.
I don't recall anyone saying they're a "must-have" for any other
reason. But if you assert that everyone else things _BitInt types
were an absolutely necessary feature to add to the language, it
gives you something to argue against.
>>>> Well, you were told many times that regulars here know deficiencies
>>>> of C. "Nobody care about BitInt" in the sense that before _BitInt
>>>> people will say "this can not be expressed directly in C, you need
>>>> such and such workaround". People did not loudly complain
>>>> knowing that complaints would achive nothing. But say doing
>>>> language comparisons they could note that C lack such a feature.
>>>>
>>>> There is also a psychological phenomenon: computers even in crude
>>>> form are quite useful. So people were willing to jump hops to
>>>> use them. But when better/easier approach is available people
>>>> wery strongly resist going to old ways. So, once w got _BitInt
>>>> you will not be able to take it back.
>>>
>>> I've been claiming that _BitInt was a poor fit for a language at the
>>> level of C which lacks some more fundamental features.
>>>
>>> But I think I was wrong: the way _BitInt has been devised and presented
>>> is actually completely in line with the haphazard way C has evolved up
>>> to now.
>>>
>>> I made the mistake in this thread of thinking that people cared about
>>> measured language design; obviously if they're using C, they don't.
Here you make the mistake of assuming that everyone who disagrees
with you doesn't care about language design. You fail to consider
the possibility that someone can (a) care about language design *and*
(b) be willing to accept the design of C as it is, even with its flaws.
>>> unsigned char* p;
>>> uint8_t* q; // only exists when stdint.h used
>>> unsigned _BitInt(8)* r;
>>> char* s;
>>>
>>> p and q are probably compatible. p and r are not; q and r and not. s is
>>> incompatible with p, q, r even if it is unsigned.
I've asked you before why it matters to you that some of these types are
incompatible.
>> Do you understand that uint8_t and _BitInt(8) are different types?
>
> Well, apparently they aren't. It's not immediately obvious why, but as
> I explained above, I realise this is entirely in keeping with how C
> works.
>
>> And the difference is not an accident, but they have different
>> properties (uint8_t in expressions promotes to int, _BitInt(8)
>> is not subject to this promotion).
>
> This is another little rule that is not obvious, and out of keeping
> with how other types work. Yet add _BitInt(8) to _BitInt(16), and one
> side /is/ promoted.
And this is all specified in the standard. The *integer promotions*
convert a value of any narrow integer type other than a bit-precise type
to int or unsigned int; they do not apply to bit-precise types. The
*usual arithmetic conversions* resolve the left and right operands of an
operator to the same type.
The fact that bit-precise integer types are not subject to the integer
promotions *is* obvious. It's clearly stated in the C23 standard.
> My example was just to highlight the plethora of type denotations that
> exist, even for the same machine type. The rules for
> type-compatibility and promotions (and the ugly syntax) is just icing
> on top.
>
> This ungainly way to evolve a language is how C works (just look at
> all the things wrong with how stdint.h types were handled).
>
> The following table for example shows the rules for mixed sign
> arithmetic: S means the result (32 or 64 bits) has signed type, and u
> means it is unsigned:
>
> u8 u16 u32 u64 i8 i16 i32 i64
>
> u8 S S u u S S S S
> u16 S S u u S S S S
> u32 u u u u u u u S
> u64 u u u u u u u u
>
> i8 S S u u S S S S
> i16 S S u u S S S S
> i32 S S u u S S S S
> i64 S S S u S S S S
>
> But of course, every C programmer knows this and doesn't need such a chart!
I'm not going to take the time to confirm that your chart is correct.
It assumes that int is 32 bits; an implementation with 16-bit or
64-bit int would require a different chart.
But the fact that you were able to generate the chart means that
*you already understand the rules*. You just choose to express
those rules in a way that's more confusing.
> Here, i8 + u8 gives a signed result; but 'unsigned _BitInt(8 ) +
> _Bitint(8)' apparently gives an unsigned result (tested using
> _Generic).
Yes. That follows from the language rules, and in particular the
fact that the new bit-precise types are not subject to the integer
promotions. But citing a special case of those rules and taking
it out of context just makes the rules seem more confusing --
deliberately, I presume.
Am I happy about the C conversion rules? Not entirely.
The ANSI C committee had to choose between value-preserving and
unsigned-preserving semantics (both choices had been made by existing
compilers). I tend to think that unsigned-preserving rules would
have been better. And the fact that types narrower than int are
promoted before they can be operated on also strikes me as a bit
iffy; I think that, for example, having operations on two short
int operands yield a short int result would have been cleaner.
But I'm far more interested in understanding and explaining the
existing rules than in complaining about them. And the rules can't
be changed without breaking existing code.
> So another plus point for staying close to the C spirit!
--
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-12-01 22:01 +0000 |
| Message-ID | <10gl38c$1o9hb$1@dont-email.me> |
| In reply to | #395642 |
On 01/12/2025 20:34, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
>> The following table for example shows the rules for mixed sign
>> arithmetic: S means the result (32 or 64 bits) has signed type, and u
>> means it is unsigned:
>>
>> u8 u16 u32 u64 i8 i16 i32 i64
>>
>> u8 S S u u S S S S
>> u16 S S u u S S S S
>> u32 u u u u u u u S
>> u64 u u u u u u u u
>>
>> i8 S S u u S S S S
>> i16 S S u u S S S S
>> i32 S S u u S S S S
>> i64 S S S u S S S S
>>
>> But of course, every C programmer knows this and doesn't need such a chart!
>
> I'm not going to take the time to confirm that your chart is correct.
> It assumes that int is 32 bits; an implementation with 16-bit or
> 64-bit int would require a different chart.
>
> But the fact that you were able to generate the chart means that
> *you already understand the rules*. You just choose to express
> those rules in a way that's more confusing.
That doesn't follow; the chart was created by a C program (by submitting
64 combinations of typed variables (eg. issigned(x * y)) to the macro
below, compiled with gcc.
My own C compiler produces a quite different chart, but I'm not
interested at this point in rewriting the front-end, considering the
many other ways it doesn't conform.
Fortunately this doesn't seem to affect too many things.
As example, the above says that i8 * u32 (or u32 * i8) is unsigned; my
chart says it's signed. The difference can be demonstrated here:
signed char a = -2;
unsigned int b = 13;
printf("%f\n", (double)(a*b));
The output is:
gcc 4294967270.000000
bcc -26.000000
I don't know about you, but to me, my result looks a lot more intuitive!
So I also didn't /want/ to change it to something I didn't agree with.
-------------------------------------------------
#define issigned(x) _Generic((x),\
int8_t: "S",\
int16_t: "S",\
int32_t: "S",\
int64_t: "S",\
uint8_t: "u",\
uint16_t: "u",\
uint32_t: "u",\
uint64_t: "u",\
default: "other")
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-01 15:01 -0800 |
| Message-ID | <87wm353ixs.fsf@example.invalid> |
| In reply to | #395644 |
bart <bc@freeuk.com> writes:
> On 01/12/2025 20:34, Keith Thompson wrote:
[...]
>> I'm not going to take the time to confirm that your chart is
>> correct.
>>
>> It assumes that int is 32 bits; an implementation with 16-bit or
>> 64-bit int would require a different chart.
>>
>> But the fact that you were able to generate the chart means that
>> *you already understand the rules*. You just choose to express
>> those rules in a way that's more confusing.
>
> That doesn't follow; the chart was created by a C program (by
> submitting 64 combinations of typed variables (eg. issigned(x * y)) to
> the macro below, compiled with gcc.
OK, apparently I overestimated your knowledge of C's rules (unless you
could have reproduced the chart manually).
> My own C compiler produces a quite different chart, but I'm not
> interested at this point in rewriting the front-end, considering the
> many other ways it doesn't conform.
>
> Fortunately this doesn't seem to affect too many things.
>
> As example, the above says that i8 * u32 (or u32 * i8) is unsigned; my
> chart says it's signed. The difference can be demonstrated here:
>
> signed char a = -2;
> unsigned int b = 13;
>
> printf("%f\n", (double)(a*b));
>
> The output is:
>
> gcc 4294967270.000000
> bcc -26.000000
>
> I don't know about you, but to me, my result looks a lot more
> intuitive! So I also didn't /want/ to change it to something I didn't
> agree with.
Sure, if I didn't know C's rules, your result might seem more
intuitive.
Nevertheless, it's wrong. C's rules for the integer promotions and
the usual arithmetic conversions are clear and unambiguous. If I
want to multiply a by b using conversions other than the default
ones, I can easily do so with casts: `(int)a * (int)b` for example.
Or I can make a and b have more appropriate types in the first place.
To be blunt, *I don't care* about the behavior of your personal
non-conforming C compiler. You're absolutely free to make it behave
in any way you like, and to have it conform to the C standard or not.
But in this newsgroup, I prefer to discuss the actual C language (and
occasionally possible improvements that won't break existing code).
> -------------------------------------------------
>
> #define issigned(x) _Generic((x),\
> int8_t: "S",\
> int16_t: "S",\
> int32_t: "S",\
> int64_t: "S",\
> uint8_t: "u",\
> uint16_t: "u",\
> uint32_t: "u",\
> uint64_t: "u",\
> default: "other")
That will yield "other" for plain char, and for some other predefined
types. For example, on my 64-bit system I get "unknown" for long
long and unsigned long long; with "gcc -m32", I get "unknown"
for long and unsigned long.
If you want to cover all the predefined integer types this way,
I suggest using char, signed char, unsigned char, et al, up to
[unsigned] long long.
Please note clearly that I am describing how the language is defined,
not defending or advocating anything other than knowing how to use
it effectively. We already know how much you hate C's type system.
--
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-12-01 11:33 +0100 |
| Message-ID | <10gjqts$17nkj$1@dont-email.me> |
| In reply to | #395617 |
On 30/11/2025 18:55, bart wrote:
> On 30/11/2025 17:17, Janis Papanagnou wrote:
>> On 2025-11-30 13:51:22, bart wrote:
<snip>
>
> I've said many times that it's a poorly designed feature.
You have said continuously that you think everything about C, along with
everything you believe to be related to C (however tenuous the
connection may be in reality) is poorly designed. It seems that
absolutely everything that you did not design personally, is poorly
designed in your eyes. I'm not even sure you think your own languages
are well designed, given the number of times you've found new features
or limitations that you didn't know they had.
Perhaps you just have a different scale of what is "poor design" and
"good design". Or maybe you don't understand that things don't have to
be perfect to be good enough in practice. You certainly don't seem to
understand that when there is more than one person involved - and for C,
there are millions involved - compromises are inevitable, and elegance
of design must bow to compatibility requirements.
> Read the
> thread, as I'm not going to repeat things.
>
Is that a promise?
>
>>> Yet over the past decades nobody has been screaming because they
>>> couldn't have a 31-bit or 65-bit numeric type. But now suddenly
>>> EVERYONE wants to be able to do that, and on huge numbers!
For the most part, programmers use the tools they have, and switch to
more suitable tools as they become available. Programmers that are not
toddlers are usually aware that screaming about things does not help.
A relatively small proportion of those who work with C have any
influence over features. Many /could/ have influence if they choose to
- anyone can take part in standards discussions, make new proposals, get
involved in compiler development, and so on. Most just get on with
their tasks of programming in the languages others have created and
implemented.
When a new feature is added to the language, it is natural to consider
it and discuss what uses people could have for it. That's what we have
been trying to do here. For most programmers, the reasons behind the
feature are only of minor interest - _BitInt exists in the latest C
standard, and is to some extent supported in existing compilers. The
question for C users is not whether it should have been different - it's
too late for that (anyone could have followed and got involved in the
standards discussions earlier). And pretty much every C user is aware
that they are each one voice in million - features are based on
compromises that work for many people, not what happens to be perfect
for their particular needs. No, the question for C users is whether it
is a feature that will be useful for them in their own programming,
using the feature as it is defined in the standards. Can we use it to
make code more efficient, more elegant, safer, or less effort?
The answer, it seems, is that many people do think they can use _BitInt
to make their code better in some way. It doesn't matter if one person
thinks _BitInt(128) will be useful, while another thinks _BitInt(12) is
something they'd use. It doesn't matter if they will use them for FPGA
programming, small-systems embedded programming, cryptography, neater
bitfield structs, or whatever. And most importantly, it does not matter
in the slightest if someone does /not/ want to use a particular size of
_BitInt.
I don't think there is much that could be done with _BitInt's that could
not be done before in C. People could use clang's extension (_ExtInt, I
think it was called). They can use struct bitfields, or different sizes
of standard integer types, or arrays of uintNN_t types. They could make
manual maskings, macros, functions, C++ classes (for those that want to
branch out from C) or other methods to get the effect of any _BitInt
uses. But _BitInt's can be used to make some code better - clearer,
more efficient, simpler, etc.
Contrary to your beliefs, I haven't seen anyone clamouring for huge
_BitInts, especially not of "odd" sizes. It's just that no one has been
advocating for some specific arbitrary limit on sizes or on how "odd"
the size can be. Putting in such limits in the standard would be silly,
since there is no limit value that would make sense. It is far better
to leave implementations to pick a limit according to what is practical
for them.
(I am not entirely sure, but I think it is standards-conforming for an
implementation to haev BITINT_MAXWIDTH set to 64 and support all
_BitInts up size 64, and then also support _BitInts of multiples of 64
thereafter. Use of _BitInt greater than BITINT_MAXWIDTH is UB in the
standard - so an implementation can choose to give that a defined
behaviour for specific sizes.)
>>
>> You are again talking nonsense and exposing your non-sincere moves
>> to stupidly exaggerate ("screaming") and unreasonable generalize
>> ("EVERYONE"). - Yet, you prove again that you are not willing to
>> be a serious discussion partner.
>
> Yet what I said is pretty much true. Nobody care about BitInt until they
> became aware of, and now it's must-have.
>
Of course people cared about _BitInt before it existed - otherwise no
one would have implemented its prototype in clang, or written the
proposals for standardising it, and then putting it into the standards,
and then implementing it in compilers.
And I don't see anyone calling it a "must-have". But it is hardly
surprising that the people involved in a discussion thread entitled
"_BitInt(N)" with the question "Is anyone using or planning to use this
new C23 feature?" are people that are interested in using it!
In this thread, there are people who are interested in using the
feature. There are people who are just interested in C in general, and
want to understand it even if they probably won't use it themselves.
Perhaps there are some people who have chimed in to say they are not
interested in it at all - I haven't noticed any, but it's a big thread
and I might have missed some posts. That too would be a reasonable and
valid opinion to express.
And then there is one person who just wants to moan and whine about
everything in C, and invents problems, misrepresents people's opinions
and posts, and exaggerates to an absurd extent in order to "justify" his
over-inflated ego and self-image of being the sole source of "good
language and tool design".
I am struggling to understand your motivations, and to give you the
benefit of the doubt - to put your posts down to ignorance or
frustration rather than bitterness, hubris or egotism. You make it
increasingly difficult.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-12-01 11:29 +0000 |
| Message-ID | <10gju6i$18gnk$1@dont-email.me> |
| In reply to | #395625 |
On 01/12/2025 10:33, David Brown wrote: > On 30/11/2025 18:55, bart wrote: >> On 30/11/2025 17:17, Janis Papanagnou wrote: >>> On 2025-11-30 13:51:22, bart wrote: > > <snip> > >> >> I've said many times that it's a poorly designed feature. > > You have said continuously that you think everything about C, along with > everything you believe to be related to C (however tenuous the > connection may be in reality) is poorly designed. With C it is 75% about syntax. Some of it is about type systems, but mostly it is similar to what I have. The new _BitInt (which as you know I don't much like) makes the divergence greater. It seems that > absolutely everything that you did not design personally, is poorly > designed in your eyes. I'm not even sure you think your own languages > are well designed, given the number of times you've found new features > or limitations that you didn't know they had. Yeah, I'm a bit of a perfectionist. So what? > Perhaps you just have a different scale of what is "poor design" and > "good design". Or maybe you don't understand that things don't have to > be perfect to be good enough in practice. And my own designs are also full of compromises. One big one is that the systems language knows its place; I keep it simple and don't try and make it one or two levels higher. Other modern 'systems' language are much higher level, but also harder to use, more complicated, and less efficient to process. > You certainly don't seem to > understand that when there is more than one person involved - and for C, > there are millions involved - compromises are inevitable, and elegance > of design must bow to compatibility requirements. > >> Read the thread, as I'm not going to repeat things. > > Is that a promise? How a look at the first post I made in the thread. I've no idea how to do links, so a copy of it is pasted below. My other posts are mostly defending that view. > The answer, it seems, is that many people do think they can use _BitInt > to make their code better in some way. It doesn't matter if one person > thinks _BitInt(128) will be useful, while another thinks _BitInt(12) is > something they'd use. How much of this feature came about because of LLVM's support for integer types up to 2**23 or 2**24 /bits/? I thought /that/ was crass. > It doesn't matter if they will use them for FPGA > programming, small-systems embedded programming, cryptography, neater > bitfield structs, or whatever. And most importantly, it does not matter > in the slightest if someone does /not/ want to use a particular size of > _BitInt. That's like saying we should all be using C++ compilers for C programs, and just ignore all the features we don't want. So why /do/ C-only compilers still exist? ============================================================================= bart: 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-12-01 14:10 +0100 |
| Message-ID | <10gk44c$1bg69$1@dont-email.me> |
| In reply to | #395626 |
On 01/12/2025 12:29, bart wrote: > On 01/12/2025 10:33, David Brown wrote: >> On 30/11/2025 18:55, bart wrote: >>> On 30/11/2025 17:17, Janis Papanagnou wrote: >>>> On 2025-11-30 13:51:22, bart wrote: >> >> <snip> >> >>> >>> I've said many times that it's a poorly designed feature. >> >> You have said continuously that you think everything about C, along >> with everything you believe to be related to C (however tenuous the >> connection may be in reality) is poorly designed. > > With C it is 75% about syntax. Some of it is about type systems, but > mostly it is similar to what I have. The new _BitInt (which as you know > I don't much like) makes the divergence greater. > So your argument against C is that it is different from your language. That's /very/ persuasive. > > It seems that >> absolutely everything that you did not design personally, is poorly >> designed in your eyes. I'm not even sure you think your own languages >> are well designed, given the number of times you've found new features >> or limitations that you didn't know they had. > > Yeah, I'm a bit of a perfectionist. So what? You are taking your highly subjective and personal views on "perfect" and applying them mindlessly to something different made by many people, for the use of many people. And worst of all, you believe that your opinions are somehow objective - you assume that anyone who says they like, or even merely don't object to, a particular feature of C is either lying or mistaken. We all know that C is not "perfect", no matter how "perfect" might be defined - because we all know that is completely impossible. You are not a perfectionist. You are a negativist. I am fully convinced that if you had not invented the languages you use, but were presented with them by someone else, you would moan and groan about them as much as you do about C. > >> Perhaps you just have a different scale of what is "poor design" and >> "good design". Or maybe you don't understand that things don't have >> to be perfect to be good enough in practice. > > And my own designs are also full of compromises. One big one is that the > systems language knows its place; I keep it simple and don't try and > make it one or two levels higher. Other modern 'systems' language are > much higher level, but also harder to use, more complicated, and less > efficient to process. > >> You certainly don't seem to understand that when there is more than >> one person involved - and for C, there are millions involved - >> compromises are inevitable, and elegance of design must bow to >> compatibility requirements. >> >>> Read the thread, as I'm not going to repeat things. > >> >> Is that a promise? > > How a look at the first post I made in the thread. I've no idea how to > do links, so a copy of it is pasted below. I had a look - it's whining and moaning about how terrible _BitInt is, despite not having a clue about what it is, why it was introduced, how it could be implemented and how people might use it. > > My other posts are mostly defending that view. Your other posts are repeating most of the same stuff - either specifically about _BitInt, or generally about C. > > >> The answer, it seems, is that many people do think they can use >> _BitInt to make their code better in some way. It doesn't matter if >> one person thinks _BitInt(128) will be useful, while another thinks >> _BitInt(12) is something they'd use. > > How much of this feature came about because of LLVM's support for > integer types up to 2**23 or 2**24 /bits/? I thought /that/ was crass. The feature did not come about because of that. > >> It doesn't matter if they will use them for FPGA programming, >> small-systems embedded programming, cryptography, neater bitfield >> structs, or whatever. And most importantly, it does not matter in the >> slightest if someone does /not/ want to use a particular size of _BitInt. > > That's like saying we should all be using C++ compilers for C programs, > and just ignore all the features we don't want. Do you bother to read posts at all? I didn't say anything that could plausibly be interpreted in any such manner. It is very difficult to communicate with someone who does not seem to be willing or able to understand the written word. All programmers of all languages will, for the most part, ignore features they don't want. And people should obviously use C++, or any other language, instead of C if it suits their needs better - why would anyone not use the most suitable language (where "suitable" is all-encompassing, including developer knowledge, tool and target support, task requirements, and anything else you can think of) ? > > So why /do/ C-only compilers still exist? > > ============================================================================= > > bart: > 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. > Yes, that is one possible use-case. It is neither necessary nor sufficient, but is one example. > 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). > No, it is quite straightforward when you know _BitInt's are specified. (And note that the final definitions in the standard are /not/ a direct copy of everything mentioned in the proposal.) > Such as working out how pointers to them will work. > There are no problems there. You should know that by now. > > >> 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. > If C23 were only adding a 128-bit type, then I'd agree that int128_t and uint128_t would be the best names. (There are would be certain details in the specifications for types that would need to be changed in the standard to make these fit, but those changes would be doable.) However, with the introduction of a more general mechanism the need for such individually documented types is gone. That's nice - the general solution subsumes the need for the individual solutions. > But there are two problems with _BitInt: > > * Any odd sizes are allowed, such as _BitInt(391) That's not a problem except in your mind. > > * There appears to be no upper limit on size, so _BitInt(2997901) is a > valid type That's not a problem except in your mind. > > So what is the result type of multiplying values of those two types? You already know the answer. I thought you were going to stop repeating yourself? Why do you keep asking the same questions and ignoring the answers? Ask once - that's fair enough, though you could have learned about the types before you started criticising them. > > 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. > There we go again, with the totally subjective and unjustified opinions stated as though they were some kind of universal fact. I don't know how you get so confident about thinking you have the single correct answer when you haven't even considered how many different questions there are. Is this some kind of Dunning-Kruger effect? There are a dozen different ways to implement and work with numbers of that size, depending on what you want to do with them. _BitInt(1000) can be used directly for some of these, can be used indirectly (as a storage) for others, and is useless for other cases. Some of these distinctions will depend on the quality of implementation. And exactly the same thing applies to arbitrary precision types, which can be implemented in a great many different ways.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-01 08:56 -0800 |
| Message-ID | <875xaq9m51.fsf@example.invalid> |
| In reply to | #395625 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> (I am not entirely sure, but I think it is standards-conforming for an
> implementation to haev BITINT_MAXWIDTH set to 64 and support all
> _BitInts up size 64, and then also support _BitInts of multiples of 64
> thereafter. Use of _BitInt greater than BITINT_MAXWIDTH is UB in the
> standard - so an implementation can choose to give that a defined
> behaviour for specific sizes.)
[...]
No, _BitInt(N) where N > BITINT_MAXWIDTH is a constraint violation.
N3220 6.7.3.1p2 ("Constraints") :
The parenthesized constant expression that follows the _BitInt
keyword shall be an integer constant expression N that specifies
the width (6.2.6.2) of the type. The value of N for unsigned
_BitInt shall be greater than or equal to 1. The value of N
for _BitInt shall be greater than or equal to 2. The value of
N shall be less than or equal to the value of BITINT_MAXWIDTH
(see 5.2.5.3.2).
As I mentioned before, there's a proposal for C2y to allow
signed _BitInt(1).
Of course an implementation could do what you suggest as an extension.
--
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-12-01 19:38 +0100 |
| Message-ID | <10gknaj$1io6u$2@dont-email.me> |
| In reply to | #395636 |
On 01/12/2025 17:56, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> (I am not entirely sure, but I think it is standards-conforming for an
>> implementation to haev BITINT_MAXWIDTH set to 64 and support all
>> _BitInts up size 64, and then also support _BitInts of multiples of 64
>> thereafter. Use of _BitInt greater than BITINT_MAXWIDTH is UB in the
>> standard - so an implementation can choose to give that a defined
>> behaviour for specific sizes.)
> [...]
>
> No, _BitInt(N) where N > BITINT_MAXWIDTH is a constraint violation.
>
> N3220 6.7.3.1p2 ("Constraints") :
>
> The parenthesized constant expression that follows the _BitInt
> keyword shall be an integer constant expression N that specifies
> the width (6.2.6.2) of the type. The value of N for unsigned
> _BitInt shall be greater than or equal to 1. The value of N
> for _BitInt shall be greater than or equal to 2. The value of
> N shall be less than or equal to the value of BITINT_MAXWIDTH
> (see 5.2.5.3.2).
>
> As I mentioned before, there's a proposal for C2y to allow
> signed _BitInt(1).
>
> Of course an implementation could do what you suggest as an extension.
>
Yes, of course - violating a constraint is UB, but it also requires a
diagnostic. So while an implementation could implement a limited
selection of _BitInt's larger than BITINT_MAXWIDTH, if it is to conform
to the C standards it would have to at least give a warning message when
you used these _BitInt's. As an extension (perhaps enabled by a flag),
it could then suppress such diagnostics.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-01 12:42 -0800 |
| Message-ID | <87pl8y7x2r.fsf@example.invalid> |
| In reply to | #395639 |
David Brown <david.brown@hesbynett.no> writes:
> On 01/12/2025 17:56, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> (I am not entirely sure, but I think it is standards-conforming for an
>>> implementation to haev BITINT_MAXWIDTH set to 64 and support all
>>> _BitInts up size 64, and then also support _BitInts of multiples of 64
>>> thereafter. Use of _BitInt greater than BITINT_MAXWIDTH is UB in the
>>> standard - so an implementation can choose to give that a defined
>>> behaviour for specific sizes.)
>> [...]
>> No, _BitInt(N) where N > BITINT_MAXWIDTH is a constraint violation.
>> N3220 6.7.3.1p2 ("Constraints") :
>>
>> The parenthesized constant expression that follows the _BitInt
>> keyword shall be an integer constant expression N that specifies
>> the width (6.2.6.2) of the type. The value of N for unsigned
>> _BitInt shall be greater than or equal to 1. The value of N
>> for _BitInt shall be greater than or equal to 2. The value of
>> N shall be less than or equal to the value of BITINT_MAXWIDTH
>> (see 5.2.5.3.2).
>>
>> As I mentioned before, there's a proposal for C2y to allow
>> signed _BitInt(1).
>>
>> Of course an implementation could do what you suggest as an
>> extension.
>
> Yes, of course - violating a constraint is UB, but it also requires a
> diagnostic.
I'd place a very different emphasis on that. Violating a constraint
requires a diagnostic, which needn't necessarily be fatal. If an
implementation chooses to accept the code anyway, the resulting
behavior is probably undefined (though the standard doesn't say
so explicitly).
> So while an implementation could implement a limited
> selection of _BitInt's larger than BITINT_MAXWIDTH, if it is to
> conform to the C standards it would have to at least give a warning
> message when you used these _BitInt's. As an extension (perhaps
> enabled by a flag), it could then suppress such diagnostics.
Suppressing mandatory diagnostics would not be an "extension" in
the way that term is defined by the standard. It would simply be
a failure to conform to the standard. Of course non-conforming
C-like compilers exist (like gcc in its default mode), and that's
not necessarily a bad thing.
But given that several compilers have already implemented bit-precise
integer types *without* either allowing N > BITINT_MAXWDITH or
disallowing "odd" values, I don't think it will be an issue in
practice.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-12-02 22:17 +0100 |
| Message-ID | <10gnl12$vmli$1@solani.org> |
| In reply to | #395643 |
Am 01.12.25 um 21:42 schrieb Keith Thompson: > > But given that several compilers have already implemented bit-precise > integer types *without* either allowing N > BITINT_MAXWDITH or > disallowing "odd" values, I don't think it will be an issue in > practice. > There are extensions regarding _BitInt in existing implementations: SDCC allows signed _BitInt(1), and allows the use of _BitInt as underlying type for enum. In --std-c23 mode, SDCC will emit a warning when encountering those, but the semantics are of course the same as in --std-sdcc23 mode.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-12-03 09:25 +0100 |
| Message-ID | <10gos5t$340f6$1@dont-email.me> |
| In reply to | #395661 |
On 02/12/2025 22:17, Philipp Klaus Krause wrote: > Am 01.12.25 um 21:42 schrieb Keith Thompson: >> >> But given that several compilers have already implemented bit-precise >> integer types *without* either allowing N > BITINT_MAXWDITH or >> disallowing "odd" values, I don't think it will be an issue in >> practice. >> > > There are extensions regarding _BitInt in existing implementations: SDCC > allows signed _BitInt(1), and allows the use of _BitInt as underlying > type for enum. These both seem good extensions to me. I don't know why _BitInt(1) was explicitly disallowed in C. It is arguably a fairly useless type (holding values 0 and -1), but it would seem simpler for the standard to allow it and keeping things symmetric, rather than have to make "unsigned _BitInt(1)" explicitly allowed. Since it seems likely that C++ will allow _BitInt(1) when it adopts them (with C++ templates, sometimes "useless" types become very convenient), it would not surprise me if a later C standard includes them for consistency. (But there may be good reasons for disallowing the type that I have not thought of.) I also think it makes a lot of sense to allow _BitInt types as the explicitly specified underlying type for enums - I don't know why they are disallowed. There may be some reasoning involving how enumerations or their constants can be used elsewhere, but I can't see what. If it were just a matter of avoiding complications in implementations, then their support could have been made optional here. > In --std-c23 mode, SDCC will emit a warning when encountering those, but > the semantics are of course the same as in --std-sdcc23 mode. >
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-12-03 06:17 -0500 |
| Message-ID | <10gp682$37uq3$1@dont-email.me> |
| In reply to | #395643 |
On 2025-12-01 15:42, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 01/12/2025 17:56, Keith Thompson wrote:
...
>>> No, _BitInt(N) where N > BITINT_MAXWIDTH is a constraint violation.
>>> N3220 6.7.3.1p2 ("Constraints") :
>>>
>>> The parenthesized constant expression that follows the _BitInt
>>> keyword shall be an integer constant expression N that specifies
>>> the width (6.2.6.2) of the type. The value of N for unsigned
>>> _BitInt shall be greater than or equal to 1. The value of N
>>> for _BitInt shall be greater than or equal to 2. The value of
>>> N shall be less than or equal to the value of BITINT_MAXWIDTH
>>> (see 5.2.5.3.2).
>>>
>>> As I mentioned before, there's a proposal for C2y to allow
>>> signed _BitInt(1).
>>>
>>> Of course an implementation could do what you suggest as an
>>> extension.
>>
>> Yes, of course - violating a constraint is UB, but it also requires a
>> diagnostic.
>
> I'd place a very different emphasis on that. Violating a constraint
> requires a diagnostic, which needn't necessarily be fatal. If an
> implementation chooses to accept the code anyway, the resulting
> behavior is probably undefined (though the standard doesn't say
> so explicitly).
Undefined behavior is indicated in only three ways:
"If a "shall" or "shall not" requirement that appears outside of a
constraint or runtime-constraint is violated, the behavior is undefined.
Undefined behavior is otherwise indicated in this document by the words
"undefined behavior" or by the omission of any explicit definition of
behavior." (4p2).
Which of those three methods do you think applies? This "shall" occurs
inside a constraint. There's no explicit statement that it is undefined
behavior. There is an explicit definition for the behavior, provided by
what the standard says about _BitInt outside of this constraint.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-03 10:07 -0800 |
| Message-ID | <87fr9ro2vp.fsf@example.invalid> |
| In reply to | #395668 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2025-12-01 15:42, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 01/12/2025 17:56, Keith Thompson wrote:
> ...
>>>> No, _BitInt(N) where N > BITINT_MAXWIDTH is a constraint violation.
>>>> N3220 6.7.3.1p2 ("Constraints") :
>>>>
>>>> The parenthesized constant expression that follows the _BitInt
>>>> keyword shall be an integer constant expression N that specifies
>>>> the width (6.2.6.2) of the type. The value of N for unsigned
>>>> _BitInt shall be greater than or equal to 1. The value of N
>>>> for _BitInt shall be greater than or equal to 2. The value of
>>>> N shall be less than or equal to the value of BITINT_MAXWIDTH
>>>> (see 5.2.5.3.2).
>>>>
>>>> As I mentioned before, there's a proposal for C2y to allow
>>>> signed _BitInt(1).
>>>>
>>>> Of course an implementation could do what you suggest as an
>>>> extension.
>>>
>>> Yes, of course - violating a constraint is UB, but it also requires a
>>> diagnostic.
>>
>> I'd place a very different emphasis on that. Violating a constraint
>> requires a diagnostic, which needn't necessarily be fatal. If an
>> implementation chooses to accept the code anyway, the resulting
>> behavior is probably undefined (though the standard doesn't say
>> so explicitly).
>
> Undefined behavior is indicated in only three ways:
> "If a "shall" or "shall not" requirement that appears outside of a
> constraint or runtime-constraint is violated, the behavior is undefined.
> Undefined behavior is otherwise indicated in this document by the words
> "undefined behavior" or by the omission of any explicit definition of
> behavior." (4p2).
>
> Which of those three methods do you think applies? This "shall" occurs
> inside a constraint. There's no explicit statement that it is undefined
> behavior. There is an explicit definition for the behavior, provided by
> what the standard says about _BitInt outside of this constraint.
It's not clear.
A constraint is defined as a "restriction, either syntactic
or semantic, by which the exposition of language elements is
interpreted". I might argue that if a constraint is violated, it's
not possible to interpret the exposition of the language elements.
(That would fall under omission of any explicit definition of
the behavior.)
I'd like to see future edition of the standard explicitly state that
a constraint violation renders a program's behavior undefined. Or an
explicit statement that it doesn't would still be an improvement.
--
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]
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web