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 182 — 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
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 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-29 12:53 -0700 |
| Message-ID | <114dlon$14m2h$1@kst.eternal-september.org> |
| In reply to | #400516 |
bart <bc@freeuk.com> writes:
[...]
> The contexts where a conditional expression yields a Bool that is used
> for conditional branching are these:
>
> if (cond)
> while (cond)
> do while(cond)
> for(;cond;)
> cond?: (can use branching)
>
>
> But switch (index) is different, even if a compiler can turn it into
> the above.
None of those contexts yield or operate on values of type
Bool^H^H^H^H bool or _Bool. C has has type _Bool since 1999, but
it doesn't make as much use of it as it could. All the equality
and comparison operators yields results of type int with the value
0 or 1, and all conditional tests compare the expression to 0.
It's reasonable to talk informally about things like "boolean
context", and in most cases the behavior is *as if* all these
constructs worked with type _Bool/bool, but there's no such concept
in the C standard. (`sizeof (x == y)` yields `sizeof (int)`,
but that's a contrived example.)
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-07-31 14:21 -0400 |
| Message-ID | <114ip38$2vj48$1@dont-email.me> |
| In reply to | #400516 |
bart <bc@freeuk.com> writes: [...] > The contexts where a conditional expression yields a Bool that is used > for conditional branching are these: > > if (cond) > while (cond) > do while(cond) > for(;cond;) > cond?: (can use branching) The standard does not describe the behavior of those constructs in terms of a conversion to bool. There's a separate description for each of those constructs, all of which depend upon whether "the controlling expression compares unequal to 0". "When any scalar value is converted to bool, the result is false if the value is a zero (for arithmetic types), null (for pointer types), or the scalar has type nullptr_t; otherwise, the result is true." (6.3.3.2p1) So, what difference does it make? Well, the main difference it makes is that a future version of the standard could, in principle, change some but not all of those descriptions. I don't think it's likely, but it is possible.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-07-31 20:07 +0100 |
| Message-ID | <114iroq$305vd$1@dont-email.me> |
| In reply to | #400667 |
On 31/07/2026 19:21, James Kuyper wrote: > bart <bc@freeuk.com> writes: > [...] >> The contexts where a conditional expression yields a Bool that is used >> for conditional branching are these: >> >> if (cond) >> while (cond) >> do while(cond) >> for(;cond;) >> cond?: (can use branching) > The standard does not describe the behavior of those constructs in terms > of a conversion to bool. There's a separate description for each of > those constructs, all of which depend upon whether "the controlling > expression compares unequal to 0". The result of such a compare would be 0 or 1, which is what I loosely call a Bool. (In practice it is unlikely that an actual 0 or 1 is ever generated, and which is then subsequently tested. But it can happen, certainly within intermediate stages before the final code.) > "When any scalar value is converted to bool, the result is false if the > value is a zero (for arithmetic types), null (for pointer types), or the > scalar has type nullptr_t; otherwise, the result is true." (6.3.3.2p1) If the scalar value is X, I like to think of it as evaluating !!X, or just !X if it more conveniently suits the logic. Unless it knows that X may be already be Bool (ie. an integer value of either 0 or 1, perhaps the result of a compare op), then it can dispense with it. This is even before an optimising compiler is let loose on it. > or the scalar has type nullptr_t; That's new to me. So this is a type with only one possible value? How would that be used?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-31 13:00 -0700 |
| Message-ID | <114ius8$31bg5$1@kst.eternal-september.org> |
| In reply to | #400670 |
bart <bc@freeuk.com> writes:
> On 31/07/2026 19:21, James Kuyper wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> The contexts where a conditional expression yields a Bool that is used
>>> for conditional branching are these:
>>>
>>> if (cond)
>>> while (cond)
>>> do while(cond)
>>> for(;cond;)
>>> cond?: (can use branching)
>> The standard does not describe the behavior of those constructs in terms
>> of a conversion to bool. There's a separate description for each of
>> those constructs, all of which depend upon whether "the controlling
>> expression compares unequal to 0".
>
> The result of such a compare would be 0 or 1, which is what I loosely
> call a Bool.
You might have mentioned what you meant by "Bool". I assumed it was a
typo for _Bool or bool, but it's not at all the same thing.
> (In practice it is unlikely that an actual 0 or 1 is ever generated,
> and which is then subsequently tested. But it can happen, certainly
> within intermediate stages before the final code.)
It is certain that an actual 0 or 1 is generated in the abstract
machine. The generated machine code is likely to take some reasonable
shortcuts.
I find it easier to reason about C code (mostly) in terms of the
abstract machine semantics defined by the C standard rather than in
terms of what values are stored in memory or registers, particularly
when I don't know or care what target system is being used.
>> "When any scalar value is converted to bool, the result is false if the
>> value is a zero (for arithmetic types), null (for pointer types), or the
>> scalar has type nullptr_t; otherwise, the result is true." (6.3.3.2p1)
>
> If the scalar value is X, I like to think of it as evaluating !!X, or
> just !X if it more conveniently suits the logic. Unless it knows that
> X may be already be Bool (ie. an integer value of either 0 or 1,
> perhaps the result of a compare op), then it can dispense with it.
>
> This is even before an optimising compiler is let loose on it.
I find it easier to think of a condition being compared for inequality
to 0 rather than inventing a "!!X" expression that has little to do
with how the semantics are defined.
>> or the scalar has type nullptr_t;
>
> That's new to me. So this is a type with only one possible value? How
> would that be used?
nullptr_t is the type of nullptr, a new keyword introduced in C23
as a null pointer constant. (The type name "nullptr_t" is defined
in <stddef.h>.) I can't think of a reason to, for example, define
an object of type nullptr_t. The type exists because nullptr is
an expression, and every expression has a type. C adopted nullptr
from C++11.
--
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 | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-08-01 02:34 +0000 |
| Subject | Re: Prioritize Correctness Over Performance |
| Message-ID | <114jlvs$38fh0$2@dont-email.me> |
| In reply to | #400670 |
On Fri, 31 Jul 2026 20:07:08 +0100, bart wrote: > The result of such a compare would be 0 or 1, which is what I > loosely call a Bool. The Motorola 68000 processor had instructions that could store true/false values (the result of comparisons) into a destination register/memory location. The values they chose were a byte of all-zeros for false, and a byte of all-ones for true. This was all part of the prevailing assumption that any nonzero value would do for true, which I find sloppy and repugnant. I credit Pascal with insisting that the values had to be specifically 0 for false and 1 for true. Pascal popularized the idea of enumeration types (among other things), and it treated its boolean type as just a built-in enumeration type. And in particular, enumeration types could be used as array subscript types. A type like “array [boolean] of buffer” was very useful in describing double-buffer algorithms, for example.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-28 16:08 -0700 |
| Message-ID | <114bcp0$eb3h$1@kst.eternal-september.org> |
| In reply to | #400469 |
bart <bc@freeuk.com> writes:
> On 28/07/2026 12:21, Johann 'Myrkraverk' Oskarsson wrote:
>> On 28/07/2026 6:22 PM, Keith Thompson wrote:
>>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>>>> On 28/07/2026 8:59 AM, Keith Thompson wrote:
>>>>> 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.
>
> You don't seem to have much idea either.
>
>> 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!
>>>
>>> Perhaps the rest of the group would be interested in knowing just
>>> what I got so badly wrong.
>>>
>> I'll summarize it as: You think I care what the C standard documents
>> say. I don't.
>> I care how it's implemented. You don't.
>
> This is what you 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 ) { ... }
>
> a 64bit p with the pattern 0x..00000000 isn't supposed to be false,
> when truncated to an integer...."
Suppose p is pointer, pointers are 64 bits, and int is 32 bits.
I think Johann somehow has the idea that `if ( p )` truncates the
pointer value to an integer, presumably to an int.
If null pointers are all-bits-zero, "truncating" a pointer to an
int would presumably discard 32 of its 64 bits. If the remaining 32
bits happen to be zero while the discarded bits are non-zero, then
the truncation would incorrectly indicate that p is a null pointer.
Johann likely didn't think through the consequences of what he wrote.
Of course that's not how it's done.
> You don't say what type 'p' is, but I assume it is a pointer.
>
> How a compiler implements this depends partly on what the language
> says, for example:
>
> Scalar type Value True when
>
> integer i i != 0
> float x x != 0.0 (-0.0 may need considering)
"Positive zeros compare equal to negative zeros."
So a compiler generating code for `x != 0.0` must do whatever is
necessary for positive and negative zeros to be treated as equal.
It's likely (I think) that the target system's FP comparison operator
will do the right thing.
For floating-point x, `if (x)`, is equivalent to `if (x != 0)`.
The implicit int constant `0` is converted to the type of x, making
it equivalent to `if (x != 0.0)`, or `if (x != 0.0F)`, or
`if (x != 0.0L)`. (There might be corner cases where x is very close
to zero and the distinction between 0.0F, 0.0, and 0.0L matters,
but I haven't thought it through.)
> pointer p p != NULL
>
> Whether NULL is all-bits-zero depends on the implementation, but I
> think it it more platform-dependent rather than left to individual
> compilers.
Pretty much.
As far as the C standard is concerned, it's up to the implementation.
Compilers are likely to conform to the platform ABI, which is likely
to specify the representation of a null pointer. A compiler *could*
violate the ABI, but it would generate code that, as you point out,
doesn't interact correctly with code generated by other compilers.
> Since in that case code from different compilers would be
> incompatible, and calling into external libraries would be
> problematical.
>
> In any case, there is no conversion to int involved; it is just has to
> implement that comparison by whatever means works.
Right. In the abstract machine, p is compared to 0, and the rules
for evaluating `p == 0` imply that `if (p)` tests whether p is a
null pointer.
But I don't do ASCII art, so what do I know?
(Much of this is directed to Johann, but I'm not inclined to reply
to him directly.)
--
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-07-28 23:28 +0000 |
| Message-ID | <114bduv$pfm$1@reader1.panix.com> |
| In reply to | #400492 |
In article <114bcp0$eb3h$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >[snip] >I think Johann somehow has the idea that `if ( p )` truncates the >[...] >Johann likely didn't think through the consequences of what he wrote. Of course not. LLMs don't think; they just generate the statistically mostly likely next token given their context and inputs. >(Much of this is directed to Johann, but I'm not inclined to reply >to him directly.) I almost feel bad for him; it's like punching down. But LLMs don't have feelings, so.... - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-07-28 14:22 +0000 |
| Message-ID | <114adur$3ks$1@reader1.panix.com> |
| In reply to | #400468 |
In article <4h0aS.10292$1xtd.1622@fx01.ams4>, Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote: >On 28/07/2026 6:22 PM, Keith Thompson wrote: >> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >>> 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! >> >> Perhaps the rest of the group would be interested in knowing just >> what I got so badly wrong. >> > >I'll summarize it as: You think I care what the C standard documents >say. I don't. > >I care how it's implemented. You don't. Understanding the C standard is necessary, but not sufficient, for implemeing a C compiler. If you don't care how the language is defined, you are not going to do well building a compiler for that language. You may produce a compiler for some _other_ language, which may be very close to C. That's fine, but not terribly interesting relative to all the other hobby compiler projects out there. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-07-28 13:51 -0700 |
| Message-ID | <114b4ns$cf2q$1@dont-email.me> |
| In reply to | #400468 |
On 7/28/2026 4:21 AM, Johann 'Myrkraverk' Oskarsson wrote: > On 28/07/2026 6:22 PM, Keith Thompson wrote: >> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >>> 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! >> >> Perhaps the rest of the group would be interested in knowing just >> what I got so badly wrong. >> > > I'll summarize it as: You think I care what the C standard documents > say. I don't. > > I care how it's implemented. You don't. > Huh?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-07-28 20:32 -0400 |
| Message-ID | <114bhmt$g5po$2@dont-email.me> |
| In reply to | #400468 |
On 2026-07-28 07:21, Johann 'Myrkraverk' Oskarsson wrote: ...> I'll summarize it as: You think I care what the C standard documents > say. I don't. If you don't care whether it conforms to the C standard, you aren't writing a C compiler, and this is not an appropriate newsgroup to discuss it. > I care how it's implemented. You don't. We care whether the implementation conforms to the requirements of the C standard. A compiler newsgroup would be a more appropriate place to discuss the details of how you implement it.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-07-28 14:20 +0000 |
| Message-ID | <114ads2$pkb$1@reader1.panix.com> |
| In reply to | #400466 |
In article <1149vtl$3v7uk$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >> 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! > >Perhaps the rest of the group would be interested in knowing just >what I got so badly wrong. Indeed. I suspect that the person you are responding to has a rather higher opinion of his own knowledge and/or abilities than is actually warranted. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-07-28 13:54 -0700 |
| Message-ID | <114b4up$cf2q$2@dont-email.me> |
| In reply to | #400464 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-29 05:00 +0800 |
| Message-ID | <FL8aS.5455$DOD1.4819@fx17.ams4> |
| In reply to | #400483 |
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?
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-07-28 20:25 -0400 |
| Message-ID | <114bhac$g344$1@dont-email.me> |
| In reply to | #400485 |
On 2026-07-28 17:00, Johann 'Myrkraverk' Oskarsson wrote:
> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
...>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
>> pointer type,
>>
>> if (! p) { }
>>
>> is basically converted to:
>>
>> if (p == NULL) { }
More accurately, "p == 0". Since 0 and NULL are both null pointer
constants, it shouldn't make any difference, but the actual wording used
by the standard corresponds to "p == 0".
> Now implement
>
> if ( p )
>
> as not
>
> if ( ( int ) p ) ; // !
Yes, that would be an incorrect way of implementing if(p) on such a
platform.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-07-29 14:55 -0700 |
| Message-ID | <114dssv$17hcv$1@dont-email.me> |
| In reply to | #400496 |
On 7/28/2026 5:25 PM, James Kuyper wrote:
> On 2026-07-28 17:00, Johann 'Myrkraverk' Oskarsson wrote:
>> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
> ...>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
>>> pointer type,
>>>
>>> if (! p) { }
>>>
>>> is basically converted to:
>>>
>>> if (p == NULL) { }
>
> More accurately, "p == 0". Since 0 and NULL are both null pointer
> constants, it shouldn't make any difference, but the actual wording used
> by the standard corresponds to "p == 0".
Yeah. In the "internals", if p is a pointer type, it can convert (p ==
0) to (p == NULL)? Whatever the compiler needs to compare it to NULL
instead of an integer 0. Fair enough? Simply because NULL might not be 0...
>> Now implement
>>
>> if ( p )
>>
>> as not
>>
>> if ( ( int ) p ) ; // !
>
> Yes, that would be an incorrect way of implementing if(p) on such a
> platform.
yup. (p) would be (p != 0), or lower level (p != NULL) if p is a pointer
type.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-07-28 20:31 -0400 |
| Message-ID | <114bhki$g5po$1@dont-email.me> |
| In reply to | #400485 |
On 2026-07-28 17:00, Johann 'Myrkraverk' Oskarsson wrote:
> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
...>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
NULL is required to be a null pointer constant, for which there are only
two options,
1) an integer constant expression with a value of 0.
or
2) such an expression converted to (void*)
Since 0xDEADBEEF doesn't have a value of 0, it doesn't qualify.
However, is is permissible for the representation of a null pointer to
be the same as the representation of 0xDEADBEEF in one of the integer
types. I'll assume that's what you actually meant, and that NULL is in
fact #defined in a way that conforms to the C standard, such as (10L -
'\012').
>> pointer type,
>>
>> if (! p) { }
>>
>> is basically converted to:
>>
>> if (p == NULL) { }
More accurately, "p == 0". Since 0 and NULL are both null pointer
constants, it shouldn't make any difference, but the actual wording used
by the standard corresponds to "p == 0".
> Now implement
>
> if ( p )
>
> as not
>
> if ( ( int ) p ) ; // !
Yes, that would be an incorrect way of implementing if(p) on such a
platform.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-28 21:26 -0700 |
| Message-ID | <114bvdr$j594$1@kst.eternal-september.org> |
| In reply to | #400497 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2026-07-28 17:00, Johann 'Myrkraverk' Oskarsson wrote:
>> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
> ...>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
>
>
> NULL is required to be a null pointer constant, for which there are only
> two options,
> 1) an integer constant expression with a value of 0.
> or
> 2) such an expression converted to (void*)
As of C23, a null pointer constant can be an integer constant expression
with the value 0, such an expression cast to void*, or the predefined
constant nullptr. (POSIX imposes some additional requirements.)
`(void*)nullptr` is guaranteed to evaluate to a null pointer, but it's
not a null pointer constant.
Note that `(void*)0` is a null pointer constant, but it doesn't qualify
as a definition of the NULL macro. 7.1.2 requires any definition of an
object-like macro in the standard library to "expand to code that is
fully protected by parentheses where necessary, so that it groups in an
arbitrary expression as if it were a single identifier".
Any of `0`, `((void*)0)`, or `nullptr` would be a reasonable expansion
for NULL. Unreasonable but valid definitions include:
#define NULL ('/'/'/'-'/'/'/')
#define NULL (1+1==3)
> Since 0xDEADBEEF doesn't have a value of 0, it doesn't qualify.
Right. It's easy (but incorrect) to assume a correlation between
the fact that a constant 0 (in source code) is a null pointer
constant, and the fact that all-bits-zero (during execution)
is very commonly a representation for a null pointer. There are
historical reasons, but the language is careful does not require
any particular representation for a runtime null pointer.
[...]
--
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 14:57 -0700 |
| Message-ID | <114dsvh$17hcv$2@dont-email.me> |
| In reply to | #400500 |
On 7/28/2026 9:26 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 2026-07-28 17:00, Johann 'Myrkraverk' Oskarsson wrote:
>>> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
>> ...>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
>>
>>
>> NULL is required to be a null pointer constant, for which there are only
>> two options,
>> 1) an integer constant expression with a value of 0.
>> or
>> 2) such an expression converted to (void*)
>
> As of C23, a null pointer constant can be an integer constant expression
> with the value 0, such an expression cast to void*, or the predefined
> constant nullptr. (POSIX imposes some additional requirements.)
>
> `(void*)nullptr` is guaranteed to evaluate to a null pointer, but it's
> not a null pointer constant.
>
> Note that `(void*)0` is a null pointer constant, but it doesn't qualify
> as a definition of the NULL macro. 7.1.2 requires any definition of an
> object-like macro in the standard library to "expand to code that is
> fully protected by parentheses where necessary, so that it groups in an
> arbitrary expression as if it were a single identifier".
>
> Any of `0`, `((void*)0)`, or `nullptr` would be a reasonable expansion
> for NULL. Unreasonable but valid definitions include:
>
> #define NULL ('/'/'/'-'/'/'/')
> #define NULL (1+1==3)
>
>> Since 0xDEADBEEF doesn't have a value of 0, it doesn't qualify.
>
> Right. It's easy (but incorrect) to assume a correlation between
> the fact that a constant 0 (in source code) is a null pointer
> constant, and the fact that all-bits-zero (during execution)
> is very commonly a representation for a null pointer. There are
> historical reasons, but the language is careful does not require
> any particular representation for a runtime null pointer.
>
> [...]
>
The bits of the raw NULL does not have to be 0.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-29 15:33 -0700 |
| Message-ID | <114dv4l$18198$1@kst.eternal-september.org> |
| In reply to | #400569 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 7/28/2026 9:26 PM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>> On 2026-07-28 17:00, Johann 'Myrkraverk' Oskarsson wrote:
>>>> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
>>> ...>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
>>> NULL is required to be a null pointer constant, for which there are only
>>> two options,
>>> 1) an integer constant expression with a value of 0.
>>> or
>>> 2) such an expression converted to (void*)
>>
>> As of C23, a null pointer constant can be an integer constant
>> expression with the value 0, such an expression cast to void*, or the
>> predefined constant nullptr. (POSIX imposes some additional
>> requirements.) `(void*)nullptr` is guaranteed to evaluate to a null
>> pointer, but it's not a null pointer constant. Note that `(void*)0`
>> is a null pointer constant, but it doesn't qualify as a definition of
>> the NULL macro. 7.1.2 requires any definition of an object-like
>> macro in the standard library to "expand to code that is fully
>> protected by parentheses where necessary, so that it groups in an
>> arbitrary expression as if it were a single identifier".
>>
>> Any of `0`, `((void*)0)`, or `nullptr` would be a reasonable
>> expansion for NULL. Unreasonable but valid definitions include:
>>
>> #define NULL ('/'/'/'-'/'/'/')
>> #define NULL (1+1==3)
>>
>>> Since 0xDEADBEEF doesn't have a value of 0, it doesn't qualify.
>>
>> Right. It's easy (but incorrect) to assume a correlation between
>> the fact that a constant 0 (in source code) is a null pointer
>> constant, and the fact that all-bits-zero (during execution)
>> is very commonly a representation for a null pointer. There are
>> historical reasons, but the language is careful does not require
>> any particular representation for a runtime null pointer.
>> [...]
>
> The bits of the raw NULL does not have to be 0.
You're restating something that was already clearly stated in this
thread, and you're doing it incorrectly.
The NULL macro is a source code construct. It doesn't have "bits",
unless you count the bits making up the characters 'N', 'U', 'L',
'L' (in the source character set, which needn't match the execution
character set).
The thing whose bits don't have to be 0 is a null pointer *value*,
something that exists during execution and can result from an
occurence of NULL in the source code.
The point from upthread is that your suggested (void*)0xDEADBEEF
is not a null pointer constant, and therefore is not a valid
expansion of the NULL macro, *even if* 0xDEADBEEF matches the
run-time representation of a null pointer.
(I normally ignore your posts, but I made an arbitrary exception
in this case.)
--
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 16:22 -0700 |
| Message-ID | <114e20i$190bc$1@dont-email.me> |
| In reply to | #400571 |
On 7/29/2026 3:33 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 7/28/2026 9:26 PM, Keith Thompson wrote:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>> On 2026-07-28 17:00, Johann 'Myrkraverk' Oskarsson wrote:
>>>>> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
>>>> ...>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
>>>> NULL is required to be a null pointer constant, for which there are only
>>>> two options,
>>>> 1) an integer constant expression with a value of 0.
>>>> or
>>>> 2) such an expression converted to (void*)
>>>
>>> As of C23, a null pointer constant can be an integer constant
>>> expression with the value 0, such an expression cast to void*, or the
>>> predefined constant nullptr. (POSIX imposes some additional
>>> requirements.) `(void*)nullptr` is guaranteed to evaluate to a null
>>> pointer, but it's not a null pointer constant. Note that `(void*)0`
>>> is a null pointer constant, but it doesn't qualify as a definition of
>>> the NULL macro. 7.1.2 requires any definition of an object-like
>>> macro in the standard library to "expand to code that is fully
>>> protected by parentheses where necessary, so that it groups in an
>>> arbitrary expression as if it were a single identifier".
>>>
>>> Any of `0`, `((void*)0)`, or `nullptr` would be a reasonable
>>> expansion for NULL. Unreasonable but valid definitions include:
>>>
>>> #define NULL ('/'/'/'-'/'/'/')
>>> #define NULL (1+1==3)
>>>
>>>> Since 0xDEADBEEF doesn't have a value of 0, it doesn't qualify.
>>>
>>> Right. It's easy (but incorrect) to assume a correlation between
>>> the fact that a constant 0 (in source code) is a null pointer
>>> constant, and the fact that all-bits-zero (during execution)
>>> is very commonly a representation for a null pointer. There are
>>> historical reasons, but the language is careful does not require
>>> any particular representation for a runtime null pointer.
>>> [...]
>>
>> The bits of the raw NULL does not have to be 0.
>
> You're restating something that was already clearly stated in this
> thread, and you're doing it incorrectly.
>
> The NULL macro is a source code construct. It doesn't have "bits",
> unless you count the bits making up the characters 'N', 'U', 'L',
> 'L' (in the source character set, which needn't match the execution
> character set).
>
> The thing whose bits don't have to be 0 is a null pointer *value*,
> something that exists during execution and can result from an
> occurence of NULL in the source code.
>
> The point from upthread is that your suggested (void*)0xDEADBEEF
> is not a null pointer constant, and therefore is not a valid
> expansion of the NULL macro, *even if* 0xDEADBEEF matches the
> run-time representation of a null pointer.
>
> (I normally ignore your posts, but I made an arbitrary exception
> in this case.)
>
At the system level under C, a NULL can boil down to a pointer value
equal to 0xDEADBEEF. So, the compiler needs to handle that.
at the low level:
if (! p) if p is a pointer type:
if (! __compare_ptr_to_null(p))
deep inside it compares it to 0xDEADBEEF
a system null ptr can be 0xDEADBEEF. This is lower level than the C std.
The compiler just needs to handle it. __compare_ptr_to_null(p) can be a
stub for another pass for if (p == PLATFORM_NULL_BITPATTERN)
Fair enough?
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web