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 205 — 24 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 dave_thompson_2@comcast.net - 2026-09-15 21:16 -0400
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-09-15 22:05 -0400
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 14:37 +0000
Re: Prioritize Performance over Correctness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-18 08:14 -0700
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-19 05:45 +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
Re: Malicious Computer Architecture Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-03 14:26 -0300
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
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-18 22:49 +0000
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 08:32 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Anthk GM <anthk@disroot.org> - 2026-09-15 17:10 +0000
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 18:08 +0000
You hear some noises in the distance (Was: Loderunner Enemy AI better than SWI-Prolog?) Mild Shock <janburse@fastmail.fm> - 2026-09-15 20:21 +0200
Re: You hear some noises in the distance (Was: Loderunner Enemy AI better than SWI-Prolog?) scott@slp53.sl.home (Scott Lurndal) - 2026-09-15 20:05 +0000
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] George Neuner <gneuner2@comcast.net> - 2026-08-21 02:08 -0400
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-21 15:25 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] George Neuner <gneuner2@comcast.net> - 2026-08-21 16:28 -0400
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 08:27 +0800
William A. Howard solved all his 99 problems (Re: Loderunner Enemy AI better than SWI-Prolog?) Mild Shock <janburse@fastmail.fm> - 2026-08-23 01:48 +0200
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
GNU Emacs native compiled functions (was Re: Malicious Computer Architecture) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-03 14:37 -0300
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 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-21 05:49 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-21 10:38 -0700
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-08-21 18:25 +0000
Re: Prioritize Performance over Correctness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-24 10:15 -0700
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 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-07-29 12:03 +0100 |
| Message-ID | <114cmm9$q9vq$1@dont-email.me> |
| In reply to | #400503 |
On 29/07/2026 09:45, Johann 'Myrkraverk' Oskarsson wrote:
> On 28/07/2026 9:17 PM, bart wrote:
>> On 28/07/2026 13:18, Johann 'Myrkraverk' Oskarsson wrote:
>>> On 28/07/2026 8:02 PM, bart wrote:
>>
>>>>
>>>> In any case, there is no conversion to int involved; it is just has
>>>> to implement that comparison by whatever means works.
>>>>
>>
>>> On the other hand, to the programmer, especially those not who have not
>>> and never will read the C language standard, it does look like the p
>>> pointer is "truncated" to an integer valued 0 or 1, in boolean context.
>>
>> It doesn't look like that all. This is just testing for 'truthiness',
>> which in many languages can be applied to data types such as strings
>> or lists.
>
> Let's test something for /truthiness/,
>
> #include <stdio.h>
>
> int main( int argc, char *argv[] ) {
>
> printf( "boolean: %d\n", 3 || 0 ) ;
>
> return 0;
> }
>
> what do you think the above code prints out? How is a programmer not to
> believe boolean contexts truncate to 0 and 1 after experiments like
> this?
You're using 'truncate' incorrectly. Normally it means masking some low
bits then zero- or sign-extending as needed.
If you truncated '4' to 1 bit but then you'd end up with 0, which is
false, but '4' itself is considered true.
A conversion of X to bool can be done explicitly using !!X, but it is
unnecessary in many contexts in C such as your example. It involves
neither conversion to an integer nor truncation.
>
> Have you never performed any?
>
> Did you never read /C Traps and Pitfalls/ by Koenig?
>
> Dan Cross thinks I'm an LLM.
No he just thinks you're a pratt.
>> There is also rarely any result - no value needs to be yielded when
>> the result just affects control-flow.
> Ah, I see you're still writing fiction. You /must/ be a journalist.
>
> What exactly do you mean "no value needs to yielded when the result
> just affects control-flow?"
I mean that this:
if (a && b == c)
is not usually the equivalent of:
cond = a && b == c;
if (cond)
or even:
c1 = !!a;
c2 = b == c;
c3 = c1 && c2;
if (c3)
No explicit boolean intermediates are generated, just a series of
comparisons and branches. Unless you have a very poor compiler backend.
In my own C compiler (an actual one) then this C:
int a, b, c;
if (a && b == c) ...;
produces this x64 code:
test R.a, R.a
jz L2
cmp R.b, R.c
jnz L2
...
No registers or variables are modified; there are no tangible
intermediate values.
> Do you mean this is not allowed?
>
> #include <stdio.h>
>
> int main( int argc, char *argv[] ) {
>
> switch ( argv == NULL ) case 0: printf( "argv is not NULL!\n" ) ;
This example is a little like:
c1 = argv == NULL;
where an actual value is needed, in this case an integer rather than
bool, which is the index value. But here a compiler is free to rearrange
it into an if-statement. So it depends.
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.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-29 19:32 +0800 |
| Message-ID | <LxlaS.373$TxB9.178@fx07.ams4> |
| In reply to | #400516 |
On 29/07/2026 7:03 PM, bart wrote:
> On 29/07/2026 09:45, Johann 'Myrkraverk' Oskarsson wrote:
>> On 28/07/2026 9:17 PM, bart wrote:
>>> On 28/07/2026 13:18, Johann 'Myrkraverk' Oskarsson wrote:
>>>> On 28/07/2026 8:02 PM, bart wrote:
>>>
>>>>>
>>>>> In any case, there is no conversion to int involved; it is just has
>>>>> to implement that comparison by whatever means works.
>>>>>
>>>
>>>> On the other hand, to the programmer, especially those not who have not
>>>> and never will read the C language standard, it does look like the p
>>>> pointer is "truncated" to an integer valued 0 or 1, in boolean context.
>>>
>>> It doesn't look like that all. This is just testing for 'truthiness',
>>> which in many languages can be applied to data types such as strings
>>> or lists.
>>
>> Let's test something for /truthiness/,
>>
>> #include <stdio.h>
>>
>> int main( int argc, char *argv[] ) {
>>
>> printf( "boolean: %d\n", 3 || 0 ) ;
>>
>> return 0;
>> }
>>
>> what do you think the above code prints out? How is a programmer not to
>> believe boolean contexts truncate to 0 and 1 after experiments like
>> this?
>
> You're using 'truncate' incorrectly. Normally it means masking some low
> bits then zero- or sign-extending as needed.
Truncate is truncate. It's in the English dictionary. Let's ask Merriam-
Webster.
1: to shorten by or as if by cutting off truncate an essay/article
discussion
2: to replace (an edge or corner of a crystal) by a plane
Shamelessly copied from the web, like an LLM. Dan Cross can pay the
copyright penalty.
As you can see, the definition has nothing at all to do with bits.
>
> If you truncated '4' to 1 bit but then you'd end up with 0, which is
> false, but '4' itself is considered true.
But I'm not truncating 4, I'm truncating a boolean expression.
> A conversion of X to bool can be done explicitly using !!X, but it is
> unnecessary in many contexts in C such as your example. It involves
> neither conversion to an integer nor truncation.
We aren't talking about bools here, we're talking about integers. C
has its "boolean context" in integers, due to historical compatibility
with B.
>
>>
>> Have you never performed any?
>>
>> Did you never read /C Traps and Pitfalls/ by Koenig?
>>
>> Dan Cross thinks I'm an LLM.
>
> No he just thinks you're a pratt.
I don't know what a "pratt" is. Do you mind looking it up in the
dictionary for me?
>
>
>>> There is also rarely any result - no value needs to be yielded when
>>> the result just affects control-flow.
>
>> Ah, I see you're still writing fiction. You /must/ be a journalist.
>>
>> What exactly do you mean "no value needs to yielded when the result
>> just affects control-flow?"
>
> I mean that this:
>
> if (a && b == c)
>
> is not usually the equivalent of:
>
> cond = a && b == c;
> if (cond)
What do you mean? Isn't this exactly how SSA treats the code? Do you
just randomly cut off your /phi/ variables in your optimizer?
>
> or even:
>
> c1 = !!a;
> c2 = b == c;
> c3 = c1 && c2;
> if (c3)
>
> No explicit boolean intermediates are generated, just a series of
> comparisons and branches. Unless you have a very poor compiler backend.
I mean to make my compiler middleware use SSA. What does yours do? Do
you also just randomly forget some /phi/ variables?
>
> In my own C compiler (an actual one) then this C:
>
> int a, b, c;
> if (a && b == c) ...;
>
> produces this x64 code:
>
> test R.a, R.a
> jz L2
> cmp R.b, R.c
> jnz L2
> ...
>
> No registers or variables are modified; there are no tangible
> intermediate values.
Yes there are. They are in the flags register. X64 isn't MIPS.
>
>
>> Do you mean this is not allowed?
>>
>> #include <stdio.h>
>>
>> int main( int argc, char *argv[] ) {
>>
>> switch ( argv == NULL ) case 0: printf( "argv is not NULL!\n" ) ;
>
> This example is a little like:
>
> c1 = argv == NULL;
>
> where an actual value is needed, in this case an integer rather than
> bool, which is the index value. But here a compiler is free to rearrange
> it into an if-statement. So it depends.
>
> 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.
>
Yes, switch () is different, and you can force the boolean expression by
writing an explicit p == NULL there, like I did. It's "hidden" when you
put it in an if ().
Happy compiler building! Oh, and did you bother to read the /SSA-based
Compiler Design/ book, edited by Rastello, and Bouchez Tichadou?
--
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 | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-07-29 13:42 +0100 |
| Message-ID | <114csfe$rnd4$1@dont-email.me> |
| In reply to | #400518 |
On 29/07/2026 12:32, Johann 'Myrkraverk' Oskarsson wrote: > On 29/07/2026 7:03 PM, bart wrote: >> On 29/07/2026 09:45, Johann 'Myrkraverk' Oskarsson wrote: >> You're using 'truncate' incorrectly. Normally it means masking some >> low bits then zero- or sign-extending as needed. > > Truncate is truncate. It's in the English dictionary. Let's ask Merriam- > Webster. > > 1: to shorten by or as if by cutting off truncate an essay/article > discussion > > 2: to replace (an edge or corner of a crystal) by a plane > > Shamelessly copied from the web, like an LLM. Dan Cross can pay the > copyright penalty. > > As you can see, the definition has nothing at all to do with bits. It seems to be nothing to do with pointer/integer/float to bool conversion either. >> >> If you truncated '4' to 1 bit but then you'd end up with 0, which is >> false, but '4' itself is considered true. > > But I'm not truncating 4, I'm truncating a boolean expression. I'd be interested in how you consider converting integer 8 to boolean 1, or integer 0 to boolean 0, to be 'truncation', and how you reconcile that to your dictionary definition. >> In my own C compiler (an actual one) then this C: >> >> int a, b, c; >> if (a && b == c) ...; >> >> produces this x64 code: >> >> test R.a, R.a >> jz L2 >> cmp R.b, R.c >> jnz L2 >> ... >> >> No registers or variables are modified; there are no tangible >> intermediate values. > > Yes there are. They are in the flags register. X64 isn't MIPS. Not really: * There are three implicit boolean results: 'a', 'b == c' and the result of '&&'. But the only flags used are tested only twice * We want both 'a' and 'b == c' to be True, but notice each of these tests uses the opposite logic from the other (the first needs a non-zero result and the second a zero result, since 'cmp' works by performing a subtraction, which must yield zero for equality) So there is no correspondence between how the internal machine flags behave, and the intermediate bools in the C code. >> 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. >> > > Yes, switch () is different, and you can force the boolean expression by > writing an explicit p == NULL there, like I did. It's "hidden" when you > put it in an if (). In the 'if', it directly controls branching. In the 'switch', it needs an integer value to index into a jump-table. This is in abstract machine terms.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-29 20:49 +0800 |
| Message-ID | <QFmaS.5696$DOD1.293@fx17.ams4> |
| In reply to | #400524 |
On 29/07/2026 8:42 PM, bart wrote: > On 29/07/2026 12:32, Johann 'Myrkraverk' Oskarsson wrote: >> On 29/07/2026 7:03 PM, bart wrote: >>> On 29/07/2026 09:45, Johann 'Myrkraverk' Oskarsson wrote: > >>> You're using 'truncate' incorrectly. Normally it means masking some >>> low bits then zero- or sign-extending as needed. >> >> Truncate is truncate. It's in the English dictionary. Let's ask >> Merriam- >> Webster. >> >> 1: to shorten by or as if by cutting off truncate an essay/article >> discussion >> >> 2: to replace (an edge or corner of a crystal) by a plane >> >> Shamelessly copied from the web, like an LLM. Dan Cross can pay the >> copyright penalty. >> >> As you can see, the definition has nothing at all to do with bits. > > It seems to be nothing to do with pointer/integer/float to bool > conversion either. > > >>> >>> If you truncated '4' to 1 bit but then you'd end up with 0, which is >>> false, but '4' itself is considered true. >> >> But I'm not truncating 4, I'm truncating a boolean expression. > > > I'd be interested in how you consider converting integer 8 to boolean 1, > or integer 0 to boolean 0, to be 'truncation', and how you reconcile > that to your dictionary definition. > >>> In my own C compiler (an actual one) then this C: >>> >>> int a, b, c; >>> if (a && b == c) ...; >>> >>> produces this x64 code: >>> >>> test R.a, R.a >>> jz L2 >>> cmp R.b, R.c >>> jnz L2 >>> ... >>> >>> No registers or variables are modified; there are no tangible >>> intermediate values. >> >> Yes there are. They are in the flags register. X64 isn't MIPS. > > Not really: Yes, really. The very instructions you used as example put their results in the flags register. > > * There are three implicit boolean results: 'a', 'b == c' and the result > of '&&'. But the only flags used are tested only twice > > * We want both 'a' and 'b == c' to be True, but notice each of these > tests uses the opposite logic from the other (the first needs a > non-zero result and the second a zero result, since 'cmp' works by > performing a subtraction, which must yield zero for equality) > > So there is no correspondence between how the internal machine flags > behave, and the intermediate bools in the C code. That's just because SSA doesn't deal with two assignments from the same operation. The C code is innocent. > > >>> 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. >>> >> >> Yes, switch () is different, and you can force the boolean expression by >> writing an explicit p == NULL there, like I did. It's "hidden" when you >> put it in an if (). > In the 'if', it directly controls branching. In the 'switch', it needs > an integer value to index into a jump-table. This is in abstract machine > terms. > > In concrete machine terms, both use a label; or actually, a hardware address. The machine code doesn't use labels. -- 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 | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-07-29 16:01 +0100 |
| Message-ID | <114d4k4$uqhc$1@dont-email.me> |
| In reply to | #400526 |
On 29/07/2026 13:49, Johann 'Myrkraverk' Oskarsson wrote: > On 29/07/2026 8:42 PM, bart wrote: >>>> In my own C compiler (an actual one) then this C: >>>> >>>> int a, b, c; >>>> if (a && b == c) ...; >>>> >>>> produces this x64 code: >>>> >>>> test R.a, R.a >>>> jz L2 >>>> cmp R.b, R.c >>>> jnz L2 >>>> ... >>>> >>>> No registers or variables are modified; there are no tangible >>>> intermediate values. >>> >>> Yes there are. They are in the flags register. X64 isn't MIPS. >> >> Not really: > > Yes, really. The very instructions you used as example put their > results in the flags register. Where is the result of the && operation? > In concrete machine terms, both use a label; or actually, a hardware > address. The machine code doesn't use labels. In machine code, labels are just code addresses. Label rereferences depend on the architecture; typically these will be offsets rather than addresses. Any disassembler will be able to add labels, although it can't show the original identifiers for the same reason it can't show names of variables etc unless extra info is provided. How you actually implemented any language, including a backend? I looked at your site, and there's lots of stuff there, but no mention of anything like that.
[toc] | [prev] | [next] | [standalone]
| 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]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web