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 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-12-15 08:19 -0800 |
| Message-ID | <86y0n3u38l.fsf@linuxsc.com> |
| In reply to | #395669 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 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.
I think a better description is "no behavior". The C standard
specifies the meaning of C programs. Source code that violates
one or more constraints is not a C program, even if it might look
like one.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-12-15 08:21 -0800 |
| Message-ID | <86tsxru353.fsf@linuxsc.com> |
| In reply to | #395636 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> 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).
Yay! Sanity prevails.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-30 18:05 -0800 |
| Message-ID | <87a5039csr.fsf@example.invalid> |
| In reply to | #395609 |
bart <bc@freeuk.com> writes:
[...]
> 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!
No.
Nobody here, myself included, is "screaming" about 31-bit or 65-bit
integer types (other than you).
The current edition of the C standard, C23, mandates support for
bit-precise integer types. Support for 31-bit types is mandatory.
Support for 65-bit types is optional (BITINT_MAXWIDTH can be as
small as 64).
Most of us, myself included, have been discussing this feature: how
it's defined, how it can be used, how compilers can implement it.
Most of us are more interested in discussing C as it's defined,
and how to use it, than in advocacy for or against new features.
I have never advocated for or against bit-precise integer types.
I'm not sure how long I've known about them. I observe that they
are now a standard part of the C language. It is a fact that any
conforming C23 compiler must support _BitInt types with odd sizes.
You argue that bit-precise types with sizes that don't meet your
personal criteria are silly and should be forbidden by the language.
Well, they aren't, and that's not going to change. I understand that
you think bit-precise types should have been defined less flexibly;
how many times do you need to repeat it?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-29 20:32 -0800 |
| Message-ID | <87ikes9m3c.fsf@example.invalid> |
| In reply to | #395589 |
bart <bc@freeuk.com> writes:
> On 30/11/2025 00:46, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 29/11/2025 20:24, Waldek Hebisch wrote:
>>>> bart <bc@freeuk.com> wrote:
>>>>> On 24/11/2025 20:26, David Brown wrote:
>>>>>> On 24/11/2025 19:35, bart wrote:
>>>>>
>>>>>>> But now there is this huge leap, not only to 128/256/512/1024 bits,
>>>>>>> but to conceivably millions, plus the ability to specify any weird
>>>>>>> type you like, like 182 bits (eg. somebody makes a typo for
>>>>>>> _BitInt(128), but they silently get a viable type that happens to be a
>>>>>>> little less efficient!).
>>>>>>>
>>>>>>
>>>>>> And this huge leap also lets you have 128-bit, 256-bit, 512-bit, etc.,
>>>>>
>>>>> And 821 bits. This is what I don't get. Why is THAT so important?
>>>>>
>>>>> Why couldn't 128/256/etc have been added first, and then those funny
>>>>> ones if the demand was still there?
>>>>>
>>>>> If the proposal had instead been simply to extend the 'u8 u16 u32 u64'
>>>>> set of types by a few more entries on the right, say 'u128 u256 u512',
>>>>> would anyone have been clamouring for types like 'u1187'? I doubt it.
>>>>>
>>>>> For sub-64-bit types on conventional hardware, I simply can't see the
>>>>> point, not if they are rounded up anyway. Either have a full range-based
>>>>> types like Ada, or not at all.
>>>> First, _BitInt(821) (and _BitInt(1187)) are really unimportant. You
>>>> simple get them as a byproduct of general rules.
>>>
>>> That they are allowed is the problem. People use them and expect the
>>> compiler to waste its time generating bit-precise code.
>> You are literally the only person I've seen complain about it. And
>> you can avoid any such problem by not using unusual sizes in your
>> code.
>>
>> You want to impose your arbitrary restrictions on the rest of us.
>>
>> Do you even use _BitInt types?
>>
>> Oh no, I can type (n + 1187), and it will yield the sum of n and
>> 1187. Why would anyone want to add 1187 to an integer? The language
>> should be changed (made more complicated) to forbid operations that
>> don't make obvious sense!!
>
> You seem to be mixing up values and types. Or are arguing for there to
> be nearly as many integer types as possible values.
You know that I understand the distinction between value and types.
I used (n + 1187) as an example of something that's not obviously
useful, but that is not the basis of a good argument that it should
be forbidden.
> Everyone in this group seems obsessed with not having any limitations
> at all in the language.
That's not true at all.
Let me be clear about what I've been saying. If C23 had introduced
_BitInt types with the restrictions you want, I likely wouldn't have
complained. I'm still not sure just what restrictions you want, but for
example, it could have required support for all widths up to the width
of uintmax_t (typically, but not necessarily, 64 bits), and multiples of
the width of uintmax_t up to an implementation-defined limit. Or maybe
multiples of CHAR_BIT. I would have been ok with that.
C23's definition is more flexible than that. That flexibility has
apparently not caused problems for implementators (in fact clang
has a flexible version of the feature before it was added to C23).
And it's part of the ISO C standard, which makes it very difficult to
change.
I find it interesting that the C23 standard requires support for
*all* widths up to BITINT_MAXWIDTH, and that gcc and clang have
implemented that support. I also find it interesting that sdcc
sets BITINT_MAXWIDTH to 64, which is also perfectly valid (and
happens to be consistent with the restrictions you want to impose,
if I understand them correctly).
What I usually discuss here is what the C standard actually says
and how to use it.
You, on the other hand, see a new feature and are offended by it
because it's more flexible than you think it should be.
> For example, gcc allows identifiers up to 4 billion characters along,
> or something (I think I've tested it with three 1-billion-character
> variables.)
>
> There was a discussion here about it. Of course, even
> million-character names would be totally impractical to work with. I'd
> have trouble with 256 characters (my own cap).
I haven't looked into this particular case, but I presume that the
implementers of gcc chose to implement their lexical analysis in
a way that does not implies a fixed limit on identifier lengths.
Using a billion-character identifier would be silly, but the gcc
developers apparently felt no need to go out of their way to forbid
such identifiers. I have no problem with that, and I don't know
why you do.
Doctor, it hurts when I do this.
> The rationale for BitInts seems to be heading the same way. The work
> for billion-character variables as already 'been done'. That doesn't
> mean they are sensible or practical or efficient!
They are practical, in the sense that working implementations exist.
If you don't find them sensible, don't use them.
There are inefficiencies in at least one existing implementation, which
I expect to be corrected (there's an open bug report). Other than that,
what inefficiencies are you concerned about?
Do you really believe that the fact that you don't find something
useful or sensible means that it should be forbidden?
>>> You can have general _BitInt(N) syntax and have constraints on the
>>> values of N, not just an upper limit.
>>
>> No you can't, because the language does not allow the arbitrary
>> restrictions you want. If an implementer finds _BitInt(1187)
>> too difficult, they can set BITINT_MAXWIDTH to 64.
>>
>> One more time: Both gcc and llvm/clang have already implemented
>> bit-precise types, with very large values of BITINT_MAXWIDTH.
>> What actual problems has this fact caused for you, other than giving
>> you something to complain about?
>
> What problem would there be if BitInt sizes above the machine word
> sizes had to be multiples of the word sizes?
You didn't answer my question.
> It what way would it inconvenience /you/?
Possibly none. In what way would it inconvenience anyone else?
I don't know.
But I'm certain that imposing the restrictions you want would
inconvenience the maintainers of gcc and clang.
> I just don't unlike unnecessarily flexible, lax or over-ambitious
> features in a language. I think that is as much poor design as
> underspecifying.
>
> So I'm interested in what that one extra bit in a million buys you. Or
> that one bit fewer.
Flexibility and simplicity of the language definition.
You want to impose restrictions on the value of N in _BitInt(N)
or unsigned _BitInt(N). How much work would be required to define
exactly what those restrictions should be? Is 64 bits a magic
value that should be included in the restrictions?
Surely whatever restrictions you want to impose should apply to
all C implementations for all target systems. We already have
BITINT_MAXWIDTH in <limits.h>; how many other constants would
we need?
Are you willing to take the time and effort to write up your
restrictions in standardese and advocate for adding them to C26?
And exactly what would be the benefit of such an effort? We'd end up
with a more complicated standard that rejects code that's currently
accepted by C23 implementations.
Because you think it's too flexible, and you want to impose your ideas
(which I've seen nobody else agree with) on the rest of us.
And apparently there are issues related to FPGAs, which I haven't
commented on because I lack the expertise.
[...]
>>> Apparently _BitInt(8) is incompatible with int8_t.
>>
>> Yes, it is. char, signed char, and unsigned char are also
>> incompatible with each other. How is that a problem?
>
> Signed and unsigned char have ranges of -128..+127 and 0..255
> respectively when they are 8 bits wide; they cannot be compatible.
>
> But BitInt(8) also has a -128..+127 range, yet it is not compatible
> with signed char or int8_t.
>
> Why not? Under what circumstances would somebody choose BitInt(8)
> those alternatives, and why?
_BitInt(8) is guaranteed to have a width of 8 bits, and is guaranteed to
be supported on any conforming C23 implementation. char may be wider
than 8 bits. int8_t may not exist. If you don't care about
implementations with CHAR_BIT > 8, that's fine, but other people do.
> When 'char' is signed, that means that a signed 8-bit type on PCs can
> chosen amongst four incompatible types!
Why do you care whether they're compatible? I'm not saying you
shouldn't, but you haven't made it clear why it matters to you.
[...]
I have yet to see you describe any problem that isn't neatly solved by
you not using features you don't like.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-30 12:22 +0200 |
| Message-ID | <20251130122242.00000f2e@yahoo.com> |
| In reply to | #395581 |
On Sat, 29 Nov 2025 22:58:26 +0000 bart <bc@freeuk.com> wrote: > On 29/11/2025 20:24, Waldek Hebisch wrote: > > > > First, _BitInt(821) (and _BitInt(1187)) are really unimportant. You > > simple get them as a byproduct of general rules. > > That they are allowed is the problem. People use them and expect the > compiler to waste its time generating bit-precise code. > I fail to see the difficulty for implementer. For arithmetic ops, _BitInt(1187) is almost the same as _BitInt(1216). You just add one 'and by constant' operation applied to MS word at the very end. You only have do it for unsigned variant, since for signed variant overflow is undefined, anyway. So, for signed, you can do nothing or you can do the same as unsigned, if you fill that it's simpler. The same goes for left shift. For right shift and for logical ops, _BitInt(1187) is exactly the same as _BitInt(1216). So what is all the fuss about?
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-11-30 11:41 +0100 |
| Message-ID | <10gh71g$t9vt$1@solani.org> |
| In reply to | #395601 |
Am 30.11.25 um 11:22 schrieb Michael S: > > I fail to see the difficulty for implementer. > For arithmetic ops, _BitInt(1187) is almost the same as _BitInt(1216). > You just add one 'and by constant' operation applied to MS word at the > very end. You only have do it for unsigned variant, since for signed > variant overflow is undefined, anyway. So, for signed, you can do > nothing or you can do the same as unsigned, if you fill that it's > simpler. > The same goes for left shift. > For right shift and for logical ops, _BitInt(1187) is exactly the same > as _BitInt(1216). > So what is all the fuss about? I see two implementation strategies: * Just ignore the values of the padding bits. You don't need to and or anything after arithmetic operations. Makes arithmetic as fast as possible. But you need special handling at comparisons and casts. * Always keep the padding bits in line with the value, i.e. and after arithemetic operations for unsigned, copy value of sign bit for signed. Extra effort at arithmetic operations, but no extra effort at casts and comparisons. Philipp
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-30 12:28 +0100 |
| Message-ID | <10gh9o2$8ooq$3@dont-email.me> |
| In reply to | #395602 |
On 30/11/2025 11:41, Philipp Klaus Krause wrote: > Am 30.11.25 um 11:22 schrieb Michael S: >> >> I fail to see the difficulty for implementer. >> For arithmetic ops, _BitInt(1187) is almost the same as _BitInt(1216). >> You just add one 'and by constant' operation applied to MS word at the >> very end. You only have do it for unsigned variant, since for signed >> variant overflow is undefined, anyway. So, for signed, you can do >> nothing or you can do the same as unsigned, if you fill that it's >> simpler. >> The same goes for left shift. >> For right shift and for logical ops, _BitInt(1187) is exactly the same >> as _BitInt(1216). >> So what is all the fuss about? > > I see two implementation strategies: > > * Just ignore the values of the padding bits. You don't need to and or > anything after arithmetic operations. Makes arithmetic as fast as > possible. But you need special handling at comparisons and casts. > > * Always keep the padding bits in line with the value, i.e. and after > arithemetic operations for unsigned, copy value of sign bit for signed. > Extra effort at arithmetic operations, but no extra effort at casts and > comparisons. > That sounds about right. It's much the same as the implementation of _Bool. You either ignore the padding bits while doing the calculations and filter them out when they later get in the way, or you keep them neat and consistent (signed or unsigned extended, as appropriate) during calculations and it's all fine for other operations. I have no idea what might be the most efficient choice overall - it could vary by application, but I expect implementations to have one fixed strategy.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-11-30 13:35 +0100 |
| Message-ID | <10ghdlm$teft$1@solani.org> |
| In reply to | #395605 |
Am 30.11.25 um 12:28 schrieb David Brown: >> >> I see two implementation strategies: >> >> * Just ignore the values of the padding bits. You don't need to and or >> anything after arithmetic operations. Makes arithmetic as fast as >> possible. But you need special handling at comparisons and casts. >> >> * Always keep the padding bits in line with the value, i.e. and after >> arithemetic operations for unsigned, copy value of sign bit for >> signed. Extra effort at arithmetic operations, but no extra effort at >> casts and comparisons. >> > > That sounds about right. It's much the same as the implementation of > _Bool. You either ignore the padding bits while doing the calculations > and filter them out when they later get in the way, or you keep them > neat and consistent (signed or unsigned extended, as appropriate) during > calculations and it's all fine for other operations. I have no idea > what might be the most efficient choice overall - it could vary by > application, but I expect implementations to have one fixed strategy. > _Bool is a bit different, since it promotes to int, so we don't really have arithemetic directly on _Bool: I can definitely see an implementation going one way for _BitInt, and the other for _Bool.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-11-30 15:14 +0100 |
| Message-ID | <10ghjgc$d7d1$1@dont-email.me> |
| In reply to | #395608 |
On 30/11/2025 13:35, Philipp Klaus Krause wrote: > Am 30.11.25 um 12:28 schrieb David Brown: >>> >>> I see two implementation strategies: >>> >>> * Just ignore the values of the padding bits. You don't need to and >>> or anything after arithmetic operations. Makes arithmetic as fast as >>> possible. But you need special handling at comparisons and casts. >>> >>> * Always keep the padding bits in line with the value, i.e. and after >>> arithemetic operations for unsigned, copy value of sign bit for >>> signed. Extra effort at arithmetic operations, but no extra effort at >>> casts and comparisons. >>> >> >> That sounds about right. It's much the same as the implementation of >> _Bool. You either ignore the padding bits while doing the >> calculations and filter them out when they later get in the way, or >> you keep them neat and consistent (signed or unsigned extended, as >> appropriate) during calculations and it's all fine for other >> operations. I have no idea what might be the most efficient choice >> overall - it could vary by application, but I expect implementations >> to have one fixed strategy. >> > > _Bool is a bit different, since it promotes to int, so we don't really > have arithemetic directly on _Bool: It is absolutely true that there are no arithmetic operations on _Bool's. But there are still operations on _Bool that can (on typical processors) be affected by what is in the padding bits - and thus you need to mask these out at some point. That includes converting the _Bool to an int before arithmetic operations, or comparison with another _Bool. So the same principle applies. > I can definitely see an > implementation going one way for _BitInt, and the other for _Bool. > That's entirely possible. Your choice of when to deal with the padding bits can be when creating or modifying the type, or when using it in an operation (at the assembly / processor level) that can be affected by the padding bits. The best choice depends on the efficiency of handling padding at these times, and how often "typical" code does these different types of operations. It is entirely possible that balance is different for _Bool and for various _BitInt sizes, leading to different choices in implementation strategy.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-30 12:09 +0000 |
| Message-ID | <10ghc63$a3ci$1@dont-email.me> |
| In reply to | #395601 |
On 30/11/2025 10:22, Michael S wrote: > On Sat, 29 Nov 2025 22:58:26 +0000 > bart <bc@freeuk.com> wrote: > >> On 29/11/2025 20:24, Waldek Hebisch wrote: >>> >>> First, _BitInt(821) (and _BitInt(1187)) are really unimportant. You >>> simple get them as a byproduct of general rules. >> >> That they are allowed is the problem. People use them and expect the >> compiler to waste its time generating bit-precise code. >> > > I fail to see the difficulty for implementer. > For arithmetic ops, _BitInt(1187) is almost the same as _BitInt(1216). > You just add one 'and by constant' operation applied to MS word at the > very end. You only have do it for unsigned variant, since for signed > variant overflow is undefined, anyway. So, for signed, you can do > nothing or you can do the same as unsigned, if you fill that it's > simpler. > The same goes for left shift. > For right shift and for logical ops, _BitInt(1187) is exactly the same > as _BitInt(1216). > So what is all the fuss about? You say just do this and just do that, suggesting that suporting 13-bits or 17 bits on power-of-two processors (the vast majority) over the last few decades would have been so simple. With that 17 bits of course rounded up to 24 bits storage, or maybe it's 32 bits. I've either lost track or it's implementation defined. Presumably (_BitInt821)x where 'x' has 'unsigned _BitInt(832)' type (similar to your 12-bit example), returns a _BitInt821 value, but within a 824-bit field or a 832-bit one? Which is then truncated to 621 bits (in a 624- or 640-bit field?) when assigned to a _BitInt(621) variable. It's all so obvious!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-24 18:03 -0800 |
| Message-ID | <87cy563m3v.fsf@example.invalid> |
| In reply to | #395428 |
bart <bc@freeuk.com> writes:
> On 24/11/2025 14:41, David Brown wrote:
>> On 24/11/2025 13:31, bart wrote:
>> That's all up to the implementation.
>> You are worrying about completely negligible things here.
>
> Is it that negligible? That's easy to say when you're not doing the
> implementing! However it may impact on the size and performance of
> code.
You're right, it's easy to say when I'm not doing the implementing.
Which I'm not.
The maintainers of gcc and llvm/clang have done that for me, so I don't
have to worry about it.
Are you planning to implement bit-precise integer types yourself? I
don't think you've said so in this thread. If you are, you have at
least two existing implementations you can look at for ideas.
[...]
> You don't think it strange that C doesn't even have a 128-bit type yet
> (it only barely has width-specific 64-bit ones).
C doesn't *require* 128-bit types. It certainly allows them. A C90
implementation could in principle have had 128-bit long, and a C99 or
later implementation can have 128-bit long and/or an extended 128-bit
type.
As of C99 or C11, *requiring* support for 128-bit integers probably
wouldn't have been reasonable.
Please distinguish between the language and implementations.
> There is just the poor gnu extension where 128-bit integers didn't
> have a literal form, and there was no way to print such values.
>
> But now there is this huge leap, not only to 128/256/512/1024 bits,
> but to conceivably millions, plus the ability to specify any weird
> type you like, like 182 bits (eg. somebody makes a typo for
> _BitInt(128), but they silently get a viable type that happens to be a
> little less efficient!).
Yes. With the addition of bit-precise types, gcc's __int128 might be
obsolete (though there's bound to be existing code that depends on it).
I can imagine that gcc might make __int128 an alias for _BitInt(128).
> So, 20 years of having 64-bit processors with little or no support for
> even double-word types, and now there is this explosion in
> capabilities.
Those 20 years are in the past. Not much we can do about that now.
Seriously, is your problem with _BitInt types that they're too flexible?
What advantage do you expect from imposing additional restrictions on
a feature that has already been defined and implemented?
> Or, are literals and print facilities for these new types still missing?
C23 has literals for bit-precise integer types, using a "wb" or "WB"
suffix. That's something you could have found out by reading the N3220
C23 draft, or by reading one of my posts earlier in this thread. But I
don't mind answering questions.
There doesn't seem to be printf/scanf support for bit-precise integer
types, which is a little disappointing. But since they're all distinct
types, it could be difficult to define.
> Personally I think they should have got the basics right first, like a
> decent 128-bit type, proper literals, and ways to print.
No language changes would be necessary to support 128-bit integer types.
Implementations are free to support [u]int128_t and/or to make long long
128 bits.
It would have been nice if gcc's __int128 had been developed further,
but for whatever reason that didn't happen. (Maybe there wasn't enough
demand.)
> This looks like VLAs all over again (eg. is '_BitInt(1000000) A'
> allocated on the stack?). A poorly suited, hard-to-implement feature.
It doesn't look particularly like VLAs to me. The width is a
compile-time constant. Allocating large _BitInt objects is no
harder or easier than allocating large struct objects.
Here's an idea. Rather than asserting that _BitInt(1'000'000)
is silly and obviously useless, try *asking* how it's useful.
I personally don't know what I'd do with a million-bit integer,
but maybe somebody out there has a valid use for it. Meanwhile,
its existence doesn't bother me.
My guess is that once you've implemented integers wider than 128
or 256 bits, million-bit integers aren't much extra effort.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-25 11:38 +0000 |
| Message-ID | <10g44fn$3bqef$1@dont-email.me> |
| In reply to | #395450 |
On 25/11/2025 02:03, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 24/11/2025 14:41, David Brown wrote: >>> On 24/11/2025 13:31, bart wrote: >>> That's all up to the implementation. >>> You are worrying about completely negligible things here. >> >> Is it that negligible? That's easy to say when you're not doing the >> implementing! However it may impact on the size and performance of >> code. > > You're right, it's easy to say when I'm not doing the implementing. > Which I'm not. > > The maintainers of gcc and llvm/clang have done that for me, so I don't > have to worry about it. > > Are you planning to implement bit-precise integer types yourself? I > don't think you've said so in this thread. If you are, you have at > least two existing implementations you can look at for ideas. No, apart from the usual set of 8/16/32/64 bits. I've done 128 bits, and played with 1/2/4 bits, but my view is that above this range, using exact bit-sizes is the wrong way to go. While for odd sizes up to 64 bits, bitfields are more apt than employing the type system. > Here's an idea. Rather than asserting that _BitInt(1'000'000) > is silly and obviously useless, try *asking* how it's useful. > I personally don't know what I'd do with a million-bit integer, > but maybe somebody out there has a valid use for it. Meanwhile, > its existence doesn't bother me. Again, my view is that types like _BitInt(123456) (could they have made it any more fiddly to type?!) is the same mistake that early Pascal made with arrays. It is common that an N-array of T and an M-array of T are not compatible, but usually there are ways to deal generically with both. > My guess is that once you've implemented integers wider than 128 > or 256 bits, million-bit integers aren't much extra effort. I've implemented 128-bit arithmetic, and have seen some scary-looking C code that implemented 256-bit arithmetic. Neither of those would scale to N-bits where N can be arbitrary large /and/ might not be a multiple of either 64 or 8. You would need pretty much the same algorithms as used for arbitrary precision. Those usually require N to be some multiple of 'limb' size.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-25 14:12 +0200 |
| Message-ID | <20251125141207.00001d0f@yahoo.com> |
| In reply to | #395460 |
On Tue, 25 Nov 2025 11:38:32 +0000
bart <bc@freeuk.com> wrote:
>
> No, apart from the usual set of 8/16/32/64 bits. I've done 128 bits,
> and played with 1/2/4 bits, but my view is that above this range,
> using exact bit-sizes is the wrong way to go.
>
Either that or manifestation of your NIH syndrome.
Which explanation do you consider more likely?
> While for odd sizes up to 64 bits, bitfields are more apt than
> employing the type system.
>
int sign_extend12(unsigned x)
{
return (_BitInt(12))x;
}
Nice, is not it?
Doing the same with bit fields is possible, but less obvious and less
convenient. Also it potentially can play havoc with compiler that took
strict aliasing rules more seriously than they deserve.
int sign_extend12(unsigned x)
{
struct bar {
signed a: 12;
};
return ((struct bar*)&x)->a;;
}
Doing the same with shifts is almost as convenient as with _BitInt and
it works great on all popular compilers, but according to wording of C
Standard it is Undefined Behavior.
int sign_extend12(unsigned x)
{
return (int32_t)((uint32_t)x << 20) >> 20;
}
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-25 14:57 +0000 |
| Message-ID | <10g4g4c$3h9nv$1@dont-email.me> |
| In reply to | #395461 |
On 25/11/2025 12:12, Michael S wrote:
> On Tue, 25 Nov 2025 11:38:32 +0000
> bart <bc@freeuk.com> wrote:
>
>>
>> No, apart from the usual set of 8/16/32/64 bits. I've done 128 bits,
>> and played with 1/2/4 bits, but my view is that above this range,
>> using exact bit-sizes is the wrong way to go.
>>
>
> Either that or manifestation of your NIH syndrome.
> Which explanation do you consider more likely?
I can invent anything I like. I've looked at such things many times, and
came to the conclusion that using types is the wrong approach, certainly
for this level of language.
(Yes, long ago I allowed type denotations such as:
int*N a a has N bytes or N*8 bits (from Fortran)
int:N b b has N bits
Then I realised I was never going to use anything other than some
power-of-two size of 8 bits or more, for discrete variables.)
>
>> While for odd sizes up to 64 bits, bitfields are more apt than
>> employing the type system.
>>
>
> int sign_extend12(unsigned x)
> {
> return (_BitInt(12))x;
> }
>
> Nice, is not it?
By 'bitfields' I mean bitfields within structs, but also bitfield
operators whch work on any integer values.
Bitfields are nearly always unsigned in my projects, so I don't have an
exact equivalent to this example.
But a solution not using types would look like this:
y := x.[0..11] # get first 12 bits
y := x.[12..23] # next 12 bits
x.[24..35] := y # set next 12 bits (x, y are 64 bits!)
y := x.[0..i] # get first i+1 bits
To optionally interpret a bitfield extraction as signed, I'd need to
think up some way of denoting that. For bitfield insertion it doesn't
matter.
Your example is interesting but rather limited; while it does deal with
a signed field:
* That field can only start at bit zero, without extra manipulations
* The size is fixed at 12 (if you decide to change the field size, or
you want it as a constant parameter somewhere, it starts getting
awkward)
* If you are dealing with a range of bitfield sizes, you will need a
dedicated function, or somehow enumerate all possibilities using
_Generic.
* It's not clear how bitfield insertion would work, whether you'd still
employ a _BitInt type, and/or just revert to those shifts and masks.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-25 18:29 +0200 |
| Message-ID | <20251125182943.00002586@yahoo.com> |
| In reply to | #395464 |
On Tue, 25 Nov 2025 14:57:17 +0000
bart <bc@freeuk.com> wrote:
> On 25/11/2025 12:12, Michael S wrote:
> > On Tue, 25 Nov 2025 11:38:32 +0000
> > bart <bc@freeuk.com> wrote:
> >
> >>
> >> No, apart from the usual set of 8/16/32/64 bits. I've done 128
> >> bits, and played with 1/2/4 bits, but my view is that above this
> >> range, using exact bit-sizes is the wrong way to go.
> >>
> >
> > Either that or manifestation of your NIH syndrome.
> > Which explanation do you consider more likely?
>
> I can invent anything I like. I've looked at such things many times,
> and came to the conclusion that using types is the wrong approach,
> certainly for this level of language.
>
> (Yes, long ago I allowed type denotations such as:
>
> int*N a a has N bytes or N*8 bits (from Fortran)
> int:N b b has N bits
>
> Then I realised I was never going to use anything other than some
> power-of-two size of 8 bits or more, for discrete variables.)
>
>
> >
> >> While for odd sizes up to 64 bits, bitfields are more apt than
> >> employing the type system.
> >>
> >
> > int sign_extend12(unsigned x)
> > {
> > return (_BitInt(12))x;
> > }
> >
> > Nice, is not it?
>
> By 'bitfields' I mean bitfields within structs, but also bitfield
> operators whch work on any integer values.
>
> Bitfields are nearly always unsigned in my projects, so I don't have
> an exact equivalent to this example.
>
> But a solution not using types would look like this:
>
> y := x.[0..11] # get first 12 bits
> y := x.[12..23] # next 12 bits
>
> x.[24..35] := y # set next 12 bits (x, y are 64 bits!)
>
> y := x.[0..i] # get first i+1 bits
>
> To optionally interpret a bitfield extraction as signed, I'd need to
> think up some way of denoting that. For bitfield insertion it doesn't
> matter.
>
> Your example is interesting but rather limited; while it does deal
> with a signed field:
>
> * That field can only start at bit zero, without extra manipulations
>
> * The size is fixed at 12 (if you decide to change the field size, or
> you want it as a constant parameter somewhere, it starts getting
> awkward)
>
> * If you are dealing with a range of bitfield sizes, you will need a
> dedicated function, or somehow enumerate all possibilities using
> _Generic.
>
> * It's not clear how bitfield insertion would work, whether you'd
> still employ a _BitInt type, and/or just revert to those shifts and
> masks.
>
>
>
My example is from real world. Dealing with A-to-D converters. I need
sign extension of that sort quite often.
* I don't recollect needing to sign-extend field that does not start at
offset zero, but if it happens then logical left shift [before cast] is
an obvious and natural solution.
* My ADCs have fixed # of bits. It does not change in the middle of
project. And even if it does then a new value is also fixed, so
constant (enum or define) works fine.
Same for your other points - I don't recollect that I neeed something
like that sufficiently often to ... well... recollect.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-25 18:33 +0000 |
| Message-ID | <10g4spq$3lsgn$1@dont-email.me> |
| In reply to | #395471 |
On 25/11/2025 16:29, Michael S wrote:
> On Tue, 25 Nov 2025 14:57:17 +0000
> bart <bc@freeuk.com> wrote:
>
>> On 25/11/2025 12:12, Michael S wrote:
>>> On Tue, 25 Nov 2025 11:38:32 +0000
>>> bart <bc@freeuk.com> wrote:
>>>
>>>>
>>>> No, apart from the usual set of 8/16/32/64 bits. I've done 128
>>>> bits, and played with 1/2/4 bits, but my view is that above this
>>>> range, using exact bit-sizes is the wrong way to go.
>>>>
>>>
>>> Either that or manifestation of your NIH syndrome.
>>> Which explanation do you consider more likely?
>>
>> I can invent anything I like. I've looked at such things many times,
>> and came to the conclusion that using types is the wrong approach,
>> certainly for this level of language.
>>
>> (Yes, long ago I allowed type denotations such as:
>>
>> int*N a a has N bytes or N*8 bits (from Fortran)
>> int:N b b has N bits
>>
>> Then I realised I was never going to use anything other than some
>> power-of-two size of 8 bits or more, for discrete variables.)
>>
>>
>>>
>>>> While for odd sizes up to 64 bits, bitfields are more apt than
>>>> employing the type system.
>>>>
>>>
>>> int sign_extend12(unsigned x)
>>> {
>>> return (_BitInt(12))x;
>>> }
>>>
>>> Nice, is not it?
>>
>> By 'bitfields' I mean bitfields within structs, but also bitfield
>> operators whch work on any integer values.
>>
>> Bitfields are nearly always unsigned in my projects, so I don't have
>> an exact equivalent to this example.
>>
>> But a solution not using types would look like this:
>>
>> y := x.[0..11] # get first 12 bits
>> y := x.[12..23] # next 12 bits
>>
>> x.[24..35] := y # set next 12 bits (x, y are 64 bits!)
>>
>> y := x.[0..i] # get first i+1 bits
>>
>> To optionally interpret a bitfield extraction as signed, I'd need to
>> think up some way of denoting that. For bitfield insertion it doesn't
>> matter.
>>
>> Your example is interesting but rather limited; while it does deal
>> with a signed field:
>>
>> * That field can only start at bit zero, without extra manipulations
>>
>> * The size is fixed at 12 (if you decide to change the field size, or
>> you want it as a constant parameter somewhere, it starts getting
>> awkward)
>>
>> * If you are dealing with a range of bitfield sizes, you will need a
>> dedicated function, or somehow enumerate all possibilities using
>> _Generic.
>>
>> * It's not clear how bitfield insertion would work, whether you'd
>> still employ a _BitInt type, and/or just revert to those shifts and
>> masks.
>>
>>
>>
>
> My example is from real world. Dealing with A-to-D converters. I need
> sign extension of that sort quite often.
OK, I've looked at datasheets for two 12-ADCs. Both had a choice of
analog inputs, and in both the digital value was clocked out serially
(one with the input channel number as 4 extra bits).
The first apparently had a pin-selectable signed/unsigned mode; the
second didn't mention that, but did mention 000h and FFFh limits which
suggest unsigned.
But in any case, some extra circuitry would be needed to get the 12
parallel bits before they can be input via a 16-bit read. Here, you
might just tie D11-D15 together, so that a twos complement 12-bit value
becomes a 16-bit one.
Or maybe the CPU has its own serial input pin. The point is, the whole
thing is a rather trivial matter, and it can be taken care of in several
places.
I don't know the details in your case, but if BitInt helps you save a
couple of lines of code, then fine. Although I don't think this feature
would be worth adding just for that purpose.
(The only ADCs I've used were 4-bit (homemade) and 8-bit, both giving
unsigned data in parallel, used for frame-grabbing video circuits so
read directly into memory rather than via an explicit memory- or
port-read instruction.)
> * I don't recollect needing to sign-extend field that does not start
at> offset zero,
So what's in the rest of the 32-bit field, garbage?
> Same for your other points - I don't recollect that I neeed something
> like that sufficiently often to ... well... recollect.
Yours is one of a thousand possible applications. Everyone will have
different needs. Maybe someone else will have a 16 or 32-bit value with
assorted bitfields of different widths.
Then maybe C bitfields could be used, but a bigger problem with those is
poor control over layout, which is anyway implementation-defined. (Mine
of course don't have that problem!)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-26 11:12 +0200 |
| Message-ID | <20251126111247.00000b54@yahoo.com> |
| In reply to | #395475 |
On Tue, 25 Nov 2025 18:33:30 +0000 bart <bc@freeuk.com> wrote: > > (The only ADCs I've used were 4-bit (homemade) Why am I not surprised? ;-) > and 8-bit, both giving > unsigned data in parallel, used for frame-grabbing video circuits so > read directly into memory rather than via an explicit memory- or > port-read instruction.) > ADC technology is improving at decent rate. Recently we used converter with successive-approximation architecture that delivers better SNR than most delta-sigma converters of just few years ago. Without suffering from all dis-advantages of delta-sigma. Almost 18 true bits at 2 MSPS. https://www.analog.com/en/products/ad4030-24.html
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-26 12:45 +0000 |
| Message-ID | <10g6sof$ctvh$1@dont-email.me> |
| In reply to | #395490 |
On 26/11/2025 09:12, Michael S wrote: > On Tue, 25 Nov 2025 18:33:30 +0000 > bart <bc@freeuk.com> wrote: > >> >> (The only ADCs I've used were 4-bit (homemade) > > Why am I not surprised? ;-) > >> and 8-bit, both giving >> unsigned data in parallel, used for frame-grabbing video circuits so >> read directly into memory rather than via an explicit memory- or >> port-read instruction.) >> > > ADC technology is improving at decent rate. > Recently we used converter with successive-approximation > architecture that delivers better SNR than most delta-sigma > converters of just few years ago. Without suffering from all > dis-advantages of delta-sigma. Almost 18 true bits at 2 MSPS. > > https://www.analog.com/en/products/ad4030-24.html > That's interesting; my 4-bit circuit also worked at 2M samples per second (128 samples every 52us), and probably would have worked much higher if I'd had the memory to store the results. This was in 1981.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-26 15:31 +0200 |
| Message-ID | <20251126153106.00001fe3@yahoo.com> |
| In reply to | #395497 |
On Wed, 26 Nov 2025 12:45:04 +0000 bart <bc@freeuk.com> wrote: > On 26/11/2025 09:12, Michael S wrote: > > On Tue, 25 Nov 2025 18:33:30 +0000 > > bart <bc@freeuk.com> wrote: > > > >> > >> (The only ADCs I've used were 4-bit (homemade) > > > > Why am I not surprised? ;-) > > > >> and 8-bit, both giving > >> unsigned data in parallel, used for frame-grabbing video circuits > >> so read directly into memory rather than via an explicit memory- or > >> port-read instruction.) > >> > > > > ADC technology is improving at decent rate. > > Recently we used converter with successive-approximation > > architecture that delivers better SNR than most delta-sigma > > converters of just few years ago. Without suffering from all > > dis-advantages of delta-sigma. Almost 18 true bits at 2 MSPS. > > > > https://www.analog.com/en/products/ad4030-24.html > > > > That's interesting; my 4-bit circuit also worked at 2M samples per > second (128 samples every 52us), and probably would have worked much > higher if I'd had the memory to store the results. > > This was in 1981. I would guess that your circuit used Flash ADC architecture. https://en.wikipedia.org/wiki/Flash_ADC This architecture is great for low resolution and high sample rate, but can't be improved beyond 10-11 "true" bits of resolution. Or, may be, it can, but it's so hard that nobody bothers. Instead, high res/high rate converters use pipelined architecture - sort of cross between Flash and SAR. The cost of it is typically high power consumption. Also, resolution/SNR is still not as good as really good SAR. Example of pipelined ADC: https://www.analog.com/en/products/ad9652.html
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-26 11:29 +0200 |
| Message-ID | <20251126112916.00005eef@yahoo.com> |
| In reply to | #395475 |
On Tue, 25 Nov 2025 18:33:30 +0000 bart <bc@freeuk.com> wrote: > > > * I don't recollect needing to sign-extend field that does not > > start > at> offset zero, > > So what's in the rest of the 32-bit field, garbage? > Either garbage or zero or, rarely there could be meaningful flags. I don't see how the question is relevant. > > > Same for your other points - I don't recollect that I neeed > > something like that sufficiently often to ... well... recollect. > > Yours is one of a thousand possible applications. Everyone will have > different needs. Maybe someone else will have a 16 or 32-bit value > with assorted bitfields of different widths. > > Then maybe C bitfields could be used, but a bigger problem with those > is poor control over layout, which is anyway implementation-defined. > (Mine of course don't have that problem!) According to the language of The Standard, it's not 'poor control'. As far as standard requirements goes, there is *no* control on layout of bit fields. Of course, implementer is encouraged to specify exact rules in his documents. In many (not all) cases bitfield layout is part of the ABI, so it is shared by all compilers on given platform. But that does not exactly help people that don't like reading ABI docs or compiler manuals. Also does not help those poor souls that try to write portable code. Shifts and masks provide much more solid ground. And combination of shifts with _BitInt() appears equally solid, but more convenient and more self-documenting.
[toc] | [prev] | [next] | [standalone]
Page 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web