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 | 8 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 13 of 13 — ← Prev page 1 … 11 12 [13]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-11-24 13:12 -0600 |
| Message-ID | <10g2as7$2ndvg$1@dont-email.me> |
| In reply to | #395420 |
On 11/24/2025 8:21 AM, bart wrote:
> On 24/11/2025 13:35, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> There are two kinds of BitInts: those smaller than 64 bits; and those
>>> larger than 64 bits, sometimes /much/ larger.
>>
>> As far as I know, the standard makes no such distinction.
>
> *I* am making the distinction. From an implementation point of view (and
> assuming 64-bit hardware), they are quite different.
>
> And that leads to different kinds of language features.
>
As noted, as I understand it there is no reason for the storage to be
smaller than the next power-of-2 size.
Supporting odd-sized values in memory would have added a lot more of a
pain in terms of making things efficient (it is a lot more of an issue
to store a 24-bit or 40-bit item to memory than 32 or 64).
Though, one possibility could be "__packed _BitInt(n)" where in this
case it would handle them as the nearest multiple of 8 bits rather than
as the nearest power-of-2.
As least on my ISA design, Load/Store ops are mostly only available in
power-of-2 sizes, and the direct displacement case is limited to natural
alignment (though using RISC-V encodings can sidestep this limitation in
the case of the XG3 variant, or if targeting RISC-V, *).
*: In my case, the ISA has split into multiple variants:
XG1: Its original form.
16/32/64/96 bit instructions.
Mostly 5-bit register fields.
XG2: Modified.
Loses 16-bit encodings;
Gains slightly larger immediate values;
All register fields expand to 6 bits;
Encoding scheme is slightly dog-chewed.
XG3:
Instructions were repacked to be compatible with RISC-V;
Register numbering was made compatible with RISC-V;
Un-dog-chewed the encoding scheme some vs its predecessors;
Instruction stream can be mixed/matched with RV64G.
However, while both RV64G and XG3 ops support superscalar.
For reasons, my CPU core can't co-issue RV64 and XG3 instructions.
So, it is more like the ISA can flip/flop every clock-cycle.
However, can note that RISC-V also still lacks NPOT memory operations.
And, if your memory store looks like:
SRLI X6, X10, 16
SW X10, 13(X12)
SB X6, 15(X12)
This isn't great, don't want to pay these sorts of penalties without reason.
For odd-sized _BitInt, one pays the cost mostly by using sign/zero
extension on certain operations.
In basic forms of both ISAs, this can be done via a pair of shift
instructions, say, zero-extending 24 bits:
SLLI X10, X10, 40
SRLI X10, X10, 40
In my case, there is an optional feature that can allow this to be
encoded as a single instruction. Although the instruction in question
uses a 64-bit encoding; so doesn't save any code-size over the pair of
shifts, but is faster; partly also because in my CPU core most
instructions have a minimum latency of 2 clock cycles; which isn't ideal
for a lot of RISC-V's patterns.
Though, on the CPU in question, the ideal scheduling isn't so much to
try to reuse a register immediately, but if possible to put around 5
instructions between modifying a register and trying to access its value
again (but, this case really sucks for some constructs in RV).
Like, one can't optimally schedule an array index load (needs 3
instructions in RV64G) when such scheduling will most likely exceed the
total length of the loop body (and trying to modulo-schedule array-loads
is just kinda absurd).
Well, technically, CPU isn't VLIW (at least for RV64 and XG3, XG1 and
XG2 were "LIW"), but being 3-wide in-order, optimal case for performance
is still to try to schedule things as-if they were (V)LIW.
Though, the spacing drops to 3 intermediate instructions if scheduling
for 2-wide; which may make sense either if there isn't sufficient ILP to
optimize for 3-wide scheduling (most of the time) or the code is doing
things that hinder 3-wide operation (minority case; but can happen as
the 3rd lane in this case only does basic ALU instructions and is
"eaten" by certain instructions, such as indexed-store, etc).
...
My compiler still doesn't deal with all of this well (and sorta blows it
off in the case of targeting RV64G or RV64GC), but this sort of thing
seems to be sort of a pain case in general (and it sorta helps if the
programmer also write their code in a way that helps the compiler along
here; but helps some if ISA design limitations don't actively hinder the
ability to generate efficient code in this area).
...
Though, had noted that (curiously) writing code as-if one were targeting
a modulo-scheduled VLIW seems to help with x86-64 as well, even if
x86-64 has nowhere near enough registers to benefit here (it is almost
as-if x86-64 has a mechanism in place to cheapen the cost of stack
spills and reloads).
In my case, I had instead used 64 GPRs (from the RV64G POV, it is just
the X and F register spaces glued together). Where 64 is mostly enough
to competently modulo-schedule things and not run out of registers.
Though, it is only some kinds of code that can benefit from the power of
64 GPRs.
But, yeah, in any case, I guess the main issue is that NPOT loads/stores
would suck here in the absence of dedicated CPU instructions (in a
similar way to how much it hurts by RV64G lacking indexed-load/store;
where array operations are often very common in the types of code one
might want to optimize via modulo scheduling the loop).
But, you don't really want to add NPOT Load/Store instructions either,
because this more just offloads the pain onto the CPU.
...
> If the possibilities above 64 bits were less ambitious (say i128 and
> i256), then the concept might be stretched to cover both. But not when
> when you can also have i1234567.
>
> It would be having a GETBITS macro, which is not limited to a 1- to 63-
> bit bitfield of a u64 value, but could return a slice of an arbitrarily
> large array.
>
I added some Verilog style notation, which can in premise be used for
large _BitInts. However this case is untested and very likely runs into
an "implementation hole" for types larger than 128 bits.
>>
>>> I had been responding to the claim that those smaller types save
>>> memory, compared to using sizes 8/16/32 bits which are commonly
>>> available and have better hardware support.
>>
>> I don't recall any such claim. Do you have a citation (other than
>> the FPGA-specific wording in N2709)?
>
> This is where it came up in this thread:
>
> On 23/11/2025 11:46, Philipp Klaus Krause 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. Also
> > being able to use bit-fields wider than int.
> >
> > Saving memory for two reasons:
> >
> > * On small embedded systems where there is very little memory
> > * For code that needs to be very fast on big systems to make data
> > structures fit into cache
> >
>
> Although this doesn't go as far as using odd bit-sizes: it would mean
> using sizes like 24, 40, 48, and 56 bits instead of 32 or 64 bits.
>
> The savings would be sparse.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-24 17:00 -0800 |
| Message-ID | <87ldjv2afy.fsf@example.invalid> |
| In reply to | #395430 |
BGB <cr88192@gmail.com> writes:
> On 11/24/2025 8:21 AM, bart wrote:
>> On 24/11/2025 13:35, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>> [...]
>>>> There are two kinds of BitInts: those smaller than 64 bits; and those
>>>> larger than 64 bits, sometimes /much/ larger.
>>>
>>> As far as I know, the standard makes no such distinction.
>>
>> *I* am making the distinction. From an implementation point of view
>> (and assuming 64-bit hardware), they are quite different.
>> And that leads to different kinds of language features.
>
> As noted, as I understand it there is no reason for the storage to be
> smaller than the next power-of-2 size.
Really?
Rounding up to 8, 16, 32, or the next multiple of 64 bits seems
reasonable. Rounding 1025 bits up to 2048 does not (and is not
the current gcc and llvm/clang implementations do).
What advantage does rounding 1025 up to 2048 give you over rounding
it up to 1088 (17*64)? It seems to me that the only real difference
is in how many times a loop has to iterate.
My understanding is that power-of-two sizes lose their advantages
beyond about 64 or 128 bits. Am I mistaken?
[...]
--
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 | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-11-24 20:10 -0600 |
| Message-ID | <10g33c0$30v8f$1@dont-email.me> |
| In reply to | #395446 |
On 11/24/2025 7:00 PM, Keith Thompson wrote:
> BGB <cr88192@gmail.com> writes:
>> On 11/24/2025 8:21 AM, bart wrote:
>>> On 24/11/2025 13:35, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>> [...]
>>>>> There are two kinds of BitInts: those smaller than 64 bits; and those
>>>>> larger than 64 bits, sometimes /much/ larger.
>>>>
>>>> As far as I know, the standard makes no such distinction.
>>>
>>> *I* am making the distinction. From an implementation point of view
>>> (and assuming 64-bit hardware), they are quite different.
>>> And that leads to different kinds of language features.
>>
>> As noted, as I understand it there is no reason for the storage to be
>> smaller than the next power-of-2 size.
>
> Really?
>
> Rounding up to 8, 16, 32, or the next multiple of 64 bits seems
> reasonable. Rounding 1025 bits up to 2048 does not (and is not
> the current gcc and llvm/clang implementations do).
>
Granted, I meant for smaller sizes (below 128 bits).
BGBCC rounds larger sizes up to the next multiple of 128 bits.
However, 384 bits is the first size where rounding up to a multiple of
128 bits differs from the next power of 2.
> What advantage does rounding 1025 up to 2048 give you over rounding
> it up to 1088 (17*64)? It seems to me that the only real difference
> is in how many times a loop has to iterate.
>
> My understanding is that power-of-two sizes lose their advantages
> beyond about 64 or 128 bits. Am I mistaken?
>
> [...]
>
I mentioned a few messages up that this was not the scheme I am using.
So:
1.. 8 => 8
9.. 16 => 16
17.. 32 => 32
33.. 64 => 64
65..128 => 128
129..256 => 256
256..384 => 384 (first point of divergence)
385..512 => 512
513..640 => 640 (second point of divergence)
641..768 => 768 (third point of divergence)
...
But, alas, reason for keeping small sizes power-of-2 is to optimize for
memory loads/stores.
Reason for multiples of 128 bits for larger sizes was this was the most
efficient option for the target ISA (ans also less complicated for the
support code).
Though, if optimizing for RISC-V, a case could be made for using the
next multiple of 64 bits instead.
...
While theoretically possible, multiples of a smaller size would end up
being a worse option in terms of performance than just "wasting" a few
extra bytes.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-11-29 22:30 +0100 |
| Message-ID | <10gfokt$sda3$3@solani.org> |
| In reply to | #395420 |
Am 24.11.25 um 15:21 schrieb bart: >>> I had been responding to the claim that those smaller types save >>> memory, compared to using sizes 8/16/32 bits which are commonly >>> available and have better hardware support. >> >> I don't recall any such claim. Do you have a citation (other than >> the FPGA-specific wording in N2709)? > > This is where it came up in this thread: > > On 23/11/2025 11:46, Philipp Klaus Krause 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. Also > > being able to use bit-fields wider than int. > > > > Saving memory for two reasons: > > > > * On small embedded systems where there is very little memory > > * For code that needs to be very fast on big systems to make data > > structures fit into cache > > > > Although this doesn't go as far as using odd bit-sizes: it would mean > using sizes like 24, 40, 48, and 56 bits instead of 32 or 64 bits. > > The savings would be sparse. > > "On small embedded systems" - those tend to be 8-bit systems, so compilers targeting them would only round up to multiple of 8, i.e. a BitInt(40) is exactly 5 bytes. Also "bit-fields wider than int" - for bit-fields it can indeed make sense to have a width that is not a multiple of 8, if the remaining bits of the last byte can be used for other purposes. Philipp
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-30 01:51 +0000 |
| Message-ID | <10gg7vh$1fl4d$4@paganini.bofh.team> |
| In reply to | #395577 |
Philipp Klaus Krause <pkk@spth.de> wrote:
> Am 24.11.25 um 15:21 schrieb bart:
>>>> I had been responding to the claim that those smaller types save
>>>> memory, compared to using sizes 8/16/32 bits which are commonly
>>>> available and have better hardware support.
>>>
>>> I don't recall any such claim. Do you have a citation (other than
>>> the FPGA-specific wording in N2709)?
>>
>> This is where it came up in this thread:
>>
>> On 23/11/2025 11:46, Philipp Klaus Krause 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. Also
>> > being able to use bit-fields wider than int.
>> >
>> > Saving memory for two reasons:
>> >
>> > * On small embedded systems where there is very little memory
>> > * For code that needs to be very fast on big systems to make data
>> > structures fit into cache
>> >
>>
>> Although this doesn't go as far as using odd bit-sizes: it would mean
>> using sizes like 24, 40, 48, and 56 bits instead of 32 or 64 bits.
>>
>> The savings would be sparse.
>>
>>
>
> "On small embedded systems" - those tend to be 8-bit systems, so
> compilers targeting them would only round up to multiple of 8, i.e. a
> BitInt(40) is exactly 5 bytes. Also "bit-fields wider than int" - for
> bit-fields it can indeed make sense to have a width that is not a
> multiple of 8, if the remaining bits of the last byte can be used for
> other purposes.
I think it is better to say "8-bit systems". People here wrote
that RPi Pico with its 256 kB RAM and megabytes of flash is small.
I have CH32V003, 32-bit MCU which has 2 KB RAM and 16 kB flash,
I would call it small. MSP430 is 16-bit, and was available with
some tiny RAM and 2 kB flash, I would say that most embedded
systems (counting projects, not number chips/subsystems that were
manufactured) is bigger. Clearly 8-bit MCU-s are used in some
high-volume projects, but now one can get relatively small
32-bit MCU-s and various statistics indicate that 32-bit
MCU-s get more use than 8-bit ones. So, claim that "small
embedded systems tend to be 8-bit systems" is debatable.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-11-30 11:22 +0200 |
| Message-ID | <20251130112208.000061f5@yahoo.com> |
| In reply to | #395588 |
On Sun, 30 Nov 2025 01:51:47 -0000 (UTC) antispam@fricas.org (Waldek Hebisch) wrote: > Philipp Klaus Krause <pkk@spth.de> wrote: > > Am 24.11.25 um 15:21 schrieb bart: > >>>> I had been responding to the claim that those smaller types save > >>>> memory, compared to using sizes 8/16/32 bits which are commonly > >>>> available and have better hardware support. > >>> > >>> I don't recall any such claim. Do you have a citation (other than > >>> the FPGA-specific wording in N2709)? > >> > >> This is where it came up in this thread: > >> > >> On 23/11/2025 11:46, Philipp Klaus Krause 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. Also being able to use bit-fields wider than int. > >> > > >> > Saving memory for two reasons: > >> > > >> > * On small embedded systems where there is very little memory > >> > * For code that needs to be very fast on big systems to make > >> > data structures fit into cache > >> > > >> > >> Although this doesn't go as far as using odd bit-sizes: it would > >> mean using sizes like 24, 40, 48, and 56 bits instead of 32 or 64 > >> bits. > >> > >> The savings would be sparse. > >> > >> > > > > "On small embedded systems" - those tend to be 8-bit systems, so > > compilers targeting them would only round up to multiple of 8, i.e. > > a BitInt(40) is exactly 5 bytes. Also "bit-fields wider than int" - > > for bit-fields it can indeed make sense to have a width that is not > > a multiple of 8, if the remaining bits of the last byte can be used > > for other purposes. > > I think it is better to say "8-bit systems". People here wrote > that RPi Pico with its 256 kB RAM and megabytes of flash is small. > I have CH32V003, 32-bit MCU which has 2 KB RAM and 16 kB flash, > I would call it small. MSP430 is 16-bit, and was available with > some tiny RAM and 2 kB flash, I would say that most embedded > systems (counting projects, not number chips/subsystems that were > manufactured) is bigger. Clearly 8-bit MCU-s are used in some > high-volume projects, but now one can get relatively small > 32-bit MCU-s and various statistics indicate that 32-bit > MCU-s get more use than 8-bit ones. So, claim that "small > embedded systems tend to be 8-bit systems" is debatable. > I agree. What matters is the size of memory. In context of our discussion - the size of writable RAM. 32-bit MCU with 16 or less KB of RAM in my book is small, even if it happens to have 2MB of NOR Flash. Besides, compactness of data can be important on not so small systems as well. If my MCU have 128 KB of RAM and I want to keep a vectors with 40,000 24-bit elements then I certainly don't want each element to occupy 4 bytes.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-24 04:37 -0800 |
| Message-ID | <87ecpn4nea.fsf@example.invalid> |
| In reply to | #395399 |
BGB <cr88192@gmail.com> writes:
[...]
> In BGBCC, there is a hard limit of IIRC 16384 bits.
>
> As an extension, it also allows for very large literals, though
> currently literals larger than 128 bits can only use hexadecimal or
> similar.
>
> This is encoded via suffixes, eg:
> I, L, LL, U, UI, UL, ULL: Normal 32/64 bit.
> I128, UI128: 128-bit
> I256, UI256: 256-bit
> other odd sizes map to _BitInt or _UBitInt (unsigned _BitInt).
In C23, an integer constant with a "wb" or "WB" suffix is of type
_BitInt(n). One with a "wbu" suffix is of type unsigned _BitInt(n).
The value of n is the smallest that can accomodate the value of the
constant.
[...]
--
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 | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-11-24 11:52 -0600 |
| Message-ID | <10g265j$2l15u$1@dont-email.me> |
| In reply to | #395409 |
On 11/24/2025 6:37 AM, Keith Thompson wrote:
> BGB <cr88192@gmail.com> writes:
> [...]
>> In BGBCC, there is a hard limit of IIRC 16384 bits.
>>
>> As an extension, it also allows for very large literals, though
>> currently literals larger than 128 bits can only use hexadecimal or
>> similar.
>>
>> This is encoded via suffixes, eg:
>> I, L, LL, U, UI, UL, ULL: Normal 32/64 bit.
>> I128, UI128: 128-bit
>> I256, UI256: 256-bit
>> other odd sizes map to _BitInt or _UBitInt (unsigned _BitInt).
>
> In C23, an integer constant with a "wb" or "WB" suffix is of type
> _BitInt(n). One with a "wbu" suffix is of type unsigned _BitInt(n).
> The value of n is the smallest that can accomodate the value of the
> constant.
>
OK, I missed that part.
I had a need though in this case to specify an exact width for the
constant in some use cases, rather than merely just specify its largeness.
But, yeah, I<nn> and U<nn> / UI<nn> are non-standard, but alas...
Follows a similar pattern as for printf modifiers, say:
printf("%I64u\n", longValue); //MSVC specific
Vs, say:
printf("%llu\n", longValue); //Most everything else
In this case, the I<nn> notation being extended to also cover __int128
and _BitInt.
...
> [...]
>
[toc] | [prev] | [standalone]
Page 13 of 13 — ← Prev page 1 … 11 12 [13]
Back to top | Article view | comp.lang.c
csiph-web