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 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-12-02 14:12 +0000 |
| Subject | Block syntax (was Re: _BitInt(N)) |
| Message-ID | <10gms4q$2b9ms$1@dont-email.me> |
| In reply to | #395656 |
On 02/12/2025 13:15, Janis Papanagnou wrote:
> On 2025-12-02 13:21:32, bart wrote:
>> So:
>>
>> if .. then begin ... end else begin ... end
>>
>> ... represents multiple statements.
>>
>> Even I would see braces in a more favourable light. I wonder why it
>> took some years for language designers to realise you could simply have:
>>
>> if .. then ... else ... end
>
> You're misrepresenting history, or at least convey the impression
> that this would be something new and previously obscure,
I'm not misrepresenting anything at all. For example Algol60 needed
begin-end if you wanted several statements in a block; Algol68 made that
optional.
There are 'some years' between them.
> or that
> language designers would not know all these syntactical options.
>
> You had the if .. then ... else ... fi syntax as paragon in the
> back then by language experts well known Algol 68 language, it's
> been inherited (also in comparable forms), e.g. by the common Unix
> shell, also in "more recent" languages (with "end") in Eiffel, for
> example.
It's everywhere now with 'end'-based languages: Ada, modern Fortran,
Lua, Ruby. Even Wirth adopted it Modula-2.
> The huge impact of the "C" language syntax might have made that
> less visible in the modern, contemporary (used, hyped) languages.
> But there's really nothing to "realize" by language designers, I'm
> sure.
Language designers were hung up on the concept of allowing only a single
statement for each branch of a structured statement like 'if' or the
body of a loop, or of a function. I guess it made their grammars simpler.
This applies to C too. So if someone wanted multiple statements, then
they need to use a special 'compound statement' which needed enclosure:
{s1; s2; s3;}
begin s1; s2; s3 end
This now counts as single statement to satisfy the requirement. (Note C
requires a compound statement for a function body, even if it is just
one statement.)
So, what they had to realise was they could simply allow N statements
instead of 1, in such contexts. The only problem then was in delimiting
that sequence.
Some syntaxes could use a token like 'end' on the final block of a
structured statement (previous ones being delimited by then ... else for
example), but that didn't work for braces, so C-like syntaxes are stuck
with the notion of a single statement per branch.
Some others now use significant white space, a more fragile approach.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-12-02 13:53 +0100 |
| Message-ID | <10gmngs$3htol$10@dont-email.me> |
| In reply to | #395649 |
On 2025-12-02 08:31:53, David Brown wrote:
> On 01/12/2025 23:59, Janis Papanagnou wrote:
>> On 2025-12-01 21:06:13, Keith Thompson wrote:
>>>
>>> The use of curly braces vs. begin/end is IMHO trivial. [...]
>>>
>>> Someone who dislikes C for whatever reasons will probably dislike
>>> most other languages that use curly braces, and not necessarily
>>> because of that one syntactic detail.
>>
>> There may also be just simple practical real-life facts that
>> influence the preferences of languages with curly braces (or
>> brackets). I want to remind that keyboards from other domains
>> may not have the simple access to the [ ] { } characters! On
>> my US keyboard [ and ] are adjacent and directly accessible,
>> and { and } are on the same keys reachable simply with 'Shift'.
>> That's extremely convenient if you're programming C-like syntax!
>> Though on my German keyboard these characters are placed on the
>> top numbers row in one line, ordered as { [ ] }, and reachable
>> only through the 'Alt Gr' key. This is really a pain to type.
>> For _very common characters_ in a fairly common and rich family
>> of programming languages it's an issue [in such non-US domains].
>>
>
> My Norwegian keyboard needs AltGr for {[]}, but I don't find it a burden
> - it's habit, I suppose.
Well, given that I'm using these keyboards since decades I'm
(sort of) "used" to that layout. Nonetheless its "complexity"
I'm feeling as burden; these _standard characters_ are far off
(upper row), non adjacent (with room for typos), and the key
to access them is available just on the right side (as opposed
to the Shift or Ctrl keys, or the useless "Window" key). It's
also practically a burden; my fingers get [literally] twisted
when typing, and the physis of the fingers is strained; at the
moment I'm suffering from aching sinews. The "typing ergonomy"
is extremely reduced when using these characters. For me that
really is (and ever was) a concrete burden, not only a little
nuisance.
>
> But in days gone by if anyone ever needed to use trigraphs for C
> programming, then I am sure they would happily switch to a word-based
> language given half a chance. I find "{ }" nicer than "begin end", but
> I'd pick "begin end" over "??< ??>" any day!
I've never even had considered using trigraphs.
Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-02 19:55 +0200 |
| Message-ID | <20251202195511.00000c89@yahoo.com> |
| In reply to | #395654 |
On Tue, 2 Dec 2025 13:53:48 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 2025-12-02 08:31:53, David Brown wrote:
> > On 01/12/2025 23:59, Janis Papanagnou wrote:
> >> On 2025-12-01 21:06:13, Keith Thompson wrote:
> >>>
> >>> The use of curly braces vs. begin/end is IMHO trivial. [...]
> >>>
> >>> Someone who dislikes C for whatever reasons will probably dislike
> >>> most other languages that use curly braces, and not necessarily
> >>> because of that one syntactic detail.
> >>
> >> There may also be just simple practical real-life facts that
> >> influence the preferences of languages with curly braces (or
> >> brackets). I want to remind that keyboards from other domains
> >> may not have the simple access to the [ ] { } characters! On
> >> my US keyboard [ and ] are adjacent and directly accessible,
> >> and { and } are on the same keys reachable simply with 'Shift'.
> >> That's extremely convenient if you're programming C-like syntax!
> >> Though on my German keyboard these characters are placed on the
> >> top numbers row in one line, ordered as { [ ] }, and reachable
> >> only through the 'Alt Gr' key. This is really a pain to type.
> >> For _very common characters_ in a fairly common and rich family
> >> of programming languages it's an issue [in such non-US domains].
> >>
> >
> > My Norwegian keyboard needs AltGr for {[]}, but I don't find it a
> > burden
> > - it's habit, I suppose.
>
> Well, given that I'm using these keyboards since decades I'm
> (sort of) "used" to that layout. Nonetheless its "complexity"
> I'm feeling as burden; these _standard characters_ are far off
> (upper row), non adjacent (with room for typos), and the key
> to access them is available just on the right side (as opposed
> to the Shift or Ctrl keys, or the useless "Window" key). It's
> also practically a burden; my fingers get [literally] twisted
> when typing, and the physis of the fingers is strained; at the
> moment I'm suffering from aching sinews. The "typing ergonomy"
> is extremely reduced when using these characters. For me that
> really is (and ever was) a concrete burden, not only a little
> nuisance.
>
> >
> > But in days gone by if anyone ever needed to use trigraphs for C
> > programming, then I am sure they would happily switch to a
> > word-based language given half a chance. I find "{ }" nicer than
> > "begin end", but I'd pick "begin end" over "??< ??>" any day!
>
> I've never even had considered using trigraphs.
>
> Janis
>
I never used Western European keyboard, so probably don't understand
something very basic.
Suppose, you use Greek/Latin keyboard (or InScript/Latin, or
Cyrillic/Latin, or Hebrew/Latin, Arabic/Latin, Thai/Latin,
Vietnamese//Latin, etc ...). When you right code, you just switch the
keyboard layout from Greek to English (US) or English (UK). It's easy.
Tens of millions of programmers do it all the time, instinctively.
Why Western Europeans can't do exactly the same? Just because their
native scripts are also Latin-based? To me it does not sound as a
meaningful reason :(
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-12-02 19:37 +0100 |
| Message-ID | <10gnbks$2f6kq$1@dont-email.me> |
| In reply to | #395658 |
On 2025-12-02 18:55, Michael S wrote: > > I never used Western European keyboard, so probably don't understand > something very basic. Yes. (So it's probably useless to discuss that then [with you].) > Suppose, you use Greek/Latin keyboard (or InScript/Latin, or > Cyrillic/Latin, or Hebrew/Latin, Arabic/Latin, Thai/Latin, > Vietnamese//Latin, etc ...). When you right code, you just switch the > keyboard layout from Greek to English (US) or English (UK). It's easy. The switch is [technically] easy. The point is that there's also quite some differences, where keys are largely or only slightly on other positions, both are obvious source of typing mistakes. (I'm certainly not schizophrenic enough to have my muscle memory be able to switch seamlessly.) > Tens of millions of programmers do it all the time, instinctively. (Ah, here we have the "Tens of millions of programmers" again! Is that you, bart? - Ah, no; it's Michael S this time.) Switching layouts while being aware of all the differences then? And having a muscle memory that is capable of acting on the subtle as well as the serious differences? - I seriously doubt that! > Why Western Europeans can't do exactly the same? (Now you're getting on a cultural prejudice (or racist?) track.) > Just because their > native scripts are also Latin-based? To me it does not sound as a > meaningful reason :( I think your initial sentence is the best insight of you to know whether to contribute on that or not. I suggest to you to abstain from it. Thanks. Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-12-02 21:07 +0100 |
| Message-ID | <10gngug$2juli$1@dont-email.me> |
| In reply to | #395658 |
On 02/12/2025 18:55, Michael S wrote: > > I never used Western European keyboard, so probably don't understand > something very basic. Let me try to help you understand - that's why we are here! > Suppose, you use Greek/Latin keyboard (or InScript/Latin, or > Cyrillic/Latin, or Hebrew/Latin, Arabic/Latin, Thai/Latin, > Vietnamese//Latin, etc ...). When you right code, you just switch the > keyboard layout from Greek to English (US) or English (UK). It's easy. > Tens of millions of programmers do it all the time, instinctively. > Why Western Europeans can't do exactly the same? Just because their > native scripts are also Latin-based? To me it does not sound as a > meaningful reason :( (They say that the best way to get an answer on the internet is not by asking questions, but by posting something wrong and waiting for the corrections :-) ) I was initially used to a UK English layout. When I moved to Norway, I learned to use the Norwegian layout. It is the same QWERTY for the common letters, but has punctuation moved around a bit and three keys for the Norwegian letters Æ, Ø and Å as letters. It also has dead keys so that you can get accents and other diacriticals (though these are not much used in Norwegian), and a number of extra symbols use AltGr rather than shift. With Windows, you can directly type several more symbols than with the UK layout - with Linux, you can type a great many more without having to use the compose key or other tools. All in all, it is a far better keyboard layout than the standard UK English (or slightly more limited, the standard US English). It bears more resemblance to the international English layouts. So why on earth would I want to switch to an inferior layout when writing code? The disadvantage - the slightly more awkward brackets, braces and complement operator are certainly not good enough reason to have two sets of muscle memory for different tasks. And what about situations where I want Norwegian letters and also various symbols and punctuation? What would you suggest I use when writing Norwegian LaTeX? Should I switch back and forth depending on whether I want Norwegian letters or brace symbols? People are likely to switch keyboard layouts if they often use a completely different alphabet, but I seriously doubt that many switch from other Latin layouts to US or UK layouts just for coding.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.org> |
|---|---|
| Date | 2025-11-27 08:10 +0000 |
| Message-ID | <slrn10ig1r1.isj.ike@iceland.freeshell.org> |
| In reply to | #395502 |
On 2025-11-26, bart <bc@freeuk.com> wrote:
> In C, the solution for my example might look like this:
>
> double temp = x+y;
> printf("%llu", ((*(uint64_t*)&temp)>>52) & 2047);
>
> Rather more fiddly and error prone, and it needs an auxiliary statement
> that makes it awkward to embed into an expression. (I also had to think
> twice about that format code.)
The ilogb() function from <math.h> extracts the exponent of a double.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-27 01:30 +0000 |
| Message-ID | <10g89kh$hnqd$1@paganini.bofh.team> |
| In reply to | #395494 |
bart <bc@freeuk.com> wrote:
> And yet, integer widths have been roughly capped at double a machine
> word size for decades - until 64 bits came along and then few even
> bothered with double-width.
>
> Nobody thought how easy it would be to just have an integer of whatever
> size you like - you just generate whatever code is necessary to make it
> happen. We could have had BitInts on 32- and even 16-bit machines if
> only somebody had thought of it!
PL/I had things like 'fixed binary(23)' (that is ability to
specify bit size) around 1965, but that stopped at machine
word length. Pascal had range types, but similarly stopped
at at integer size. GNU Pascal allowed specifiying size in
bits and going to twice machine word (that was limitation
imposed by gcc backend).
And yes, such types could be added much earlier and it
is a shame that they are added only now.
This IMHO was classic example of inertia: people needing
larger integers were used to fact that mainstream lower
level languages provided no support, so they used their
own special purpose code. Since apparently programs were
written compiler writers assumed that there is no need for
bigger integer types. As long as no compiler provided
support for bigger integers, no was loosing marked due to
lack of such feature. Fortunately, LLVM added them and
after that competitive pressure led to gcc adding such
types.
Part of reason may be that in nineties usage of other
(than C) lower level languages went down. C was
traditionally quite minimal and did not want new to
introduce new features.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-27 02:18 +0000 |
| Message-ID | <10g8ccs$103r4$1@dont-email.me> |
| In reply to | #395510 |
On 27/11/2025 01:30, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> And yet, integer widths have been roughly capped at double a machine >> word size for decades - until 64 bits came along and then few even >> bothered with double-width. >> >> Nobody thought how easy it would be to just have an integer of whatever >> size you like - you just generate whatever code is necessary to make it >> happen. We could have had BitInts on 32- and even 16-bit machines if >> only somebody had thought of it! > > PL/I had things like 'fixed binary(23)' (that is ability to > specify bit size) around 1965, but that stopped at machine > word length. Pascal had range types, but similarly stopped > at at integer size. What were the reasons for PL/I to use odd sizes not related to word size or memory width? > GNU Pascal allowed specifiying size in > bits and going to twice machine word (that was limitation > imposed by gcc backend). Before 64-bits, we needed double the word size in order to represent ordinary quantities. With 64 bits, there is much less need (hence few 128-bit types). > And yes, such types could be added much earlier and it > is a shame that they are added only now. So what is the pressing need now? It is a mild convenience for those applications which really need numbers of 100s of bits, but not what I would have thought were worth making special provision for in a language. While they would be unwieldy for very much larger numbers, and in any case there are caps in place. I can see some use when you want a block datatype or so many bytes (sorry, bits, since it needs to be bit-precise even at the large scale), especially if some bitwise ops are available. Eg. do some of the things that Pascal bit-sets were used for, but there's still seems to be lots of support lacking. So it still appears to me a rather heavyweight feature, in a lightweight language, that is lacking in everyday use-cases. > Part of reason may be that in nineties usage of other > (than C) lower level languages went down. C was > traditionally quite minimal and did not want new to > introduce new features.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-27 04:12 +0000 |
| Message-ID | <10g8j3e$icu3$1@paganini.bofh.team> |
| In reply to | #395511 |
bart <bc@freeuk.com> wrote:
> On 27/11/2025 01:30, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>>> And yet, integer widths have been roughly capped at double a machine
>>> word size for decades - until 64 bits came along and then few even
>>> bothered with double-width.
>>>
>>> Nobody thought how easy it would be to just have an integer of whatever
>>> size you like - you just generate whatever code is necessary to make it
>>> happen. We could have had BitInts on 32- and even 16-bit machines if
>>> only somebody had thought of it!
>>
>> PL/I had things like 'fixed binary(23)' (that is ability to
>> specify bit size) around 1965, but that stopped at machine
>> word length. Pascal had range types, but similarly stopped
>> at at integer size.
>
> What were the reasons for PL/I to use odd sizes not related to word size
> or memory width?
One reason probably was theoritical elegance: program should say
how many bits _it_ needed, not how many bits computer has.
PL/I allowed such types as part of data structures, so they worked
as C bit fields. With restriction on number of bits they would
need separate construct for bit fields.
Also, note that at that time IBM introduced 32-bit machines, but
also had older 36-bit ones. Other manufacturers had 18-bit,
24-bit and 60-bit machines. IBM wanted to ease convertion from
such machines. I am not sure if they cared, but their definition
made possible implementing PL/I on such machines. For example
GE implemented PL/I for their 36-bit machines.
BTW: I think that overflow in PL/I is an error (optionally
causing exception) so there is no need to implement wraparound.
>> GNU Pascal allowed specifiying size in
>> bits and going to twice machine word (that was limitation
>> imposed by gcc backend).
>
> Before 64-bits, we needed double the word size in order to represent
> ordinary quantities. With 64 bits, there is much less need (hence few
> 128-bit types).
Less need, but it does not vanish.
>> And yes, such types could be added much earlier and it
>> is a shame that they are added only now.
>
> So what is the pressing need now?
>
> It is a mild convenience for those applications which really need
> numbers of 100s of bits, but not what I would have thought were worth
> making special provision for in a language.
>
> While they would be unwieldy for very much larger numbers, and in any
> case there are caps in place.
"worth" is subjective. Simple implementation of largish numbers
(say Turbo Pascal quality) is not that complictated, basically
allocation of variables, assignment and similar are handled by
general code needed for other things. So only arithmetic need
special implementation. Here you need to generate inline code
for few small cases and runtime calls for other things. Note
that compiler knows its runtime so could use special calling
convention so that calls are slightly cheaper than calls to
user-defined routines.
Multiple precision computations have at least one obvious use:
to verify correctness of computations at given precision
simplest approach uses higher precision. This is not big
use, but valuable to developers, saving them effort to
create their own multiple precision routines.
IIUC in seventies Lisp implementations converged on supporting
arbitrary precision integers. Lisp is garbage collected, so
in a sense Lisp users already "payed" for cost of dynamic
allocation so arbitrary precision is reasonably natural.
But one can also declare bit size (say 1159 bits) or
ranges and theoreticaly compiler can use this information
for optimization. In lower level language one wants to avoid
dynamic allocation, so fixed size types are more natural.
I would say that if you are used to limited languages, then
you can cope reasonably well. But availability of largish
integers makes some things easier. Now I certainly do not
want to go back to using only languages which do not support
them. For me support for larger numbers in Clang and gcc is
really good news (reading standard suggested that compilers
may put upper limit quite low).
> I can see some use when you want a block datatype or so many bytes
> (sorry, bits, since it needs to be bit-precise even at the large scale),
> especially if some bitwise ops are available.
>
> Eg. do some of the things that Pascal bit-sets were used for, but
> there's still seems to be lots of support lacking.
>
> So it still appears to me a rather heavyweight feature, in a lightweight
> language, that is lacking in everyday use-cases.
IIUC is is light in a sense that compiler is not obliged to support
bigger integers than it already supported. So the only new thing is
masking for unsigned types of strange sizes. Gain is that
on 8-bit processors (still important in embedded area) users
can now request 8-bit type and get all computaions in 8 bits
(without useless promotion to 16 bits mandated for older types).
>> Part of reason may be that in nineties usage of other
>> (than C) lower level languages went down. C was
>> traditionally quite minimal and did not want new to
>> introduce new features.
>
>
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-11-29 20:24 +0000 |
| Message-ID | <10gfkqd$19n2d$1@paganini.bofh.team> |
| In reply to | #395436 |
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.
Second, C has standard process and each proposal must go trough
this process. It is much easier to standarize one simple general
frature (like _BitInt) than a bunch of separate proposals.
Also, note that 64 bits is maximum guaranteed by the standard.
If stanard mandated presence of say 'int128_t' that could cause
opposiotion from some influential parties (like a rich company
in north-west USA). Optional 'int128_t' and 'uint128_t' adds little
value.
'_BitInt' is a simple interface, for example 'intnnn_t' for
some 'nnn' would add multiple slots in compiler symbol table
or need multiple entries in header files. '_BitInt' is a single
identifier.
_BitInt(8) makes a lot of sense for 8-bit processors. The
requirement for number of bits not divisible by 8 came from
requiremnt of portablity to FPGA, where hardware may use
odd width.
Even if you limit attention to mainstream hardware, 32-bit
machines are still popular enough so that C must support
them. So specifying size as multiple of 64 bits would
be unacceptable. Specifying size as multiple of 32 bits
would be unnatural too. You may think that specifying
size in bytes is natural, but clearly for efficiency
implementation my wish to round up size. So, why not
specify size with maximal possible resolution, that is
in bits?
BTW: you complained that C has many identifiers naming
integer types. Now C has uniform way to form names of
integer types that covers most needs for fixed size
integer types (sometimes you may wish promotion to
integer, so 'int8_t', 'int16_t' and possibly 'int32_t'
and usigned variants still may be preferable). So now
you complian that this scheme is too flexible and
C should use separate names...
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-29 22:58 +0000 |
| Message-ID | <10gftqi$3qhkg$1@dont-email.me> |
| In reply to | #395574 |
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 can have general _BitInt(N) syntax and have constraints on the values of N, not just an upper limit. > > Second, C has standard process and each proposal must go trough > this process. It is much easier to standarize one simple general > frature (like _BitInt) than a bunch of separate proposals. > Also, note that 64 bits is maximum guaranteed by the standard. > If stanard mandated presence of say 'int128_t' that could cause > opposiotion from some influential parties (like a rich company > in north-west USA). Optional 'int128_t' and 'uint128_t' adds little > value. > > '_BitInt' is a simple interface, for example 'intnnn_t' for > some 'nnn' would add multiple slots in compiler symbol table > or need multiple entries in header files. '_BitInt' is a single > identifier. I think that's how it works in Zig; i1234 is a valid integer type. It can be done without defining all such type names up to maximum N. However, I would have suggested a syntax like int(N), but I suspect it clashes with something in C. > _BitInt(8) makes a lot of sense for 8-bit processors. The > requirement for number of bits not divisible by 8 came from > requiremnt of portablity to FPGA, where hardware may use > odd width. Wouldn't 'char' have a different width there anyway? Or can it be even odder where char is 7 bits and int is 19? > Even if you limit attention to mainstream hardware, 32-bit > machines are still popular enough so that C must support > them. So specifying size as multiple of 64 bits would > be unacceptable. Specifying size as multiple of 32 bits > would be unnatural too. You may think that specifying > size in bytes is natural, but clearly for efficiency > implementation my wish to round up size. So, why not > specify size with maximal possible resolution, that is > in bits? But it means the possibility of silly or misguided sizes, or even unintended ones where someone makes a typo in N and the compiler says nothing because anything goes. To me it makes sense to have N doubling, at least until some limit, then increasing by word size. Below 64 bits, non-power-of-two sizes don't seem that meaningful to me outside of special contexts like the members of a struct, and there, there are other means to do that. > BTW: you complained that C has many identifiers naming > integer types. Now C has uniform way to form names of > integer types that covers most needs for fixed size > integer types (sometimes you may wish promotion to > integer, so 'int8_t', 'int16_t' and possibly 'int32_t' > and usigned variants still may be preferable). So now > you complian that this scheme is too flexible and > C should use separate names... It's like that XCD cartoon where 14 standards end up as 15. Apparently _BitInt(8) is incompatible with int8_t. Yes, C type denotations were a mess, and this doesn't help. Also, some emphasis has been put in this thread about odd and/or large BitInt sizes not necessarily being a single numeric value. Yet _BitInt is signed, and you have to do 'unsigned _BitInt' to get the kind of type that may represent non-numeric data. (In my PL designs, a type with 'int' in it, or of the form 'iN', is a always a signed integer. Anything else, say with 'word byte bit long', or of the form 'uN', is unsigned or non-numeric. I've also played with using N, as either a byte or bit count: int*4 i32 int:32 i32 byte*4 u32 byte:32 u32 While any N could be typed, only supported sizes were accepted. But this was only intended up to word or double-word size. Now I support only the forms in that right column, plus 'int word byte' which are 'i64 u64 u8'.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-11-29 16:46 -0800 |
| Message-ID | <87sedw9wjh.fsf@example.invalid> |
| In reply to | #395581 |
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 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?
[...]
>> _BitInt(8) makes a lot of sense for 8-bit processors. The
>> requirement for number of bits not divisible by 8 came from
>> requiremnt of portablity to FPGA, where hardware may use
>> odd width.
>
> Wouldn't 'char' have a different width there anyway? Or can it be even
> odder where char is 7 bits and int is 19?
char is at least 8 bits wide, and the size of int must be a multiple of
CHAR_BIT (though its width needn't be if there are padding bits).
I don't know about C implementations for FPGAs, but I presume they
still obey the rules of the language.
[...]
> 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? They're both scalar types, so
they're implicitly converted when needed.
[...]
--
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-30 02:30 +0000 |
| Message-ID | <10gga8k$3v646$1@dont-email.me> |
| In reply to | #395585 |
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. Everyone in this group seems obsessed with not having any limitations at all in the language. 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). 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! >> 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? It what way would it inconvenience /you/? 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. > [...] > >>> _BitInt(8) makes a lot of sense for 8-bit processors. The >>> requirement for number of bits not divisible by 8 came from >>> requiremnt of portablity to FPGA, where hardware may use >>> odd width. >> >> Wouldn't 'char' have a different width there anyway? Or can it be even >> odder where char is 7 bits and int is 19? > > char is at least 8 bits wide, and the size of int must be a multiple of > CHAR_BIT (though its width needn't be if there are padding bits). > I don't know about C implementations for FPGAs, but I presume they > still obey the rules of the language. > > [...] > >> 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? When 'char' is signed, that means that a signed 8-bit type on PCs can chosen amongst four incompatible types! > They're both scalar types, so > they're implicitly converted when needed. > [...] >
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-11-30 05:31 +0100 |
| Message-ID | <10gghbg$3htol$4@dont-email.me> |
| In reply to | #395589 |
On 2025-11-30 03:30:42, bart wrote: > On 30/11/2025 00:46, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >>> 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? Not sure whether you're talking at cross-purposes. (I haven't followed all postings or details.) If, on a 64-bit-word system, _BitInt(80) would produce an error (because it "had to be multiples of the word sizes", as you say), that would obviously be a problem, don't you think? If all you want to express is that the underlying "transfer syntax" (the memory to store those values) may cover a larger memory range, one that may exceed the size [needed by the programmer] to the next byte or word boundary, I wouldn't see a problem. (I'd actually even expect that the [low-level] implementation range be something that's supported by the system.) (Care must in any case be taken in the definition of that feature for memory accesses outside the defined bounds. - Don't know what "C" defines here.) > > It what way would it inconvenience /you/? If I couldn't define _BitInt(80) I'd indeed consider that a problem. Or any other constant value that stems from my application domain. > > 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. You mean you have problems with, say, "char a[81]" as well? > > So I'm interested in what that one extra bit in a million buys you. Or > that one bit fewer. It's not about extra bits. It's about making it possible to define what your tasks (that are to be implemented) ask for. (In my book. YMMV.) What actual problems you have (or could imagine) with that? Janis >> [...]
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-30 12:51 +0000 |
| Message-ID | <10gheka$bgvr$1@dont-email.me> |
| In reply to | #395593 |
On 30/11/2025 04:31, Janis Papanagnou wrote: > On 2025-11-30 03:30:42, bart wrote: >> On 30/11/2025 00:46, Keith Thompson wrote: >>> bart <bc@freeuk.com> writes: >>>> 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? > > Not sure whether you're talking at cross-purposes. (I haven't > followed all postings or details.) > > If, on a 64-bit-word system, _BitInt(80) would produce an error > (because it "had to be multiples of the word sizes", as you say), > that would obviously be a problem, don't you think? How did you represent an 80-bit type up to now? How much of a problem has it actually been? >> It what way would it inconvenience /you/? > > If I couldn't define _BitInt(80) I'd indeed consider that a problem. > Or any other constant value that stems from my application domain. Which domain is that, is it representing, as an integer, the 80-bit float type from an x87 FPU? > >> >> 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. > > You mean you have problems with, say, "char a[81]" as well? If the feature was about bit-arrays, then I agree that any arbitrary size must be meaningful, within broad limits. But _BitInt(N), especially without the 'unsigned' prefixed that I've rarely seen used in the examples in this thread, has been heavily pushed as a numeric type. Each extra bit doubles the range of values it can represent. The user cares only that N is sufficient to represent that data, so a few surplus bits are neither here nor there: the N itself is not critical. With char[N], there is also char[] which, in the form of 'char*' or 'char(*)[]' with an accompanying N, can be used to create functions that can work with such arrays of any length. You can also individually index any individual element (or create a pointer to any element). Neither of these possibilities exist for BitInt(N). So it's a feature that does neither one thing well nor the other. With char[] also, element 0 is always at the lower memory address. I don't think endianess has been mentioned for BitInt, so I don't know where large multi-word BitInts have the least significant word on big-endian systems. (BTW my second language has actual bit-arrays and Pascal-style bit-sets. Both features could be usefully added to a systems language in fixed-size form, but would have the same capabilities as the char[] example above, plus more.) >> >> So I'm interested in what that one extra bit in a million buys you. Or >> that one bit fewer. > > It's not about extra bits. It's about making it possible to define > what your tasks (that are to be implemented) ask for. (In my book. > YMMV.) 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! I think there's more psychology at play here than anything else.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-11-30 18:17 +0100 |
| Message-ID | <10ghu7d$3htol$5@dont-email.me> |
| In reply to | #395609 |
On 2025-11-30 13:51:22, bart wrote:
> On 30/11/2025 04:31, Janis Papanagnou wrote:
>> On 2025-11-30 03:30:42, bart wrote:
>>> On 30/11/2025 00:46, Keith Thompson wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>> 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?
>>
>> Not sure whether you're talking at cross-purposes. (I haven't
>> followed all postings or details.)
>>
>> If, on a 64-bit-word system, _BitInt(80) would produce an error
>> (because it "had to be multiples of the word sizes", as you say),
>> that would obviously be a problem, don't you think?
>
> How did you represent an 80-bit type up to now? How much of a problem
> has it actually been?
I had to use workarounds and/or more effort to achieve what I intended.
For the implementation I have to think in terms of technical entities
unnecessarily, and not in [more natural] application domain entities.
>
>>> It what way would it inconvenience /you/?
>>
>> If I couldn't define _BitInt(80) I'd indeed consider that a problem.
>> Or any other constant value that stems from my application domain.
>
> Which domain is that, is it representing, as an integer, the 80-bit
> float type from an x87 FPU?
That was an arbitrary number. (Other posters provided extensive lists
of other numbers already, based on application domain requirements.)
I could provide even more "crude" numbers, say, like _BitInt(17), to
operate on coefficients of generator polynomials, just for example.
The point is not to discuss any specific number. - The point is that
they are bound to the application domain and express a sensible (not
artificial, defined by technical CPU word-sizes) counterpart of the
[application domain] items you work on.
Programming is about implementing solutions to application problems.
It's not primarily about focusing how the hardware looks like. There
are abstracting formal programming languages (and the compilers) that
shall bridge that gap as good as possible. (To be clear; "C" hadn't
been a good paragon concerning that abstraction capability.) We're
using computers primarily to work on real-world tasks (not to engage
existing hardware with work of any sort).
The fact that you obviously don't see that, and also don't understand
it after pointing that out, in addition with your squirming to *not*
*answer* the repeatedly formulated question what your actual problem
with it is, that all shows that you are obviously not willing to be a
serious discussion partner.
>
>>>
>>> So I'm interested in what that one extra bit in a million buys you.
>>> Or that one bit fewer.
>>
>> It's not about extra bits. It's about making it possible to define
>> what your tasks (that are to be implemented) ask for. (In my book.
>> YMMV.)
>
> 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!
You are again talking nonsense and exposing your non-sincere moves
to stupidly exaggerate ("screaming") and unreasonable generalize
("EVERYONE"). - Yet, you prove again that you are not willing to
be a serious discussion partner.
>
> I think there's more psychology at play here than anything else.
It's okay to have opinions. - If that's all you want to share, your
opinions and personal preferences, that's okay.
But it's not okay to strip, repeatedly ignore, and not answer the
basic repeatedly asked question:
>> What actual problems you have (or could imagine) with that?
Why are you so stubbornly refusing to answer that? - I'll tell you;
because it would expose that you have nothing to contribute but an
isolated opinion from your extremely restricted bubble of thinking.
You have a chance to answer now!
(Or will you instead yet again complain about the personal attacks?)
Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-11-30 17:55 +0000 |
| Message-ID | <10gi0ep$i4fi$1@dont-email.me> |
| In reply to | #395616 |
On 30/11/2025 17:17, Janis Papanagnou wrote:
> On 2025-11-30 13:51:22, bart wrote:
>> How did you represent an 80-bit type up to now? How much of a problem
>> has it actually been?
>
> I had to use workarounds and/or more effort to achieve what I intended.
> For the implementation I have to think in terms of technical entities
> unnecessarily, and not in [more natural] application domain entities.
How much storage did your type take up in the end?
Because if you expect it to occupy only 10 bytes, you might be
disappointed with _BitInts:
_BitInt(80) A;
_BitInt(80) B[10];
printf("%zu\n", sizeof(A));
printf("%zu\n", sizeof(B));
This shows 16 bytes for A (the same as for _BitInt(128)), and 160 bytes
for B.
So here need to ask questions about why you need 80 bits and not 128.
>> Which domain is that, is it representing, as an integer, the 80-bit
>> float type from an x87 FPU?
>
> That was an arbitrary number.
An arbitrary number that can represents values up to some exact power of
two.
> (Other posters provided extensive lists
> of other numbers already, based on application domain requirements.)
I've also given examples where the desire is to store numbers up to some
arbitrary value that is not of the form 2**N-1. It is also possible
numbers are in some arbitrary range that does not start at 2**N or 0 for
signed/unsigned.
BitInt won't help here.
> I could provide even more "crude" numbers, say, like _BitInt(17), to
> operate on coefficients of generator polynomials, just for example.
> The point is not to discuss any specific number. - The point is that
> they are bound to the application domain and express a sensible (not
> artificial, defined by technical CPU word-sizes) counterpart of the
> [application domain] items you work on.
>
> Programming is about implementing solutions to application problems.
> It's not primarily about focusing how the hardware looks like.
BitInt is still hardware-based (what do you think a 'bit' is?!).
And implementations appear to have hardware-based limits and compromises.
> The fact that you obviously don't see that, and also don't understand
> it after pointing that out, in addition with your squirming to *not*
> *answer* the repeatedly formulated question what your actual problem
> with it is,
I've said many times that it's a poorly designed feature. Read the
thread, as I'm not going to repeat things.
>> 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!
>
> You are again talking nonsense and exposing your non-sincere moves
> to stupidly exaggerate ("screaming") and unreasonable generalize
> ("EVERYONE"). - Yet, you prove again that you are not willing to
> be a serious discussion partner.
Yet what I said is pretty much true. Nobody care about BitInt until they
became aware of, and now it's must-have.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-12-01 00:08 +0000 |
| Message-ID | <10gima4$1k84u$2@paganini.bofh.team> |
| In reply to | #395617 |
bart <bc@freeuk.com> wrote:
>
> Yet what I said is pretty much true. Nobody care about BitInt until they
> became aware of, and now it's must-have.
Well, you were told many times that regulars here know deficiencies
of C. "Nobody care about BitInt" in the sense that before _BitInt
people will say "this can not be expressed directly in C, you need
such and such workaround". People did not loudly complain
knowing that complaints would achive nothing. But say doing
language comparisons they could note that C lack such a feature.
There is also a psychological phenomenon: computers even in crude
form are quite useful. So people were willing to jump hops to
use them. But when better/easier approach is available people
wery strongly resist going to old ways. So, once w got _BitInt
you will not be able to take it back.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-12-01 01:14 +0000 |
| Message-ID | <10giq57$rn96$1@dont-email.me> |
| In reply to | #395619 |
On 01/12/2025 00:08, Waldek Hebisch wrote: > bart <bc@freeuk.com> wrote: >> >> Yet what I said is pretty much true. Nobody care about BitInt until they >> became aware of, and now it's must-have. > > Well, you were told many times that regulars here know deficiencies > of C. "Nobody care about BitInt" in the sense that before _BitInt > people will say "this can not be expressed directly in C, you need > such and such workaround". People did not loudly complain > knowing that complaints would achive nothing. But say doing > language comparisons they could note that C lack such a feature. > > There is also a psychological phenomenon: computers even in crude > form are quite useful. So people were willing to jump hops to > use them. But when better/easier approach is available people > wery strongly resist going to old ways. So, once w got _BitInt > you will not be able to take it back. I've been claiming that _BitInt was a poor fit for a language at the level of C which lacks some more fundamental features. But I think I was wrong: the way _BitInt has been devised and presented is actually completely in line with the haphazard way C has evolved up to now. I made the mistake in this thread of thinking that people cared about measured language design; obviously if they're using C, they don't. unsigned char* p; uint8_t* q; // only exists when stdint.h used unsigned _BitInt(8)* r; char* s; p and q are probably compatible. p and r are not; q and r and not. s is incompatible with p, q, r even if it is unsigned.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-12-01 04:10 +0000 |
| Message-ID | <10gj4g5$1q8vh$1@paganini.bofh.team> |
| In reply to | #395620 |
bart <bc@freeuk.com> wrote:
> On 01/12/2025 00:08, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>>>
>>> Yet what I said is pretty much true. Nobody care about BitInt until they
>>> became aware of, and now it's must-have.
>>
>> Well, you were told many times that regulars here know deficiencies
>> of C. "Nobody care about BitInt" in the sense that before _BitInt
>> people will say "this can not be expressed directly in C, you need
>> such and such workaround". People did not loudly complain
>> knowing that complaints would achive nothing. But say doing
>> language comparisons they could note that C lack such a feature.
>>
>> There is also a psychological phenomenon: computers even in crude
>> form are quite useful. So people were willing to jump hops to
>> use them. But when better/easier approach is available people
>> wery strongly resist going to old ways. So, once w got _BitInt
>> you will not be able to take it back.
>
>
> I've been claiming that _BitInt was a poor fit for a language at the
> level of C which lacks some more fundamental features.
>
> But I think I was wrong: the way _BitInt has been devised and presented
> is actually completely in line with the haphazard way C has evolved up
> to now.
>
> I made the mistake in this thread of thinking that people cared about
> measured language design; obviously if they're using C, they don't.
>
> unsigned char* p;
> uint8_t* q; // only exists when stdint.h used
> unsigned _BitInt(8)* r;
> char* s;
>
> p and q are probably compatible. p and r are not; q and r and not. s is
> incompatible with p, q, r even if it is unsigned.
Do you understand that uint8_t and _BitInt(8) are different types?
And the difference is not an accident, but they have different
properties (uint8_t in expressions promotes to int, _BitInt(8)
is not subject to this promotion). AFAICS unsigned char and
uint8_t may be (and usually probably are) the same type.
Compatibiliy (or not) for pointers is just consequence of this.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web