Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #400344 > unrolled thread
| Started by | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| First post | 2026-07-22 01:38 +0200 |
| Last post | 2026-07-23 11:18 +0200 |
| Articles | 20 on this page of 183 — 20 participants |
Back to article view | Back to comp.lang.c
Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-22 01:38 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-21 17:26 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-22 01:50 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-21 20:25 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-22 17:37 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-22 13:26 -0700
Re: Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-22 07:33 +0200
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-22 10:41 +0200
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-22 18:08 -0500
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-23 10:31 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 14:31 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 14:48 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 15:11 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-24 09:23 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-24 03:14 -0700
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-07-24 14:56 +0000
Re: Prioritize Performance over Correctness antispam@fricas.org (Waldek Hebisch) - 2026-07-25 16:30 +0000
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-27 09:33 -0400
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 00:22 +0800
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 12:58 -0700
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-27 15:37 -0500
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-27 17:13 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 15:17 -0700
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-07-28 01:18 +0000
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 15:40 +0800
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:18 +0000
Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 22:48 +0800
Re: Multics( Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-07-28 15:08 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 23:30 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 19:08 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:08 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:15 +0000
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:26 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 06:41 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 23:23 +0000
Picture of Organicks' book Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 16:01 +0800
Re: Picture of Organicks' book cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-29 13:46 +0000
Re: Picture of Organicks' book R Kym Horsell <kymhorsell@gmail.com> - 2026-07-29 16:54 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Cóilín Nioclásín Glostéir <thanks-to@Taf.com> - 2026-07-29 23:22 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 15:55 -0700
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 18:58 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:10 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:20 +0000
Re: Multics( Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-07-29 14:44 +0000
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-30 02:08 +0000
Re: Prioritize Performance over Correctness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-16 07:59 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 17:59 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 15:42 +0800
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 03:22 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 19:21 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-28 13:02 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 20:18 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-28 14:17 +0100
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-28 16:02 -0500
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 16:45 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 12:03 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 19:32 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 13:42 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 20:49 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 16:01 +0100
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-29 12:53 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-31 14:21 -0400
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-31 20:07 +0100
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-31 13:00 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-01 02:34 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 16:08 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 23:28 +0000
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:22 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-28 13:51 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:32 -0400
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:20 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-28 13:54 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 05:00 +0800
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:25 -0400
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 14:55 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:31 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 21:26 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 14:57 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-29 15:33 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 16:22 -0700
Re: Prioritize Performance over Correctness Richard Harnden <richard.nospam@gmail.invalid> - 2026-07-30 07:40 +0100
Re: Prioritize Correctness over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 06:48 +0000
Re: Prioritize Correctness over Performance James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 06:50 -0400
Re: Prioritize Correctness over Performance Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 03:54 -0700
Re: Prioritize Correctness over Performance James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 08:24 -0400
Re: Prioritize Correctness over Performance Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 14:40 -0700
Re: Prioritize Correctness over Performance "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:39 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 06:44 -0400
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 21:00 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 14:38 -0700
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 21:53 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 15:10 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:40 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-31 02:43 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:44 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:58 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-01 01:25 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-02 23:14 +0200
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-02 14:37 -0700
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-02 22:51 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-02 16:43 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 12:03 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-03 23:49 +0000
Re: Prioritize Correctness Over Performance "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 19:35 -0700
MS-DOS memory models (was: Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 08:08 +0800
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 10:16 +0200
Re: Prioritize Performance over Correctness Richard Harnden <richard.nospam@gmail.invalid> - 2026-08-03 10:41 +0100
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 12:28 +0200
Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 19:23 +0800
Re: Malicious Computer Architecture David Brown <david.brown@hesbynett.no> - 2026-08-03 14:01 +0200
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 22:52 +0800
Re: Malicious Computer Architecture David Brown <david.brown@hesbynett.no> - 2026-08-03 19:41 +0200
Re: Malicious Computer Architecture "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:13 -0700
Re: Malicious Computer Architecture "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:10 -0700
Re: Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-08-03 14:29 +0000
Johnny Depp prevention [Windows 11 etc...] (Was: Malicious Computer Architecture) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:10 +0200
But how can you deploy. when its ROM? (Was: Johnny Depp prevention [Windows 11 etc...]) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:15 +0200
GPU Elasticity: Collective Communications Libraries (Was: But how can you deploy. when its ROM?) Mild Shock <janburse@fastmail.fm> - 2026-08-07 14:37 +0200
What are Flits and Phits? [Network on a Chip] (Re: GPU Elasticity: Collective Communications Libraries) Mild Shock <janburse@fastmail.fm> - 2026-08-07 18:07 +0200
Cristallina: Thank you for the Beam (Re: What are Flits and Phits? [Network on a Chip]) Mild Shock <janburse@fastmail.fm> - 2026-08-09 21:22 +0200
Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:26 +0200
How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:50 +0200
Re: How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:24 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:21 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Aidan Kehoe <kehoea@parhasard.net> - 2026-08-18 21:13 +0100
The Mac Neo is a Budget Monster [GPU Channels] (Re: What are Flits and Phits? [Network on a Chip]) Mild Shock <janburse@fastmail.fm> - 2026-08-11 16:27 +0200
The luminaries of duct-tape engineering [Sweeney and Torvald] (Was: The Mac Neo is a Budget Monster [GPU Channels]) Mild Shock <janburse@fastmail.fm> - 2026-08-11 16:51 +0200
Re: Malicious Computer Architecture Aidan Kehoe <kehoea@parhasard.net> - 2026-08-03 19:51 +0100
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 00:22 +0800
Re: Malicious Computer Architecture Richard Harnden <richard.nospam@gmail.invalid> - 2026-08-04 19:10 +0100
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 03:21 +0800
Re: Malicious Computer Architecture Kaz Kylheku <046-301-5902@kylheku.com> - 2026-08-06 21:55 +0000
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-07 06:31 +0800
Re: Malicious Computer Architecture Aidan Kehoe <kehoea@parhasard.net> - 2026-08-06 23:01 +0100
A Case for Impurity: The Applied Pi Calculus (Re: Malicious Computer Architecture) Mild Shock <janburse@fastmail.fm> - 2026-08-04 14:58 +0200
The Sandcastle of Paul Taraus Interactors (Re: A Case for Impurity: The Applied Pi Calculus) Mild Shock <janburse@fastmail.fm> - 2026-08-04 15:10 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-03 05:34 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:04 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-04 00:52 +0000
Re: Prioritize Correctness Over Performance scott@slp53.sl.home (Scott Lurndal) - 2026-08-04 14:22 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-03 05:25 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 15:10 +0200
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:16 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-08-03 20:29 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-03 17:55 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-04 09:12 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-02 19:01 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-03 19:59 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 03:50 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 15:09 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 08:14 +0800
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 05:54 +0800
Re: Prioritize Performance over Correctness steveo@panix.com (Steven M. O'Neill) - 2026-07-31 20:34 +0000
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 19:40 -0400
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-27 15:36 -0500
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:56 +0800
Re: Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-24 14:47 +0200
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-24 16:27 +0200
Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 00:52 +0800
Re: Resources for Amateur Compiler Writers bart <bc@freeuk.com> - 2026-07-24 23:08 +0100
Re: Resources for Amateur Compiler Writers BGB <cr88192@gmail.com> - 2026-07-24 18:50 -0500
Re: Resources for Amateur Compiler Writers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-25 01:54 +0000
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 15:20 +0800
Re: Resources for Amateur Compiler Writers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-25 07:24 +0000
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 15:30 +0800
Re: Resources for Amateur Compiler Writers David Brown <david.brown@hesbynett.no> - 2026-07-25 10:37 +0200
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-27 00:35 +0800
Re: Resources for Amateur Compiler Writers BGB <cr88192@gmail.com> - 2026-07-26 12:39 -0500
Re: Resources for Amateur Compiler Writers bart <bc@freeuk.com> - 2026-07-26 22:27 +0100
Re: Resources for Amateur Compiler Writers BGB <cr88192@gmail.com> - 2026-07-26 18:02 -0500
Re: Resources for Amateur Compiler Writers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-25 22:32 +0000
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-25 15:58 -0700
Re: Resources for Amateur Compiler Writers David Brown <david.brown@hesbynett.no> - 2026-07-25 10:23 +0200
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-24 16:29 -0700
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 15:25 +0800
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-25 15:33 -0700
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-27 00:38 +0800
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-26 17:06 -0700
Re: Resources for Amateur Compiler Writers Cóilín Nioclásín Glostéir <thanks-to@Taf.com> - 2026-07-26 17:03 +0000
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-24 16:50 -0500
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-24 16:13 -0700
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-26 15:26 -0500
Re: Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-23 11:18 +0200
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-03 05:25 -0700 |
| Message-ID | <114q1cb$1a0sa$1@kst.eternal-september.org> |
| In reply to | #400734 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> First, if the implementation does not support an integer type big
> enough to hold a void*, then the type "uintptr_t" will not exist in
> <stdint.h>. I don't know of any such platforms, but if one is made,
> then a hard compile-time error is far better than hidden problems.
>
> Secondly, assuming the type exists, it is the ideal size for the job.
Almost certainly, but that's not guaranteed by the standard.
The requirement is that converting a void* to [u]intptr_t and back
again yields a result that compares equal to the original pointer.
A conforming implementation could have 32-bit pointers and 64-bit
[u]intptr_t, even of 32-bit integer types are available. I can't
think of a good reason for an implementation to do that.
> So always use "const uintptr_t address = (uintptr_t) pointer;", rather
> than using "unsigned long" or other guessed type that will be
> appropriate on some targets and not others.
But first think carefully whether storing pointer values in integer
objects is really an appropriate thing to do. Sometimes it is,
but I've seen code that did so needlessly and incorrectly.
Let pointers be pointers (unless there's a specific reason not to).
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-03 15:10 +0200 |
| Message-ID | <114q3vl$1am6d$1@dont-email.me> |
| In reply to | #400740 |
On 03/08/2026 14:25, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> First, if the implementation does not support an integer type big
>> enough to hold a void*, then the type "uintptr_t" will not exist in
>> <stdint.h>. I don't know of any such platforms, but if one is made,
>> then a hard compile-time error is far better than hidden problems.
>>
>> Secondly, assuming the type exists, it is the ideal size for the job.
>
> Almost certainly, but that's not guaranteed by the standard.
>
That's true, of course - but it would be a strange implementation that
did not use the "best" size for the job. ("Best" does not necessarily
mean "smallest".) Theoretically, there may be tradeoffs and no single
"ideal" size here. In practice, however, it would be very unlikely that
there will be a more efficient type than "uintptr_t" for the task of
holding the results of converting a pointer to an integer type.
> The requirement is that converting a void* to [u]intptr_t and back
> again yields a result that compares equal to the original pointer.
>
> A conforming implementation could have 32-bit pointers and 64-bit
> [u]intptr_t, even of 32-bit integer types are available. I can't
> think of a good reason for an implementation to do that.
>
It would have been a reasonable choice for the x32 ABI (where pointers
are 32 bit, but otherwise 64-bit instructions are generated). After
all, for normal x86-64, uint_fast32_t is 64-bit. But AFAIK x32 has
32-bit uintptr_t.
>> So always use "const uintptr_t address = (uintptr_t) pointer;", rather
>> than using "unsigned long" or other guessed type that will be
>> appropriate on some targets and not others.
>
> But first think carefully whether storing pointer values in integer
> objects is really an appropriate thing to do. Sometimes it is,
> but I've seen code that did so needlessly and incorrectly.
>
> Let pointers be pointers (unless there's a specific reason not to).
>
Agreed entirely.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-03 13:16 -0700 |
| Message-ID | <114qsuf$1k97b$3@dont-email.me> |
| In reply to | #400740 |
On 8/3/2026 5:25 AM, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> First, if the implementation does not support an integer type big >> enough to hold a void*, then the type "uintptr_t" will not exist in >> <stdint.h>. I don't know of any such platforms, but if one is made, >> then a hard compile-time error is far better than hidden problems. >> >> Secondly, assuming the type exists, it is the ideal size for the job. > > Almost certainly, but that's not guaranteed by the standard. > > The requirement is that converting a void* to [u]intptr_t and back > again yields a result that compares equal to the original pointer. > > A conforming implementation could have 32-bit pointers and 64-bit > [u]intptr_t, even of 32-bit integer types are available. I can't > think of a good reason for an implementation to do that. > >> So always use "const uintptr_t address = (uintptr_t) pointer;", rather >> than using "unsigned long" or other guessed type that will be >> appropriate on some targets and not others. > > But first think carefully whether storing pointer values in integer > objects is really an appropriate thing to do. Sometimes it is, > but I've seen code that did so needlessly and incorrectly. Fwiw, its generally useful for lock/wait free algorithms. > > Let pointers be pointers (unless there's a specific reason not to). > > [...] >
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-08-03 20:29 -0400 |
| Message-ID | <114rbq0$1op2s$1@dont-email.me> |
| In reply to | #400686 |
On 01/08/2026 10:25, Chris M. Thomasson wrote: > On 7/30/2026 7:44 PM, Chris M. Thomasson wrote: >> On 7/30/2026 7:43 PM, Dan Cross wrote: >>> In article <114h1v7$2b0po$2@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 7/30/2026 2:00 PM, Lawrence D’Oliveiro wrote: >>>>> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote: >>>>> >>>>>> ... the value of a pointer is the location that it points at. It's >>>>>> value is never a number. >>>>> >>>>> In C, its value is never *directly compatible* with a number. >>>> >>>> Well, uintptr_t? >>> >>> That's a type, not a value. >> Afait uintptr_t can be set to the NULL and any pointer? Then compared? > > I think, humm... uintptr_t can be set to a function pointer as well? If uintptr_t is supported, then any pointer value can be converted to that type, The result of the conversion is implementation-defined integer value. It does not mean that the pointer's value was an integer before the conversion - it's the conversion itself that produced the integer. And conversely, it also does not mean that the integer's value after the conversion was the pointer's value before the conversion.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-03 17:55 -0700 |
| Message-ID | <114rd9b$1o8k3$2@kst.eternal-september.org> |
| In reply to | #400792 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 01/08/2026 10:25, Chris M. Thomasson wrote:
>> On 7/30/2026 7:44 PM, Chris M. Thomasson wrote:
>>> On 7/30/2026 7:43 PM, Dan Cross wrote:
>>>> In article <114h1v7$2b0po$2@dont-email.me>,
>>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>>>> On 7/30/2026 2:00 PM, Lawrence D’Oliveiro wrote:
>>>>>> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:
>>>>>>
>>>>>>> ... the value of a pointer is the location that it points at. It's
>>>>>>> value is never a number.
>>>>>>
>>>>>> In C, its value is never *directly compatible* with a number.
>>>>>
>>>>> Well, uintptr_t?
>>>>
>>>> That's a type, not a value.
>>> Afait uintptr_t can be set to the NULL and any pointer? Then compared?
>>
>> I think, humm... uintptr_t can be set to a function pointer as well?
>
> If uintptr_t is supported, then any pointer value can be converted to
> that type, The result of the conversion is implementation-defined
> integer value. It does not mean that the pointer's value was an integer
> before the conversion - it's the conversion itself that produced the
> integer. And conversely, it also does not mean that the integer's value
> after the conversion was the pointer's value before the conversion.
And now for the usual pedantic quibbles.
Certain guarantees apply to object pointer types, not to function pointer
types.
Any pointer value can be converted to any integer type, and vice
versa. The result of such a conversion is implementation-defined
in most cases, and is not necessarily meaningful except in a few
specified cases.
A value of any object pointer type can be converted to void* and back
again, and the result compares equal to the original pointer.
If uintptr_t exists, then any void* value can be converted to intptr_t
and back again, and the resulting void* value compares equal to the
original pointer. Likewise for intptr_t. (uintptr_t feels vaguely more
appropriate to me, but there's no such implication in the standard.)
It seems obvious that a value of any object pointer type can be
converted to uintptr_t and back again without loss of information,
but I don't think the standard actually guarantees it. You can convert
an int* to void*, then to uintptr_t, then back to void*, and then back
to int*, and the result is guaranteed to compare equal to the original
int*. If you skip the intermediate void*, I don't *think* the standard
guaranteed that it works the same way. It would take a deliberately
perverse implementation to make this not work as expected.
There are no guarantees about converting between uintptr_t and
function pointer types, beyond the requirements that apply to all
pointer and integer types.
All function pointer types are convertible to all (other) function
pointer types without loss of information -- but not to or from
integer or object pointer types.
The standard doesn't say that function pointers can be converted to
object pointer types or vice versa -- no does it say that they can't.
My conclusion is that the behavior of such a conversion is undefined
by omission. (There was a lengthy and unproductive discussion about
this here a few years ago.) IMHO it would be better for the standard
to say that such conversions yield implementation-defined results.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-04 09:12 +0200 |
| Message-ID | <114s3dm$1ug6o$1@dont-email.me> |
| In reply to | #400796 |
On 04/08/2026 02:55, Keith Thompson wrote: > All function pointer types are convertible to all (other) function > pointer types without loss of information -- but not to or from > integer or object pointer types. > > The standard doesn't say that function pointers can be converted to > object pointer types or vice versa -- no does it say that they can't. > My conclusion is that the behavior of such a conversion is undefined > by omission. (There was a lengthy and unproductive discussion about > this here a few years ago.) IMHO it would be better for the standard > to say that such conversions yield implementation-defined results. > I think it would be better for the standards to say that it is implementation defined whether or not you can convert between function pointers and object pointers (or maybe just void*), and that if the implementation allows it, then the conversion must be information-preserving in both directions. Then you know that it either "just works", or that the implementation knows it can't handle it and can give a compile-time error (even when given explicit casts). The worst possible choice it is implementation-defined so that on a hypothetical system with fat function pointers and simple data pointers (or vice-versa), conversions have to be defined (such as by truncation) but silently fail to work as the programmer expects. My preference is always towards having things like this either work fully, or give a compile-time error. Leaving the behaviour undefined, as it is now, lets implementations do what they want - including the behaviour I described - and is, IMHO, better than your suggestion.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-02 19:01 -0700 |
| Message-ID | <114osqc$urbi$1@kst.eternal-september.org> |
| In reply to | #400613 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:
>> ... the value of a pointer is the location that it points at. It's
>> value is never a number.
>
> In C, its value is never *directly compatible* with a number.
Lawrence, you've never explained what you mean here by "directly
compatible". Will you please do so?
--
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 | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-08-03 19:59 +0000 |
| Message-ID | <114qrv6$1vf$1@reader1.panix.com> |
| In reply to | #400731 |
In article <114osqc$urbi$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >Lawrence D’Oliveiro <ldo@nz.invalid> writes: >> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote: >>> ... the value of a pointer is the location that it points at. It's >>> value is never a number. >> >> In C, its value is never *directly compatible* with a number. > >Lawrence, you've never explained what you mean here by "directly >compatible". Will you please do so? Or, will he please not. Lawrence is a well-known troll. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-30 03:50 -0700 |
| Message-ID | <114fa9a$1mrbt$1@kst.eternal-september.org> |
| In reply to | #400576 |
Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]
> Can a pointer have a value of zero, but not be a null pointer?
I'm not sure what you mean by that. "zero" is not a value of any
pointer type.
> This, for example, thinks that p ends up as a null pointer.
> But there is no constant 0.
>
> Probably I'm confused.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void)
> {
> char *p = malloc(1);
>
> printf("p = %p\n", (void*) p);
>
> do
> {
> p--;
> printf("p is%s null, p = %p\n", p ? " not" : "", (void*) p);
> }
> while (p);
>
> return 0;
> }
The very first `p--` has undefined behavior, since it attempts
to cause p to point before the beginning of an allocated object.
It might very well result in p==NULL eventually (after about 100
trillion iterations on my system), but that doesn't mean anything.
A much simpler illegitimate way to generate something that looks and
probably acts like a null pointer on most implementations is:
char *p;
memset(&p, 0, sizeof p);
A compiler make assumptions that prevent the code from doing what you
might expect.
A null pointer value can be validly obtained by converting a null
pointer constant to a pointer type, or as the result of some library
functions (e.g., malloc(SIZE_MAX) unless it actually succeeds),
or by copying an existing null pointer value.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-07-29 15:09 -0700 |
| Message-ID | <114dtmn$17li8$1@dont-email.me> |
| In reply to | #400485 |
On 7/28/2026 2:00 PM, Johann 'Myrkraverk' Oskarsson wrote:
> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
>> On 7/28/2026 12:42 AM, Johann 'Myrkraverk' Oskarsson wrote:
>>> On 28/07/2026 8:59 AM, Keith Thompson wrote:
>>>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>>>>> On 28/07/2026 3:58 AM, Keith Thompson wrote:
>>>>>> You'd have to create a compiler, or modify an existing one, to use a
>>>>>> non-zero representation for null pointers. That's hardly "trivial".
>>>>>> (For example, default initialization for static objects could no
>>>>>> longer just zero the target object.)
>>>>>
>>>> [SNIP]
>>>>
>>>> Your ASCII art has nothing to do with the current discussion (and
>>>> didn't even display correctly due to line wrapping). I've dropped
>>>> the cross-post to alt.ascii-art. Can you please try to focus?
>>>>
>>>
>>> Nope. You've absolutely demonstrated that you have no idea what
>>> is involved in the internals of a C compiler. What you're trying
>>> to describe is just hogwash and balderdash when it comes to the
>>> real world nitty gritty of implementing a compiler.
>>>
>>> Now stay out of my compiler discussion, you're not wanted here!
>>>
>>
>>
>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
>> pointer type,
>>
>> if (! p) { }
>>
>> is basically converted to:
>>
>> if (p == NULL) { }
>>
>> See?
>
> Now implement
>
> if ( p )
>
> as not
>
> if ( ( int ) p ) ; // !
>
> See?
>
See what? why is that (int) there? are you sure you know what you are
doing? ever hears of uintptr_t?
if (p), if p is a pointer type, at the low level is akin to:
if (p != NULL)
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-28 08:14 +0800 |
| Message-ID | <hvS9S.39$aXr.10@fx18.ams4> |
| In reply to | #400449 |
On 28/07/2026 3:58 AM, Keith Thompson wrote:
>
> You'd have to create a compiler, or modify an existing one, to use a
> non-zero representation for null pointers. That's hardly "trivial".
> (For example, default initialization for static objects could no
> longer just zero the target object.)
__ .----.__
.________________________________________.
-' `/(#)#(#) `- . o O ( I tend to assume people are more
capable )
` (#)#(#) \ ___ ^( than they actually are, because
it )^^
__( \ ,,,/ `. ``. ( makes them either feel better,
or some- )
/ \ \,-/ | \ ( times they rise to the challenge!
)^^^^^^
| `-- ( ( /__ ( ^^^( )^^^^^^^^^^^^^^^^^^^^^^^^^^^^
` ( `---\ `---._` ( } (^^
^^)______________________________.
| | \ `----._`.`. .' ( For instance, this is an old
ASCII art )
. ( `-) \ `. )) ) | ( horror I made several years ago.
)^^^
/ \ / / ) / { ( I got semi-famous for my
collection )
/ \ / ( | ( ( of non-trivial ASCII art.
)^^^^^^^^^^
/ ,\ /\\\ ( |_ \ ( And I made all of it by hand,
including )
/ /\( ) / .`\\\ ^^( this thought bubble.
)^^^^^^^^^^^^^^
\\/ \ .-' | | -_ ^^^^^^^^^^^^^^^^^^^^^^^
\ .'___( ) \ `-.
-' \/\___\\__\
/** Do you ever mix C and ASCII art? **/
int main( int _, char *o[] ) { return _^( int ) main <3 ; }
>
> I don't think there are any modern C compilers that don't use
> all-bits-zero for null pointers. Other representations are of
> course valid, but tend not to be worth the trouble.
>
> I wouldn't be terribly surprised if a future standard mandated
> all-bits-zero for null pointers -- or if it didn't.
>
I think more of it like an arm-chair thought exercise. The issue
isn't the bit pattern at all, but how you're going to treat conversion
to integers. Especially in this context,
if ( p ) { ... }
a 64bit p with the pattern 0x..00000000 isn't supposed to be false,
when truncated to an integer. If I remember the standard(s)
correctly, p here is supposed to "devolve" into either 1 or 0 in a
boolean context. I'd believe comparing to zero, and use the Z flag is
normal in x64, and in MIPS64, direct comparison to $zero is probably
the most normal way to go about it.
I forgot the actual instructions in both cases. They're easy to
look up anyway.
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-29 05:54 +0800 |
| Message-ID | <Ty9aS.8607$jNNe.5566@fx15.ams4> |
| In reply to | #400462 |
On 29/07/2026 5:35 AM, Steven M. O'Neill wrote:
> Pardon the top-posting. Just wanted to let you know that this
> didn't display well on my particular setup, as my newsreading
> software is set up to wrap at around 80 columns. IIRC this is
> (or used to be at least) the accepted limit for line lengths.
Apologies. I did this in my text editor, and neglected to notice
the longest line is 81 columns. My editor says the end of the line
is at 80, but starts the column count at zero. I'm unsure if that
should be counted as 80 columns, or 81. Is the following any better
for you? The original displays correctly for me, in my newsreader.
__ .----.__ .________________________________________.
-' `/(#)#(#) `- . o O ( I tend to assume people are more
capable )
` (#)#(#) \ ___ ^( than they actually are, because it )^^
__( \ ,,,/ `. ``. ( makes them either feel better, or
some- )
/ \ \,-/ | \ ( times they rise to the challenge!
)^^^^^^
| `-- ( ( /__ ( ^^^( )^^^^^^^^^^^^^^^^^^^^^^^^^^^^
` ( `---\ `---._` ( } (^^
^^)______________________________.
| | \ `----._`.`. .' ( For instance, this is an old ASCII
art )
. ( `-) \ `. )) ) | ( horror I made several years ago.
)^^^
/ \ / / ) / { ( I got semi-famous for my
collection )
/ \ / ( | ( ( of non-trivial ASCII art. )^^^^^^^^^^
/ ,\ /\\\ ( |_ \ ( And I made all of it by hand,
including )
/ /\( ) / .`\\\ ^^( this thought bubble.
)^^^^^^^^^^^^^^
\\/ \ .-' | | -_ ^^^^^^^^^^^^^^^^^^^^^^^
\ .'___( ) \ `-.
-' \/\___\\__\
My newsreader garbleds the paste in the newsreader-editor, but appears
to post correctly anyway. You can also see the image sans thought
bubble at
https://asciiart.website/search.php?q=myrkraverk&sort_by=random
and my own website.
Cross posting to comp.lang.c as well, for Keith.
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | steveo@panix.com (Steven M. O'Neill) |
|---|---|
| Date | 2026-07-31 20:34 +0000 |
| Message-ID | <114j0ta$197$1@reader1.panix.com> |
| In reply to | #400487 |
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
>Apologies. I did this in my text editor, and neglected to notice
>the longest line is 81 columns. My editor says the end of the line
>is at 80, but starts the column count at zero. I'm unsure if that
>should be counted as 80 columns, or 81. Is the following any better
>for you? The original displays correctly for me, in my newsreader.
Still wrapping. Here, I can remove the wrappy bits.
(the text makes less sense now :)
> __ .----.__ .________________________________________.
> -' `/(#)#(#) `- . o O ( I tend to assume people are more
> ` (#)#(#) \ ___ ^( than they actually are, because it )^^
> __( \ ,,,/ `. ``. ( makes them either feel better, or
> / \ \,-/ | \ ( times they rise to the challenge!
> | `-- ( ( /__ ( ^^^( )^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ` ( `---\ `---._` ( } (^^
> | | \ `----._`.`. .' ( For instance, this is an old ASCII
> . ( `-) \ `. )) ) | ( horror I made several years ago.
> / \ / / ) / { ( I got semi-famous for my
> / \ / ( | ( ( of non-trivial ASCII art. )^^^^^^^^^^
> / ,\ /\\\ ( |_ \ ( And I made all of it by hand,
> / /\( ) / .`\\\ ^^( this thought bubble.
> \\/ \ .-' | | -_ ^^^^^^^^^^^^^^^^^^^^^^^
> \ .'___( ) \ `-.
> -' \/\___\\__\
Nice :D
--
Steven O'Neill steveo@panix.com
Brooklyn, NY http://www.panix.com/~steveo
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-07-28 19:40 -0400 |
| Message-ID | <114belp$fb7h$1@dont-email.me> |
| In reply to | #400462 |
On 2026-07-27 20:14, Johann 'Myrkraverk' Oskarsson wrote:
...> I think more of it like an arm-chair thought exercise. The issue
> isn't the bit pattern at all, but how you're going to treat conversion
> to integers. Especially in this context,
>
> if ( p ) { ... }
The behavior of the if() statement depends only upon the result when p
is compared with 0. If it compares unequal, the block is supposed to be
executed. If it compares equal, the block is supposed to be skip. 0 is a
null pointer constant. When a pointer value is compared for equality
with a null pointer constant, the pointer is not converted to an
integer, the null pointer constant is converted to a null pointer value
of the same type. Evaluation of the equality comparison is governed by
the following rules: All null pointers are supposed to compare equal to
each other, a null pointer is never supposed to compare equal to a
non-null pointer.
Therefore, it depends very much on whether or not the pointer contains
whichever bit pattern represents a null pointer, and NOT on whether or
not the bit pattern is all 0s.
If you've never built a compiler for a platform where null pointers have
a representation that has some of it's bits set, you've never needed to
worry about this distinction. But it does need to be considered for
those platforms.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-07-27 15:36 -0500 |
| Message-ID | <1148fmf$3gt3k$1@dont-email.me> |
| In reply to | #400445 |
On 7/27/2026 11:22 AM, Johann 'Myrkraverk' Oskarsson wrote:
> On 27/07/2026 9:33 PM, James Kuyper wrote:
>> On 2026-07-25 12:30, Waldek Hebisch wrote:
>>> David Brown <david.brown@hesbynett.no> wrote:
>> ...>> The evaluation of "!p" is based on a comparison of "p" to the
>> value 0 -
>>>> it will be true if p contains the value 0. ...
>>
>> False.
>>
>>>> ... (This point is perhaps the
>>>> weak link in my reasoning - maybe "!p" is only true if "p" is
>>>> actually a
>>>> null pointer. ...
>>
>> Correct.
>>
>>>> ... However, I am confident that all real implementations,
>>>> where null pointers are value 0, ...
>>
>> I doubt that - if it were true, there would be pressure on the committee
>> to mandate such a representation.
>>
>>>> ... act by comparison of the value.)
>>>> As far as I can see, therefore, "p" can be a valid pointer to an object
>>>> of appropriate type, not be a null pointer, and still have value 0 and
>>>> have "!p" evaluate to 1.
>>> I did not check the standard, but if the standard allows this, then
>>> this is clearly a bug in the standard.
>>
>> The standard is quite clear. !p returns 0 if p compares equal to 0, and
>> 1 otherwise. When a pointer is compared with 0, the 0 gets implicitly
>> converted to a null pointer of the same type. All null pointers compare
>> equal. Therefore !p tests whether 0 is a null pointer, not whether it
>> has a representation with all bits cleared.
>>
>
> I'm not in a position to do so yet, but you can trivially test this by
> implementing "the null pointer" to be internally represented by 0xff..ff
> where the .. represents your bitwith; 16bit, 32bit, 64bit, 128bit.
>
> Then one of the first thing you notice, is that the integer zero needs
> to convert to the 0xff..ff bit pattern when cast to a pointer. After
> that, implementing !p is trivial, for some value of trivial.
>
FWIW:
In my ISA's, it is possible to have NULL pointers with not-all-bits 0.
Say, typical pointer layout:
(47: 0): Address
(63:48): Tag Bits
You could in theory have 0 base address, and non-zero tag.
Though, in the default mode, the compiler assumes canonical C data
pointers will always have the tag bits set to 0, so all bits 0 is the
canonical NULL.
Note that normal memory loads/stores ignore the high 16 bits, so (unlike
on x86-64 or similar) don't need to manually clear them first (and also
less need to rely on the graceful assumption of the OS not putting
anything outside of the 48-bit range; but other schemes like NaN Boxing
would also run into a big headache here).
Ignoring the high bits, and having instructions like LEA set them to 0,
etc, were fairly deliberate design choices.
As I see it, we are still fairly far from traditional programs being
cramped by a 48-bit VAS (and, at this scale, tag bits were a more
compelling use-case than having a bigger VAS).
Note: VAS = Virtual Address Space.
Though, it is possible I could consider allowing/defining a sub-mode
that shrinks the tag to 8 bits, if needed.
There was previously stuff to support a 32-bit VAS, but this has mostly
fallen into disuse (the relative memory savings of programs with 32-bit
pointers isn't enough in general to justify the added hassle of
supporting programs with 32-bit pointers; even if as-is, only a small
minority of the programs would need more than 32 bits of VAS).
Other contents depend on context:
LR and Function Pointers: Include some captured mode-state bits;
Applicable if LSB is Set;
Encodes things like which ISA the CPU is running.
General Data Pointers:
Typically used as type-tag bits;
Have been used for bounds-check metadata in some cases;
For internal use in my OpenGL impl, they hold texture type/size.
Where, type tags are sorta like (high 4 bits):
0000: Object Pointers, 12b = object type key
0001: Misc small values
0010: Bounds checked pointers
0011: Bounds checked pointers
01xx: Fixnum (62-bit signed integer value)
10xx: Flonum (62-bit floating point, Binary64 shifted right 2 bits)
110x: Densely packed Vectors (2/3 element, FPU)
1110: Pointer with type-tagging (direct encoded or signature index)
00dd-tttt-tttt: d=*/**/***/****, t=base type index
1xxx-xxxx-xxxx: Signature String Index
1111: Pointer, alt, may encode a 60-bit address.
This stuff is mostly relevant to a dynamically typed code.
There are extensions to C to support dynamic types, but this is used
sparingly. They are inherently slower than the normal static types, as
well as being non-portable.
There are cases where it makes sense to use dynamic types though.
Technically it also allows my compiler to compile a JavaScript variant,
though it isn't an exact match for the normal JS (its JS mode is
effectively just a static-compiled version of my older BGBScript
Language). Syntax is sorta like ES3 + other stuff; a fair bit somewhat
resembles the abandoned ES4 spec as well.
Can note that both BGBScript and BGBScript2 had ended up using hybrid
type models:
Core is static typed;
May use dynamic types as needed:
BS: via lack of explicit type;
BS2: if static type was the dynamic type (variant).
For BS, compiler may infer types via type inference.
This was used in my VM, but not currently used by BGBCC.
BS2 had an 'auto' type, but in BGBCC, is the same as 'variant'.
In this implementation, both share the same toplevel as C land.
Canonically, one needs a 'native' keyword for imports/exports, but, yeah...
In BS, say:
native function Foo(x:int):int; //import Foo from C land
native function Bar(x:int, y:int):int //exported to C
{ return x+y; }
Or, BS2:
native int Foo(int x); //import Foo from C land
native int Bar(int x, int y) //exported to C
{ return x+y; }
In BGBCC, it doesn't matter, as it is assumed for toplevel decls.
Implicitly, in this case, the toplevel also disallows overloading
(relevant to BS2 and the experimental C++ mode). For sake of the C++
mode, it is like the toplevel always has 'extern "C"' applied
(internally, 'extern "C"' having just been mapped back to the NATIVE flag).
But, yeah, in the C dialect, it mostly takes the form of:
__variant x; //dynamically typed
x=3; //3 converted to fixnum
x=3.14159; //converted to flonum
x=(__variant) { .foo=3; .bar=4; }; //ex-nihilo object
...
Then you could type-check pointers, say:
if(x __instanceof __fixint)
{ do something with a fixnum ...}
Syntax in BS2 is similar, just without the '__' on the keywords.
Note that, in this implementation, BS and BS2 can also still use the C
preprocessor, etc.
Note that for a common subset of common types, the C compiler and C
runtime need to be kept in sync regarding the initial set of dynamic
types (such that the compiler knows the type-tags in advance); but other
type-tags may appear dynamically at runtime.
Note also, unlike what may be implied in some languages, it doesn't
create a new type tag for every type of class/interface, rather it would
merely tag that it is a pointer to a class/interface, and "instanceof"
would then use a different mechanism to check class types. When compiler
does its things, the first pointer in the VTable points to a metadata
structure describing the class and its contents. Theoretically, the
class member lists could be used to implement an object serialization
thing, but currently TestKern doesn't have this.
I think I had considered something like this to allow for potential
non-local COM, but it hasn't been done yet (no network, so no need for
non-local RPC).
Well, also the other tradeoff for how to serialize:
Dump raw structs, with sizes, and pointers relative to a base address.
( Roughly the route DCOM/OLE went IIRC. )
Binary TLV style structure;
(More flexible than the above, but more overhead).
ASCII based structure (say, something JSON-like).
Or, S-Expressions, or whatever else.
Human readable text, but needs printer/parser.
Usually, object serialization is "not the right tool for the job" though.
Note: metadata differs from that defined for the IA64 C++ ABI (for
RTTI), which IIRC was merely able to identify the object, but would lack
the metadata to describe said object's contents/layout (so couldn't be
used for automatic serialization; or reflective/dynamic-typed access to
static-typed objects, ...).
Note 2: Class/Instance and ex-Nihilo objects were separate entity
sub-types (the ex-nihilo objs containing an associative key/value
structure). The languages supported "dynamic" objects (with a
class/instance part, and supporting dynamically extending with new
fields); these existed as Class/Instance objects with an internal
optional ex-nihilo object glued on (NULL if no extra members were used).
In either case, C/I object layouts were based on appending subclass
contents onto the end (like a narrow sub-case of traditional C++ object
layout), rather than any more complex "dynamic" mechanisms. In effect,
things like interfaces were also handled by basically just appending
vtable pointers onto the end of the object's layout (so casting a class
to an implemented interface is basically just adding the interface
pointer's offset to that of the base class; interface VT effectively
encoding another offset that is added to itself to get the 'this'
pointer for the base-class).
Cases where the dynamic type-system have been used had mostly been
limited to things like small specialized script interpreters and
similar. Like, there is a BASIC interpreter for a 1980s style dialect.
Note however, there is no garbage collector...
So, if code is written that assumes that dynamic types means the freedom
to generate lots of garbage and have the GC deal with it, this is not
the case here.
But, yeah, all the fun corners one can get stuck in...
>
> Happy compiler building!
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-29 04:56 +0800 |
| Message-ID | <aI8aS.5454$DOD1.157@fx17.ams4> |
| In reply to | #400450 |
On 28/07/2026 4:36 AM, BGB wrote:
> On 7/27/2026 11:22 AM, Johann 'Myrkraverk' Oskarsson wrote:
>> On 27/07/2026 9:33 PM, James Kuyper wrote:
>>> On 2026-07-25 12:30, Waldek Hebisch wrote:
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>> ...>> The evaluation of "!p" is based on a comparison of "p" to the
>>> value 0 -
>>>>> it will be true if p contains the value 0. ...
>>>
>>> False.
>>>
>>>>> ... (This point is perhaps the
>>>>> weak link in my reasoning - maybe "!p" is only true if "p" is
>>>>> actually a
>>>>> null pointer. ...
>>>
>>> Correct.
>>>
>>>>> ... However, I am confident that all real implementations,
>>>>> where null pointers are value 0, ...
>>>
>>> I doubt that - if it were true, there would be pressure on the committee
>>> to mandate such a representation.
>>>
>>>>> ... act by comparison of the value.)
>>>>> As far as I can see, therefore, "p" can be a valid pointer to an
>>>>> object
>>>>> of appropriate type, not be a null pointer, and still have value 0 and
>>>>> have "!p" evaluate to 1.
>>>> I did not check the standard, but if the standard allows this, then
>>>> this is clearly a bug in the standard.
>>>
>>> The standard is quite clear. !p returns 0 if p compares equal to 0, and
>>> 1 otherwise. When a pointer is compared with 0, the 0 gets implicitly
>>> converted to a null pointer of the same type. All null pointers compare
>>> equal. Therefore !p tests whether 0 is a null pointer, not whether it
>>> has a representation with all bits cleared.
>>>
>>
>> I'm not in a position to do so yet, but you can trivially test this by
>> implementing "the null pointer" to be internally represented by 0xff..ff
>> where the .. represents your bitwith; 16bit, 32bit, 64bit, 128bit.
>>
>> Then one of the first thing you notice, is that the integer zero needs
>> to convert to the 0xff..ff bit pattern when cast to a pointer. After
>> that, implementing !p is trivial, for some value of trivial.
>>
>
> FWIW:
> In my ISA's, it is possible to have NULL pointers with not-all-bits 0.
>
>
> Say, typical pointer layout:
> (47: 0): Address
> (63:48): Tag Bits
> You could in theory have 0 base address, and non-zero tag.
>
> Though, in the default mode, the compiler assumes canonical C data
> pointers will always have the tag bits set to 0, so all bits 0 is the
> canonical NULL.
>
> Note that normal memory loads/stores ignore the high 16 bits, so (unlike
> on x86-64 or similar) don't need to manually clear them first (and also
> less need to rely on the graceful assumption of the OS not putting
> anything outside of the 48-bit range; but other schemes like NaN Boxing
> would also run into a big headache here).
>
> Ignoring the high bits, and having instructions like LEA set them to 0,
> etc, were fairly deliberate design choices.
Isn't that how early ARM code worked? As far as I understood some line
noise I was reading until recently, a large part of why early 26bit code
on the early ARM machines didn't work when they introduced 32bit virtual
or physical address mode* was people using the upper bits of the pointer
for some tag or other.
This was in the context of RISC OS, and not modern operating systems
like Linux or NetBSD.
* I forgot the exact specifics, the incompatibility could have been
something else. I'm sure Dan Cross is just itching to correct me.
>
> As I see it, we are still fairly far from traditional programs being
> cramped by a 48-bit VAS (and, at this scale, tag bits were a more
> compelling use-case than having a bigger VAS).
>
> Note: VAS = Virtual Address Space.
>
>
> Though, it is possible I could consider allowing/defining a sub-mode
> that shrinks the tag to 8 bits, if needed.
>
> There was previously stuff to support a 32-bit VAS, but this has mostly
> fallen into disuse (the relative memory savings of programs with 32-bit
> pointers isn't enough in general to justify the added hassle of
> supporting programs with 32-bit pointers; even if as-is, only a small
> minority of the programs would need more than 32 bits of VAS).
>
>
>
> Other contents depend on context:
> LR and Function Pointers: Include some captured mode-state bits;
> Applicable if LSB is Set;
> Encodes things like which ISA the CPU is running.
> General Data Pointers:
> Typically used as type-tag bits;
> Have been used for bounds-check metadata in some cases;
> For internal use in my OpenGL impl, they hold texture type/size.
>
> Where, type tags are sorta like (high 4 bits):
> 0000: Object Pointers, 12b = object type key
> 0001: Misc small values
> 0010: Bounds checked pointers
> 0011: Bounds checked pointers
> 01xx: Fixnum (62-bit signed integer value)
> 10xx: Flonum (62-bit floating point, Binary64 shifted right 2 bits)
> 110x: Densely packed Vectors (2/3 element, FPU)
> 1110: Pointer with type-tagging (direct encoded or signature index)
> 00dd-tttt-tttt: d=*/**/***/****, t=base type index
> 1xxx-xxxx-xxxx: Signature String Index
> 1111: Pointer, alt, may encode a 60-bit address.
>
> This stuff is mostly relevant to a dynamically typed code.
> There are extensions to C to support dynamic types, but this is used
> sparingly. They are inherently slower than the normal static types, as
> well as being non-portable.
>
>
> There are cases where it makes sense to use dynamic types though.
> Technically it also allows my compiler to compile a JavaScript variant,
> though it isn't an exact match for the normal JS (its JS mode is
> effectively just a static-compiled version of my older BGBScript
> Language). Syntax is sorta like ES3 + other stuff; a fair bit somewhat
> resembles the abandoned ES4 spec as well.
>
> Can note that both BGBScript and BGBScript2 had ended up using hybrid
> type models:
> Core is static typed;
> May use dynamic types as needed:
> BS: via lack of explicit type;
> BS2: if static type was the dynamic type (variant).
> For BS, compiler may infer types via type inference.
> This was used in my VM, but not currently used by BGBCC.
> BS2 had an 'auto' type, but in BGBCC, is the same as 'variant'.
>
> In this implementation, both share the same toplevel as C land.
> Canonically, one needs a 'native' keyword for imports/exports, but, yeah...
>
> In BS, say:
> native function Foo(x:int):int; //import Foo from C land
> native function Bar(x:int, y:int):int //exported to C
> { return x+y; }
> Or, BS2:
> native int Foo(int x); //import Foo from C land
> native int Bar(int x, int y) //exported to C
> { return x+y; }
>
> In BGBCC, it doesn't matter, as it is assumed for toplevel decls.
> Implicitly, in this case, the toplevel also disallows overloading
> (relevant to BS2 and the experimental C++ mode). For sake of the C++
> mode, it is like the toplevel always has 'extern "C"' applied
> (internally, 'extern "C"' having just been mapped back to the NATIVE flag).
Did you remember to support
extern "C" foo ; // ?
I found that bug in the then-Sun C++ compiler. They had forgotten to
support a single statement extern "C", and only supported it in curly
braces. By the time Oracle took over and closed all access to non-
paying customers, the bug was still unfixed; or so I believed based on
the bug report followup emails.
Some people later told me Sun never had competent compiler team, and
I believe Oracle doesn't retain the quality people, that situation
almost certainly got worse. I have no reason to believe this bug
has been fixed.
>
>
> But, yeah, in the C dialect, it mostly takes the form of:
> __variant x; //dynamically typed
> x=3; //3 converted to fixnum
> x=3.14159; //converted to flonum
> x=(__variant) { .foo=3; .bar=4; }; //ex-nihilo object
> ...
> Then you could type-check pointers, say:
> if(x __instanceof __fixint)
> { do something with a fixnum ...}
>
> Syntax in BS2 is similar, just without the '__' on the keywords.
>
> Note that, in this implementation, BS and BS2 can also still use the C
> preprocessor, etc.
>
>
> Note that for a common subset of common types, the C compiler and C
> runtime need to be kept in sync regarding the initial set of dynamic
> types (such that the compiler knows the type-tags in advance); but other
> type-tags may appear dynamically at runtime.
>
> Note also, unlike what may be implied in some languages, it doesn't
> create a new type tag for every type of class/interface, rather it would
> merely tag that it is a pointer to a class/interface, and "instanceof"
> would then use a different mechanism to check class types. When compiler
> does its things, the first pointer in the VTable points to a metadata
> structure describing the class and its contents. Theoretically, the
> class member lists could be used to implement an object serialization
> thing, but currently TestKern doesn't have this.
>
> I think I had considered something like this to allow for potential non-
> local COM, but it hasn't been done yet (no network, so no need for non-
> local RPC).
Do you have a good source for implementing COM? And not just to use the
Microsoft, nor Mozilla's XPCOM implementations? I currently have the
books
* OLE Controls Inside Out, and
* Inside DirectX,
but am wondering if better books are out there? I prefer to read hard-
copies when available.
>
> Well, also the other tradeoff for how to serialize:
> Dump raw structs, with sizes, and pointers relative to a base address.
> ( Roughly the route DCOM/OLE went IIRC. )
> Binary TLV style structure;
> (More flexible than the above, but more overhead).
> ASCII based structure (say, something JSON-like).
> Or, S-Expressions, or whatever else.
> Human readable text, but needs printer/parser.
>
> Usually, object serialization is "not the right tool for the job" though.
Personally, I don't really use "object serialization" anymore. I prefer
to just dump everything into SQLite. Especially the session management
data for -- hopefully -- crash resilience.
>
>
> Note: metadata differs from that defined for the IA64 C++ ABI (for
> RTTI), which IIRC was merely able to identify the object, but would lack
> the metadata to describe said object's contents/layout (so couldn't be
> used for automatic serialization; or reflective/dynamic-typed access to
> static-typed objects, ...).
>
> Note 2: Class/Instance and ex-Nihilo objects were separate entity sub-
> types (the ex-nihilo objs containing an associative key/value
> structure). The languages supported "dynamic" objects (with a class/
> instance part, and supporting dynamically extending with new fields);
> these existed as Class/Instance objects with an internal optional ex-
> nihilo object glued on (NULL if no extra members were used).
>
> In either case, C/I object layouts were based on appending subclass
> contents onto the end (like a narrow sub-case of traditional C++ object
> layout), rather than any more complex "dynamic" mechanisms. In effect,
> things like interfaces were also handled by basically just appending
> vtable pointers onto the end of the object's layout (so casting a class
> to an implemented interface is basically just adding the interface
> pointer's offset to that of the base class; interface VT effectively
> encoding another offset that is added to itself to get the 'this'
> pointer for the base-class).
>
>
>
> Cases where the dynamic type-system have been used had mostly been
> limited to things like small specialized script interpreters and
> similar. Like, there is a BASIC interpreter for a 1980s style dialect.
>
>
> Note however, there is no garbage collector...
> So, if code is written that assumes that dynamic types means the freedom
> to generate lots of garbage and have the GC deal with it, this is not
> the case here.
>
>
> But, yeah, all the fun corners one can get stuck in...
You're aware of the Ravenbrook Memory Pool System, right? Still
available at
https://github.com/Ravenbrook/mps
even though ravenbrook.com seems gone. I'll probably use this
as my first garbage collector, though I am open to "write my own"
as a practice.
Is the MPS something you'd consider in your projects?
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-07-24 14:47 +0200 |
| Message-ID | <113vmtj$3mu1j$4@dont-email.me> |
| In reply to | #400371 |
On 2026-07-23 23:31, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> You are thinking of code like :
>>
>> int x = *p;
>> if (!p) return someone_made_a_mistake;
>> ...
>>
>> Some compilers will skip the check here, because they assume the
>> hardware / OS will have caught the attempt to access address 0. That
>> is fair enough - /if/ the target is guaranteed to have such a hardware
>> catch. If it is not guaranteed, then the check can't be skipped.
>
> Yes, it can. A conforming compiler can omit the (!p) test because the
> behavior is undefined, not (necessarily) because of the behavior of the
> target system.
(I've seen you posted two followups on above. - No comment on
all that.)
>> Even better, of course, would be a compiler warning that the
>> programmer is doing something silly - whether or not the check is
>> skipped.
>
> Certainly a warning would be nice. The problem is that unexpected
> optimizations in the presence of undefined behavior don't always occur
> because the compiler *knows* that the behavior is undefined.
This thought or reasoning sounds completely perverted. - If the
compiler *knows* that there's undefined behavior (that may lead
to non-equivalent (=illegitimate) [dangerous] transformations!)
a warning (or error message) should be *mandated* in any case!
Without such a notice any "optimizations" (based on bizarre and
hazardous assumptions) should never be performed! - Certainly a
warning would not only be "nice" but should be mandated. - YMMV.
It probably just boils down to the fact that the C-folks seem to
imply another meaning of "optimization", meaning more something
like "mutation of the code to something functionally different".
Or, as it appear to me, that (with the knowledge of the inherent
problems to overcome the issues) accommodated to the situation.
Given what "C" actually is (and what it can *not* become) I don't
think it makes sense to continue arguing about what I consider to
be just the crazy facts of ("C"-)reality.
Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-07-24 16:27 +0200 |
| Message-ID | <113vso2$n8ja$1@dont-email.me> |
| In reply to | #400388 |
On 24/07/2026 14:47, Janis Papanagnou wrote:
> On 2026-07-23 23:31, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> You are thinking of code like :
>>>
>>> int x = *p;
>>> if (!p) return someone_made_a_mistake;
>>> ...
>>>
>>> Some compilers will skip the check here, because they assume the
>>> hardware / OS will have caught the attempt to access address 0. That
>>> is fair enough - /if/ the target is guaranteed to have such a hardware
>>> catch. If it is not guaranteed, then the check can't be skipped.
>>
>> Yes, it can. A conforming compiler can omit the (!p) test because the
>> behavior is undefined, not (necessarily) because of the behavior of the
>> target system.
>
> (I've seen you posted two followups on above. - No comment on
> all that.)
>
>>> Even better, of course, would be a compiler warning that the
>>> programmer is doing something silly - whether or not the check is
>>> skipped.
>>
>> Certainly a warning would be nice. The problem is that unexpected
>> optimizations in the presence of undefined behavior don't always occur
>> because the compiler *knows* that the behavior is undefined.
>
> This thought or reasoning sounds completely perverted. - If the
> compiler *knows* that there's undefined behavior (that may lead
> to non-equivalent (=illegitimate) [dangerous] transformations!)
Compilers don't (baring bugs in the compiler or misunderstandings by the
compiler writers) do transformations that are illegitimate or lead to
different semantics. There's no need for warnings about them. All
defined behaviours before the transformation will have the same defined
behaviour after the transformation.
The only way to get different effects is if the behaviour /before/ the
transformation was undefined. And then there is no way, in general, for
the compiler to know if the behaviour was changed by the transformation
as it had no definition previously.
> a warning (or error message) should be *mandated* in any case!
> Without such a notice any "optimizations" (based on bizarre and
> hazardous assumptions) should never be performed! - Certainly a
> warning would not only be "nice" but should be mandated. - YMMV.
>
> It probably just boils down to the fact that the C-folks seem to
> imply another meaning of "optimization", meaning more something
> like "mutation of the code to something functionally different".
This is all standard computer science theory. You start with code that
has a precondition and a postcondition - the code guarantees that as
long as the precondition is fulfilled, running the code will fulfill the
postcondition. A transformation - optimisation, implementation, code
generation, whatever - is valid as long as the precondition is not
strengthened and the postcondition is not weakened. At no point does
the implementation, or transformed code, or the transformer (compiler /
optimiser) have to check the precondition - it can assume it is true.
The C statement "int x = *p;" has the precondition that "p" is a valid
pointer pointing to an int object. The postcondition is that "x"
contains the value of the int at the address contained in "p". The code
does not say anything about what will happen if "p" does not point to a
valid int object. So the transformed code can do anything it likes in
such a case.
Optimisations don't change the functionality of code. But you have to
remember that the functionality of the code is only defined when the
precondition is satisfied - code has no functionality outside of that.
>
> Or, as it appear to me, that (with the knowledge of the inherent
> problems to overcome the issues) accommodated to the situation.
>
> Given what "C" actually is (and what it can *not* become) I don't
> think it makes sense to continue arguing about what I consider to
> be just the crazy facts of ("C"-)reality.
>
> Janis
>
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-25 00:52 +0800 |
| Subject | Resources for Amateur Compiler Writers |
| Message-ID | <XKM8S.218878$Xz_7.58531@fx06.ams4> |
| In reply to | #400388 |
On 24/07/2026 8:47 PM, Janis Papanagnou wrote:
> On 2026-07-23 23:31, Keith Thompson wrote:
>>
>> Certainly a warning would be nice. The problem is that unexpected
>> optimizations in the presence of undefined behavior don't always occur
>> because the compiler *knows* that the behavior is undefined.
>
> This thought or reasoning sounds completely perverted. - If the
> compiler *knows* that there's undefined behavior (that may lead
> to non-equivalent (=illegitimate) [dangerous] transformations!)
> a warning (or error message) should be *mandated* in any case!
> Without such a notice any "optimizations" (based on bizarre and
> hazardous assumptions) should never be performed! - Certainly a
> warning would not only be "nice" but should be mandated. - YMMV.
>
> It probably just boils down to the fact that the C-folks seem to
> imply another meaning of "optimization", meaning more something
> like "mutation of the code to something functionally different".
>
> Or, as it appear to me, that (with the knowledge of the inherent
> problems to overcome the issues) accommodated to the situation.
>
> Given what "C" actually is (and what it can *not* become) I don't
> think it makes sense to continue arguing about what I consider to
> be just the crazy facts of ("C"-)reality.
Sounds like you want to read /What every compiler writer should know
about programmers/ by Anton Ertl, if you haven't already. Link at
https://c9x.me/compile/bib/
and more for everyone who wants to write his own C compiler.
What some people have done, including me, is to simply lose faith in
the C ISO committee, and started to write our own C compilers. This
will make Mr. Singapore from the noise earlier very happy.
Now, I decide how to react to this /Undefined behaviour/ means, and I
disagree with the people behind the "big three" C compilers.
Happy C coding!
--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-07-24 23:08 +0100 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1140npe$10v0o$1@dont-email.me> |
| In reply to | #400391 |
On 24/07/2026 17:52, Johann 'Myrkraverk' Oskarsson wrote:
> On 24/07/2026 8:47 PM, Janis Papanagnou wrote:
>> On 2026-07-23 23:31, Keith Thompson wrote:
>
>>>
>>> Certainly a warning would be nice. The problem is that unexpected
>>> optimizations in the presence of undefined behavior don't always occur
>>> because the compiler *knows* that the behavior is undefined.
>>
>> This thought or reasoning sounds completely perverted. - If the
>> compiler *knows* that there's undefined behavior (that may lead
>> to non-equivalent (=illegitimate) [dangerous] transformations!)
>> a warning (or error message) should be *mandated* in any case!
>> Without such a notice any "optimizations" (based on bizarre and
>> hazardous assumptions) should never be performed! - Certainly a
>> warning would not only be "nice" but should be mandated. - YMMV.
>>
>> It probably just boils down to the fact that the C-folks seem to
>> imply another meaning of "optimization", meaning more something
>> like "mutation of the code to something functionally different".
>>
>> Or, as it appear to me, that (with the knowledge of the inherent
>> problems to overcome the issues) accommodated to the situation.
>>
>> Given what "C" actually is (and what it can *not* become) I don't
>> think it makes sense to continue arguing about what I consider to
>> be just the crazy facts of ("C"-)reality.
>
> Sounds like you want to read /What every compiler writer should know
> about programmers/ by Anton Ertl, if you haven't already. Link at
>
> https://c9x.me/compile/bib/
>
This is an extract from that PDF:
-------------------------------
int d[16];
int SATD (void) {
int satd = 0, dd, k;
for (dd=d[k=0]; k<16; dd=d[++k]) {
satd += (dd < 0 ? -dd : dd);
}
return satd;
}
"This was “optimized” by a pre-release of gcc-4.8 into the following
infinite loop:
SATD:
.L2:
jmp .L2
What happened? The compiler assumed that no out-of-bounds access to d
would happen, and from that derived that k is at most 15 after the
access, so the following test k<16 can be “optimized” to 1 (true),
resulting in an endless loop. Then the compiler sees that the return is
now unreachable, that satd is dead, that dd is dead, and k is dead, and
optimizes the rest away."
-------------------------------
This is pretty crazy!
> and more for everyone who wants to write his own C compiler.
> What some people have done, including me, is to simply lose faith in
> the C ISO committee, and started to write our own C compilers.
Me too. But a big constraint is the language, and also existing
practice, if the aim is to be able to compile existing code.
Because 'big' compilers are gcc are lax by default, it means poor habits
are perpetuated over the years, and your compiler therefore needs to be
lax too, although at least you can make your own stricter by default
stricter.
By 'the language', I mean that C allows lots of things which in my own
systems language for example, that I maintain, would be impossible to
write as they are nonsensical.
With C, what I found bizarre was that it was easy to write a C program
where with one of these results when compiled:
* It passes with no errors
* It passes but with warnings (and still generates an executable)
* It fails with errors
All depending on which options have been chosen. Was the program correct
or not; who knows? I think here it is the language standard giving too
much scope to compilers, in part in order to be able to compile poor
quality legacy code.
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web