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 | 6 on this page of 186 — 20 participants |
Back to article view | Back to comp.lang.c
Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-22 01:38 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-21 17:26 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-22 01:50 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-21 20:25 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-22 17:37 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-22 13:26 -0700
Re: Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-22 07:33 +0200
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-22 10:41 +0200
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-22 18:08 -0500
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-23 10:31 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 14:31 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 14:48 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 15:11 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-24 09:23 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-24 03:14 -0700
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-07-24 14:56 +0000
Re: Prioritize Performance over Correctness antispam@fricas.org (Waldek Hebisch) - 2026-07-25 16:30 +0000
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-27 09:33 -0400
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 00:22 +0800
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 12:58 -0700
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-27 15:37 -0500
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-27 17:13 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 15:17 -0700
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-07-28 01:18 +0000
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 15:40 +0800
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:18 +0000
Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 22:48 +0800
Re: Multics( Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-07-28 15:08 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 23:30 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 19:08 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:08 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:15 +0000
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:26 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 06:41 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 23:23 +0000
Picture of Organicks' book Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 16:01 +0800
Re: Picture of Organicks' book cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-29 13:46 +0000
Re: Picture of Organicks' book R Kym Horsell <kymhorsell@gmail.com> - 2026-07-29 16:54 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Cóilín Nioclásín Glostéir <thanks-to@Taf.com> - 2026-07-29 23:22 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 15:55 -0700
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 18:58 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:10 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:20 +0000
Re: Multics( Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-07-29 14:44 +0000
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-30 02:08 +0000
Re: Prioritize Performance over Correctness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-16 07:59 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 17:59 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 15:42 +0800
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 03:22 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 19:21 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-28 13:02 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 20:18 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-28 14:17 +0100
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-28 16:02 -0500
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 16:45 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 12:03 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 19:32 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 13:42 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 20:49 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 16:01 +0100
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-29 12:53 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-31 14:21 -0400
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-31 20:07 +0100
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-31 13:00 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-01 02:34 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 16:08 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 23:28 +0000
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:22 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-28 13:51 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:32 -0400
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:20 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-28 13:54 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 05:00 +0800
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:25 -0400
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 14:55 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:31 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 21:26 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 14:57 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-29 15:33 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 16:22 -0700
Re: Prioritize Performance over Correctness Richard Harnden <richard.nospam@gmail.invalid> - 2026-07-30 07:40 +0100
Re: Prioritize Correctness over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 06:48 +0000
Re: Prioritize Correctness over Performance James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 06:50 -0400
Re: Prioritize Correctness over Performance Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 03:54 -0700
Re: Prioritize Correctness over Performance James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 08:24 -0400
Re: Prioritize Correctness over Performance Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 14:40 -0700
Re: Prioritize Correctness over Performance "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:39 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 06:44 -0400
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 21:00 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 14:38 -0700
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 21:53 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 15:10 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:40 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-31 02:43 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:44 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:58 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-01 01:25 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-02 23:14 +0200
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-02 14:37 -0700
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-02 22:51 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-02 16:43 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 12:03 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-03 23:49 +0000
Re: Prioritize Correctness Over Performance "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 19:35 -0700
MS-DOS memory models (was: Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 08:08 +0800
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 10:16 +0200
Re: Prioritize Performance over Correctness Richard Harnden <richard.nospam@gmail.invalid> - 2026-08-03 10:41 +0100
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 12:28 +0200
Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 19:23 +0800
Re: Malicious Computer Architecture David Brown <david.brown@hesbynett.no> - 2026-08-03 14:01 +0200
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 22:52 +0800
Re: Malicious Computer Architecture David Brown <david.brown@hesbynett.no> - 2026-08-03 19:41 +0200
Re: Malicious Computer Architecture "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:13 -0700
Re: Malicious Computer Architecture "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:10 -0700
Re: Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-08-03 14:29 +0000
Johnny Depp prevention [Windows 11 etc...] (Was: Malicious Computer Architecture) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:10 +0200
But how can you deploy. when its ROM? (Was: Johnny Depp prevention [Windows 11 etc...]) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:15 +0200
GPU Elasticity: Collective Communications Libraries (Was: But how can you deploy. when its ROM?) Mild Shock <janburse@fastmail.fm> - 2026-08-07 14:37 +0200
What are Flits and Phits? [Network on a Chip] (Re: GPU Elasticity: Collective Communications Libraries) Mild Shock <janburse@fastmail.fm> - 2026-08-07 18:07 +0200
Cristallina: Thank you for the Beam (Re: What are Flits and Phits? [Network on a Chip]) Mild Shock <janburse@fastmail.fm> - 2026-08-09 21:22 +0200
Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:26 +0200
How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:50 +0200
Re: How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:24 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:21 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Aidan Kehoe <kehoea@parhasard.net> - 2026-08-18 21:13 +0100
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] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 08:27 +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 10 of 10 — ← Prev page 1 … 8 9 [10]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-26 17:06 -0700 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <11467eu$2pbdl$1@kst.eternal-september.org> |
| In reply to | #400427 |
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
> On 26/07/2026 6:33 AM, Keith Thompson wrote:
>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>>> On 25/07/2026 7:29 AM, Keith Thompson wrote:
[...]
>>>> If you think a compiler should not generate code based on the
>>>> assumption of defined behavior (for example, that it should generate
>>>> code for a statement even if that statement can be executed only if
>>>> undefined behavior has already occurred), that's fine, and nothing
>>>> in the C standard prevents it. There are plenty of things the C
>>>> standard permits compilers but does not require compilers to do.
>>>
>>> Indeed. If I remember correctly, loading the source code is
>>> /implementation defined/, so the compiler can perfectly well
>>> read NNTP instead of files, and strictly parse only code posted
>>> to comp.lang.c.
>>
>> That's completely irrelevant to what I wrote.
>
> Right, you said something about defined, then undefined behaviour. I
> chose not to rise to the bait. If you word your question differently
> enough not to require either of those terms, I'll reply. Until then,
> happy C coding.
There was no bait. I asked you a question about how you intend
your proposed compiler to deal with undefined behavior. You are of
course not required to answer, but your choice to post a reply about
something else was odd. I won't be wording my question differently;
what you're suggesting is that I ask an entirely different
question.
I suspect that attempting to communicate with you will not be
productive. I would enjoy having my suspicion refuted.
>>> I wonder if Mr. Singapore thought of that angle?
>> Who?
>>
> Message-ID: <113lv5q$3goh8$1@paganini.bofh.team>
So there's a user posting under the name "Singapore" who has posted
here exactly once, saying nothing relevant or interesting. I have
no idea why you'd feel the need to mention him or her (and no,
I'm not asking).
--
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 | Cóilín Nioclásín Glostéir <thanks-to@Taf.com> |
|---|---|
| Date | 2026-07-26 17:03 +0000 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1145eki$1etq9$1@paganini.bofh.team> |
| In reply to | #400391 |
More resources for creating a compiler - news:comp.compilers (S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-07-24 16:50 -0500 |
| Message-ID | <1140mtm$113v0$1@dont-email.me> |
| In reply to | #400388 |
On 7/24/2026 7:47 AM, Janis Papanagnou wrote:
> On 2026-07-23 23:31, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> You are thinking of code like :
>>>
>>> int x = *p;
>>> if (!p) return someone_made_a_mistake;
>>> ...
>>>
>>> Some compilers will skip the check here, because they assume the
>>> hardware / OS will have caught the attempt to access address 0. That
>>> is fair enough - /if/ the target is guaranteed to have such a hardware
>>> catch. If it is not guaranteed, then the check can't be skipped.
>>
>> Yes, it can. A conforming compiler can omit the (!p) test because the
>> behavior is undefined, not (necessarily) because of the behavior of the
>> target system.
>
> (I've seen you posted two followups on above. - No comment on
> all that.)
>
>>> Even better, of course, would be a compiler warning that the
>>> programmer is doing something silly - whether or not the check is
>>> skipped.
>>
>> Certainly a warning would be nice. The problem is that unexpected
>> optimizations in the presence of undefined behavior don't always occur
>> because the compiler *knows* that the behavior is undefined.
>
> This thought or reasoning sounds completely perverted. - If the
> compiler *knows* that there's undefined behavior (that may lead
> to non-equivalent (=illegitimate) [dangerous] transformations!)
> a warning (or error message) should be *mandated* in any case!
> Without such a notice any "optimizations" (based on bizarre and
> hazardous assumptions) should never be performed! - Certainly a
> warning would not only be "nice" but should be mandated. - YMMV.
>
Mostly agree...
In a lot of cases, there is UB, but:
Either the UB needs to be treated not as UB,
because real-world software expects particular behaviors.
Or, the UB should likely be warning/error + breakpoint.
Had been a little caught off guard by the latter, in the case of GCC +
C++ mode + missing return values. Some code that worked before started
crashing, eventually identified as a missing return value in an "Init"
type function:
Typically one returns 'int', but the return values are typically never
used and whether or not a function does a "return(0);" is a bit hit or miss.
Newer GCC versions seem to enforce this case, generating a break-point
rather than random garbage.
Though, yes, one can just use 'void' as the return type.
Did make the recent observation in my compiler a "TODO: Fix" type item
in that if one has a function returning void, and then tries to use the
value (such as returning it again, or assigning it to a variable); the
compiler just triggers and internal break-point and unceremoniously crashes.
While, yes, this is one possible way to deal with UB, better to have
compilation fail with an error message or something.
Generally the breakpoints were used for cases where "we shouldn't get
here, if we do, probably something has gone wrong in the compiler itself".
But, sometimes this sort of thing means going and finding good places to
put code to check for issues and print an error message and escape;
rather than continue on the normal path and have some deeper code be
like "YO, WTF".
Compiler internals being a type of code where the best strategy is
generally to be pedantic and trigger a break-point or similar when
something is unexpected (with an outer layer than needs to deal with
whatever weirdness the user throws at it, either diverting the logic, or
printing warning/error messages, ...).
Sometimes errors might be harder to handle in a sensible way if they
emerge at a later/deeper stage (which is, from what I heard, partly
where some of the UB opts were coming from in Clang and similar, and
less as a deliberate design feature).
Granted, in some of these cases, would still prefer the compiler to
insert an explicit break-point into the generated code than to quietly
remove the offending code path.
> It probably just boils down to the fact that the C-folks seem to
> imply another meaning of "optimization", meaning more something
> like "mutation of the code to something functionally different".
>
Yeah.
There are several classes of things that could be classes as optimizations:
Code generation features:
Register allocation;
Choosing sensible instruction sequences;
Culling unused local variables;
...
Modification/Sequencing:
Trying to infer how to schedule instructions to best fit pipeline;
Mostly not needed for OoO CPUs, but needed for in-order.
...
Mild Transformations:
Constant folding;
Caching array/member loads;
Delaying stores to arrays/members;
...
Stronger transformations:
Loop unrolling;
Function inlining;
Pattern matching and replacing expressions;
...
My compiler mostly focuses on the former classes, but largely ignores
the latter. In the latter case, a lot of complex pattern matching can
come up, and a lot of ways that things can go horribly wrong.
There are a few special cases, like my compiler will pattern match:
(x>>SHIFT)&MASK
And similar, as there are special CPU instructions that may convert this
into a single operation; and the fallback case of decomposing it back
into a shift and mask being no-loss (or, on targets like RISC-V, it
being often cheaper turn this case into a "shift-left;shift-right" pair
than to a "shift-and-and" mostly because RISC-V suffers hard for
immediate values outside the range of -2048..2047; or my ISAs needing to
use a larger 64-bit encoding if outside the range of -512..511).
So, for example:
y=(x>>32)&0xFFFF;
Being cheaper on RV64 to behave as-if it were:
y=(x<<16)>>32;
As it requires 2 instructions rather than 4.
On my ISA, this may be 1 instruction (if the feature is enabled),
else it also needs 2 instructions.
...
The latter class is one that GCC seems to lean more heavily into, with
MSVC sort of in-between.
The former classes for GCC depend highly on target, but had noted that
for targets like RISC-V, that GCC has some room for improvement in these
areas. Some fair bit of cleverness, but also a bit of "meh".
Though, for MSVC seems to depend on era, where it seems like MSVC
behavior changed considerably in the 2010s: More aggressive high-level
optimizations, auto vectorization, etc, but also support for newer
versions on the C standard (before this, it was mostly frozen at C90/C95
levels).
Decided to leave off going into a big detour about register allocation
strategies and similar; it got long and probably no one would care.
> Or, as it appear to me, that (with the knowledge of the inherent
> problems to overcome the issues) accommodated to the situation.
>
> Given what "C" actually is (and what it can *not* become) I don't
> think it makes sense to continue arguing about what I consider to
> be just the crazy facts of ("C"-)reality.
>
Yeah, for the most part, C works well.
Just, compilers can't go quite as wild as what could be inferred by the
standard, as going out of the scope of typical behavior will break
existing code, and people generally don't like when their code breaks.
Even when maybe faster could be possible if code were broken by relying
on things outside of those granted by a strict reading of the standard.
A person writing code may need to be more conservative, but then it is a
balancing act:
What is needed for performance;
What is needed for portability across the targets of interest;
Usually smaller than: "everything that could exist"
What behaviors the existing ranges of compilers will actually do;
...
Maximum portability at the expense of performance is not always the best
strategy.
Even as much as there may be hassle from moving non-portable code to a
different machine with different tradeoffs.
Though, among modern targets, there tends to be some level of
convergence as well:
Twos complement, little endian, supports misaligned memory access, ...
Signed right shift is near universally sign-extending;
...
As the big-ending and aligned-only machines tend to be in steady decline.
There is still a bit of variation of what happens when shifts are out-of
range or negative.
More common option for "too large" is to make it modulo the width of the
type, or modulo 32/64 bits;
A minority simulate a larger space, or range-clamp the shift;
Some will treat negative shifts like large positive shifts, others will
treat it as a shift in the opposite direction, ...
Though, there isn't much precedent for code to rely on the behavior of
out-of-range shifts.
And, seemingly this was one area where compilers would differ between
constant and non-constant shifts (say, non-constant shifts following the
Mod-N behavior, but constant shifts following a
negative-reverses-direction and saturate to maximum value) approach
(with newer compilers typically generating a warning about the shift
being too large or negative).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-24 16:13 -0700 |
| Message-ID | <1140rjb$11v1l$1@kst.eternal-september.org> |
| In reply to | #400388 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-07-23 23:31, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> You are thinking of code like :
>>>
>>> int x = *p;
>>> if (!p) return someone_made_a_mistake;
>>> ...
>>>
>>> Some compilers will skip the check here, because they assume the
>>> hardware / OS will have caught the attempt to access address 0. That
>>> is fair enough - /if/ the target is guaranteed to have such a hardware
>>> catch. If it is not guaranteed, then the check can't be skipped.
>> Yes, it can. A conforming compiler can omit the (!p) test because
>> the
>> behavior is undefined, not (necessarily) because of the behavior of the
>> target system.
>
> (I've seen you posted two followups on above. - No comment on
> all that.)
>
>>> Even better, of course, would be a compiler warning that the
>>> programmer is doing something silly - whether or not the check is
>>> skipped.
>> Certainly a warning would be nice. The problem is that unexpected
>> optimizations in the presence of undefined behavior don't always occur
>> because the compiler *knows* that the behavior is undefined.
>
> This thought or reasoning sounds completely perverted. - If the
> compiler *knows* that there's undefined behavior (that may lead
> to non-equivalent (=illegitimate) [dangerous] transformations!)
> a warning (or error message) should be *mandated* in any case!
> Without such a notice any "optimizations" (based on bizarre and
> hazardous assumptions) should never be performed! - Certainly a
> warning would not only be "nice" but should be mandated. - YMMV.
In the case we're discussing:
int x = *p;
if (!p) return someone_made_a_mistake;
the compiler can't know that there's undefined behavior, because
if p is a valid pointer the behavior is undefined.
If a compiler actually proves that the behavior of a construct is
undefined, then I agree that it should issue a warning (perhaps
controlled by options) -- though the standard never requires warnings,
other than for the new #warning directive. I've seen warnings about
constructs with undefined behavior, for example for `i++ + ++i`.
Here, if the value of p is not known at compile time, a compiler
may *assume* that the code has well-defined behavior, in this case
that p is a valid non-null pointer. If p is actually non-null and
valid at run time, there's no problem; the resulting code will
behave correctly. If p is null (due to a bug), the behavior is
undefined, and any actual behavior is "correct".
Testing whether p is a null pointer *after* attempting to dereference
it is clearly a programming bug. Of course I want my compiler
to warn me about any bugs in my code and not waste my time with
warnings I don't care about, but that's not always practical.
> It probably just boils down to the fact that the C-folks seem to
> imply another meaning of "optimization", meaning more something
> like "mutation of the code to something functionally different".
>
> Or, as it appear to me, that (with the knowledge of the inherent
> problems to overcome the issues) accommodated to the situation.
>
> Given what "C" actually is (and what it can *not* become) I don't
> think it makes sense to continue arguing about what I consider to
> be just the crazy facts of ("C"-)reality.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-07-26 15:26 -0500 |
| Message-ID | <1145qof$2mabd$1@dont-email.me> |
| In reply to | #400364 |
On 7/23/2026 3:31 AM, David Brown wrote:
> On 23/07/2026 01:08, BGB wrote:
>> On 7/22/2026 3:41 AM, David Brown wrote:
>>> On 22/07/2026 07:33, Janis Papanagnou wrote:
>>>> On 2026-07-22 02:26, Keith Thompson wrote:
>>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>>>> There was some recent longish thread with discussions addressing
>>>>>> Undefined Behavior. I just stumbled across a paper from Russ Cox
>>>>>> on that topic with a provoking title. [...]
>>>>>
>>>>> For those who don't follow the link, the full title of the paper is
>>>>> "C and C++ Prioritize Performance over Correctness". (Your
>>>>> paraphrase could be interpreted as advice, which I'm sure is not
>>>>> how you intended it.)
>>>>
>>>> It was actually a (deliberate) "marketing trick" to provoke interest
>>>> by reducing the title to an (IMO) yet more aggravating formulation.
>>>>
>>>> Yes, it was not my intention to suggest performance over correctness.
>>>> (Would anyone?)
>>>>
>>>
>>> Unfortunately, the answer to your final question is yes - and that is
>>> one of the reasons UB can be a problem. If by "correctness" you mean
>>> "code does what it should", people do sometimes release code that
>>> they know has bugs, but they know that fixing them would slow down
>>> the code - perhaps it is still good enough for their purposes at the
>>> time.
>>>
>>
>> Or, the cliche: "It's not a bug, it's a feature..."
>>
>
> Possibly.
>
> But it is always important to remember that different types of software
> require different levels of quality control - it can be acceptable to
> have known bugs ("undocumented features" or "undocumented limitations")
> in some software. If video games were coded with the same level of care
> used for jet engine controllers, they would never make it to market.
>
Possibly...
Video Games are more:
Looks about right;
Lacks obvious/glaring faults from the user POV;
Timing is "fast and consistent enough that user doesn't get annoyed".
Perfection is unrealistic to achieve in some spaces.
>>
>>> More relevant to this discussion, if by "correct" code you mean code
>>> that has fully defined or appropriate implementation-defined
>>> behaviour (most code does not need to be fully portable) according to
>>> the C standards and/or platform or compiler extended semantics, then
>>> it is absolutely the case that programmers regularly prioritise
>>> performance over correctness by relying on UB. The result is code
>>> that works efficiently and as intended at the time, using tools
>>> tested by the developer. Then the UB bites the next person down the
>>> road that uses the same code in good faith, but with a different
>>> compiler or different options.
>>>
>>
>>
>> Well, or for example, this pile of wonk:
>>
>> #define gfxedit_getu16(ptr) (*(vol_u16p)(ptr))
>> #define gfxedit_getu32(ptr) (*(vol_u32p)(ptr))
>> #define gfxedit_getu64(ptr) (*(vol_u64p)(ptr))
>> #define gfxedit_setu16(ptr,val) (*(vol_u16p)(ptr)=(val))
>> #define gfxedit_setu32(ptr,val) (*(vol_u32p)(ptr)=(val))
>> #define gfxedit_setu64(ptr,val) (*(vol_u64p)(ptr)=(val))
>>
>> Insert other versions for different platform constraints.
>
> While details of volatile accesses are implementation-dependent, they
> can be a successful way of accessing the underlying memory for data.
> It's easy to get things wrong, however, if you are not consistent about
> it. And too much use can lead to inefficiencies as well.
>
Yeah.
Though mostly does achieve a primary goal:
Works on compilers that are otherwise more aggressive about optimization;
Doesn't severely penalize those which fail to optimize away things like
"memcpy()" calls.
>>
>> But, say:
>> u64 gfxedit_getu64(void *ptr)
>> { u64 v; memcpy(&v, ptr, 8); return(v); }
>> Being also possible, but a significant performance penalty on some
>> targets.
>>
>
> That's the challenge. memcpy() is often a good, safe and correct way to
> access data as though it were a different type, but not all compilers
> optimise it well in such cases. Making code that is correct on a range
> of implementations, and also efficient on a range of implementations, is
> the hard part. So sometimes people end up with code that is efficienct
> on the implementations they use, works on those, but is reliant on UB
> and fails on other implementations.
>
Such is the never-ending issue.
How clever a compiler is with "memcpy()" is highly variable, some able
to fully optimize it away, and some just sorta falling back to a normal
function call (potentially very slow).
A lot of others are partway between.
>> The situation is potentially much worse for big endian machines, but
>> these are rare at this point.
>>
>> Say:
>> u16 gfxedit_getu16(void *ptr)
>> { u16 v; v=((byte *)ptr)[0]|
>> (((u16)((byte *)ptr)[1]))<<8); return(v); }
>> u32 gfxedit_getu32(void *ptr)
>> { u32 v; v=gfxedit_getu16(ptr)|
>> (((u32)gfxedit_getu16(((byte *)ptr)+2))<<16); return(v); }
>> u64 gfxedit_getu64(void *ptr)
>> { u64 v; v=gfxedit_getu32(ptr)|
>> (((u64)gfxedit_getu32(((byte *)ptr)+4))<<32); return(v); }
>>
>> Though, for BE machines, one wouldn't want to overuse these.
>>
>
> On good modern compilers, that sort of thing is usually fine, and you
> would expect it to reduce to a single "load 64-bit with endian swap"
> instruction or minimal similar sequence.
>
Depends some on machine:
Support or non-support for misaligned access;
Whether or not the ISA supports endian swap instructions.
For example, consider an ISA like SH-2, one would likely need to do
something like (probable best case to load a 32-bit LE value):
gfxedit_getu32:
MOVU.B @R4+, R7
MOVU.B @R4+, R6
MOVU.B @R4+, R5
MOVU.B @R4+, R0
SHLL8 R0
OR R5, R0
SHLL8 R0
OR R6, R0
SHLL8 R0
OR R7, R0
RTS
Well, in part because the ISA is fairly limited. Aligned-only big-endian
ISA, no byte-swap instructions, not even a general purpose integer shift.
Say:
int a, b, c;
c=a+b; //2 ops
c=a-b; //2 ops
c=a&b; //2 ops
c=a|b; //2 ops
c=a^b; //2 ops
c=a*b; //runtime call (shift-add loop)
c=a/b; //runtime call (shift-sub loop)
c=a<<b; //runtime call (computed branch and slide)
c=a>>b; //runtime call (computed branch and slide)
> As I see it, the main problem of UB and compilers is /not/ as commonly
> believed, overly-enthusiastic compilers that optimise on assumptions
> about UB. The problem is poorer or older compilers that don't optimise
> the correct code well, forcing people who need efficient results to
> spend a lot of effort finding alternative solutions that might be
> reliant on UB. It also doesn't help that some developers don't enable
> optimisation or otherwise fail to use their tools well.
>
Yeah.
I am assuming here compilers that will optimize when optimizations are
enabled, but the scope of said optimizations is limited.
>
> <snip code>
>
>>
>> But, on the relevant implementation, trying to do the latter being
>> around an order of magnitude slower...
>
> It sounds like it might make more sense to write improved memcpy, memove
> and memset implementations for the implementation in question!
>
The main offender here was (ironically) MSVC, as seemingly their
implementations are built under the assumptions of small numbers of big
copies and not large numbers of small moves or similar. Not really dug
into MSVCRT's implementation, but (from cases where the debugger has
landed on it), their priority is usually to try to get things as quickly
as possible into SSE-based copy loops, which admittedly does make the
most sense if one assumes the copy is large by default.
This is part of why the "memlzcpyf" style copies are wonky:
Determining the correct logic for the copy is often a bigger factor than
the copy operation itself (huge numbers of often 4-14 byte copies).
Likewise, trying to use something like SSE/AVX on x86-64 makes little
sense here, given the copies are frequently smaller than the size of the
SIMD vector.
But, say, moving 64-bit chunks around costs less than moving individual
bytes.
>>
>> So, it can all turn into a big mess of cruft and ifdef's.
>>
>
> Maximum efficiency is /always/ going to be implementation and target
> dependent. It is fine, for low-level functions where the speed matters,
> to have a variety of implementations tuned to different targets, with
> fall-back to something that is correct portable code. The use of
> #ifdef's (or separate files) means you can also happily use compiler-
> specific extensions, pragmas, attributes, builtins, etc., or even inline
> assembly.
>
Yes.
Also it is an incentive for why (on my targets) "_memlzcpy()" and
"_memlzcpyf()" exist as library extensions.
This wonk can more leverage the ISA-specific quirks.
Though, if the code needs to run on other targets (like Windows, Linux,
etc), it can't use these and needs to provide its own.
A lot of wonk in things like my OpenGL implementation as well, where
there is a whole lot of non-portable edge cases and ASM alongside
generic ASM fallbacks.
>>> The killer point, however, is when you have received some code that
>>> you can justifiably assume is correct and well tested, but contains
>>> reliance on how certain types of UB happen to be implemented. It is
>>> not really any different than code that makes other undocumented
>>> assumptions, such as implementation-dependent details, reliance on
>>> certain files or OS features, timing requirements, etc. And
>>> compiling with "-fwrapv -fno- strict-aliasing" (if you are using a
>>> compiler that supports such features) will mitigate the most common
>>> cases of reliance on UB.
>>>
>>
>> In some cases, it makes sense to assume that some things formally
>> considered UB would be better considered as Implementation Defined.
>
> No, never. You might want that to be the case (and I am sure we all
> have our personal favourite UB's from the C standards that we would
> rather have as IB, or unspecified, or the up-coming "erroneous
> behaviour" - though we would not agree entirely on which UB's). But you
> can't just say "I think left-shift of negative numbers should be IB" and
> assume it to be the case!
>
Not in writing portable code, but you can if writing your own compiler...
>>
>> In practice, it likely wouldn't make that big of a difference; since
>> many cases the compiler still treats these cases is implementation
>> defined rather than true UB.
>>
>
> Particular implementations can, of course, document the way a particular
> type of UB is implemented - then when you are using that compiler, you
> can rely on that behaviour.
>
> Relying on undocumented treatment of UB is where you get in trouble. The
> code might work as you want with this version of the compiler, and fail
> with the next version.
>
I guess I was ambiguous, was assuming cases where a person controls both
ends of the software stack.
I can make the UB be IB for my compiler, even if I can't change what GCC
or MSVC does.
Though, MSVC will not usually change things that will break large
amounts of legacy code; so most "legacy-established" UB is likely
"safe-ish" on those targets.
It is usually GCC and Clang that like to break stuff in this way.
>>
>> But, I had seen non-zero code which had relied on the assumption of
>> overflows carrying over consistently between global arrays.
>>
>
> Relying on the details of how generated assembly is organised is a high-
> risk game. I have had occasions when I needed to do so, but it's
> tightly tied to exact tool versions and flags, and needs checking for
> every run of the build.
>
Where I encountered it was in some code written originally for the
Watcom C compiler on DOS.
I ended up rewriting this part, as this behavior fell outside the scope
of what I considered reasonable, even for legacy...
The other challenge was partly also trying to eliminate all of the
out-of-bounds without changing program behavior in ways that would cause
the previous demo-recordings to desync.
Well, because back in those days the popular way to do demo recordings
was to record user keypresses, then run the game back later but replay
it as-if the user were pressing the same keys at the same time, which is
kind of notorious, particularly in the face of engines which don't have
a particularly consistent timing-tick system (and are instead driving
everything off of the current "wall-clock" time, originally relying on
the timer IRQ to increment a global variable holding the current time,
etc...).
Well, and then that engine also did the annoying thing in that rather
than use the standard "Mode 0x13" memory layout (320x200 linear buffer
in raster order), whole engine was based on setting up a 320x200 planar
mode and assuming plane-manipulation for drawing; so porting it needed
to make wrappers to mimic the original VGA behavior here.
Ended up staying with 256-color in this engine, partly as the engine
also relied on some effects dynamically changing or updating the color
palette (more so than for the "screen flashes" Doom and similar had used).
>>
>>>
>>> As for the paper itself, I have a few points.
>>>
>>> It follows the time-worn path of complaining that "modern" compilers
>>> have distorted the "original" idea of UB and abuse it for
>>> optimisation in ways that are dangerous to the uninitiated. First,
>>> optimisation using UB is not new - I first used a compiler that
>>> assumed integer overflow does not wrap over thirty years ago.
>>> Second, compilers already default to "-O0" - if you know so little
>>> about your tools that you can't enable warnings, you won't have
>>> optimisation either. Third, improvements in compiler optimisation
>>> have gone hand-in-hand with improvements in compiler static error
>>> checking. Using "-Wall" along with optimisation will eliminate the
>>> solid majority of the risks and worries of the author. Fourth, the
>>> development of "sanitizers" not only allows far more UB to be found
>>> during testing, but it allows far more bugs to be found than would be
>>> possible if the mistakes were / not/ UB - "-fsanitize=signed-integer-
>>> overflow" catches overflow bugs precisely because it is UB in C,
>>> whereas if it were defines as wrapping then the mistake in the
>>> programmer's code would be correct as far as the language is concerned.
>>>
>>
>> For keeping old code working, it makes sense to assume wrapping.
>
> To be clear - you mean that if you don't know the old code, it makes
> sense to assume the code might rely on wrapping behaviour, and use
> appropriate compiler flags (or add appropriate pragmas) ?
>
Or, if writing a C compiler, to assume that wrap on overflow is the most
sensible default here.
And, not "UB nasal demons", which may make sense to assume for a
programmer writing portable code, but is not a good stance for a
compiler writer.
>>
>> But, maybe it could make sense to have a semantic distinction for
>> cases where wrapping is assumed vs where it is likely unintentional.
>>
>> My proposal, if any, would be, say:
>> If "signed" is used explicitly, it means wrap-on-overflow is expected.
>
> That makes no sense at all.
>
I am not sure I see why it would be a problem as a working assumption.
One can just sorta add a semantic distinction between 'int' and 'signed
int' in a similar way to the whole 'char' vs 'signed char' thing...
Granted, many compilers (mine included) don't currently have such a
distinction, nor does my type-tagging scheme, but also in this case it
assumes wrap-on-overflow as universal, so there is no loss.
It only really becomes necessary if one wants both existing code to keep
working, and to have the option for separate "trap on overflow" handling
or similar.
>>
>> So, say:
>> int i;
>> signed int v;
>> If 'i' overflows, one can question whether or not it was intended; but
>> if 'v' overflows, assume it is intentional (as with 'unsigned').
>
> You can't just invent a personal convention like that - at least, not if
> you ever use other people's code or compilers written by someone else.
> You can't change the meaning of existing code.
>
> If C were ever to have support for something akin to that, I would
> expect to see new names involved. It would be "_Wrapping int v;", or
> types "int_wrapping32_t" in <stdint.h>.
>
> More likely, functions like "wrapping_add" could be added to <stdckdint.h>.
>
Existing code will not care, as either way it is basically the same as
what happens already in practice.
It would ironically make more sense in practice as a way to allow making
"int" *not* wrapping, and to be able to have int overflow as an actually
useful diagnostic, rather than something that just happens randomly all
over the place.
Then one could "sanitize" it by sticking 'signed' on the cases where
overflows are happening and are intentional.
Creating new keywords here is possible, but likely to be more hassle
than it is worth in terms of compatibility or adoption.
Like, one could be like:
_Wrapinng, _NoWrapping, ...
But, a similar argument could be made for, say:
_Aligned, _Unaligned
Or:
_LittleEndian, _BigEndian
These being cases that could be useful to be able to specify, but no one
is likely to do so.
At least "signed" is more likely to come for cheap/free:
The "new" semantics match existing behavior on typical implementations;
A fair amount of code already follows this pattern implicitly (even if
there is no actual reason for why it would be so).
In this case, it is mapping semantics to existing coding patterns,
rather than merely making something up ex-nihilo.
Like, not like I am just making up how all this stuff works as I was
going along (and, if I were just making crap up, would generally make
porting efforts a bit more of a pain).
>>
>> This being in part because an explicit "signed" keyword is uncommon to
>> be used with normal counting/index type variables.
>>
>
> Some people use it - and they do not do so with the expectation of
> different semantics than when it is omitted. Some people write "signed"
> rather than "int" for declarations.
>
Possibly.
But, as noted, it would make more sense as a code diagnostic feature.
Otherwise, one would expect such code to break with "-fwrapv" or similar
in GCC, if they depended on some behavior other than wrapping.
In general, I have usually seen bare 'int' for things like counters and
similar, or the things that are probably not expected to overflow.
But, then explicit 'signed' are more often used for things like
fixed-point coordinates and similar, which typically do overflow.
>>>
>>> Don't dereference null pointers. It's a bad idea.
>>>
>>
>> Dereferencing NULL is one of those cases where the most sensible
>> option is to treat it as a fault...
>
> It's a bug.
>
NULL is one of the few cases where it is unambiguous...
Well, except maybe on Win95 where like the low 1MB of addresses held a
copy of the MS-DOS memory map.
Well, and (from very old memories) you could craft a FAR jump to get
into supervisor mode (Ring 0) while transferring control back to ones'
own code, to get ahold of the GDT and LDT and peek in on Win16 space and
similar.
These holes didn't exist on NT though.
>>
>> Most sensible option is to assume that trying to dereference NULL is
>> unintentional (given the main purpose of NULL being as a "this object
>> doesn't exist" pointer).
>>
>
> Yes.
>
> There is the exception that on some hardware, 0 is a valid memory
> address and you might want to access it. On microcontrollers, it is not
> uncommon for code flash to start there, so something like an integrity
> check of the program would have to read that address. Then you are
> dereferencing a pointer that happens to have value 0, rather than a null
> pointer.
>
Yeah, the Boot ROM in my ISA project is also like this:
00000000..00007FFF: ROM space
00008000..0000BFFF: Optional, Extended ROM space
0000C000..0000DFFF: Boot-Time SRAM
00010000..0001FFFF: Zeroes (This address range always reads as 0)
00020000..00FFFFFF: Mostly unused, special repeating-pattern pages
01000000..7FFFFFFF: DRAM goes here
Though, not the whole DRAM range contains actual valid RAM, so it is
more like, say:
01000000..03FFFFFF: First DRAM Copy
04000000..07FFFFFF: Second DRAM Copy
...
The DRAM just repeating up to the 2GB mark or similar.
The Boot ROM uses this for its RAM counter, where it detects the point
where RAM wraps around again, and uses this as its size limit.
The Boot ROM starts at 0, containing a branch to _start or similar.
As a hack the CPU also uses the encoding of this instruction to know
what ISA mode to boot into for the ROM (XG1, XG3, or RV64GC).
I may change the memory map in the future, possibly:
00000000..0000FFFF: ROM space
00010000..0007FFFF: Optional, Extended ROM space
00080000..0008FFFF: Zeroes (This address range always reads as 0)
00090000..000FFFFF: Unused, probably just more zeroes
00100000..7FFFFFFF: DRAM goes here
Though, this is likely to also coincide with dropping XG1 and making the
CPU always boot in XG3 Mode. The Boot ROM is primarily a use-case
favoring code density, so for a while RV64GC was the front-runner, but
XG3 caught up (and has fewer drawbacks).
Decided to omit going on too much more about the memory map or virtual
memory subsystem.
But, in effect, mostly using larger 48-bit VAS on hardware that could
realistically have been a 32-bit machine. But, not like there are any
FPGA boards with GB of RAM.
Instead, it is more like MB of RAM, plus a pagefile backed to an SDcard.
>> But:
>> Assuming it doesn't happen and then removing the offending code path
>> entirely is also bad IMO. However, turning the code-path into a break
>> instruction or similar (following any other externally visible side
>> effects) would still likely be acceptable IMO (or, at least, less bad
>> in this case than just continuing down the other path as if nothing
>> had ever happened).
>>
>
> You are thinking of code like :
>
> int x = *p;
> if (!p) return someone_made_a_mistake;
> ...
>
> Some compilers will skip the check here, because they assume the
> hardware / OS will have caught the attempt to access address 0. That is
> fair enough - /if/ the target is guaranteed to have such a hardware
> catch. If it is not guaranteed, then the check can't be skipped. Even
> better, of course, would be a compiler warning that the programmer is
> doing something silly - whether or not the check is skipped.
>
> I agree that sometimes a "break" (or "trap", or similar) instruction can
> be a good thing for compilers to generate when they are clearly
> executing undefined behaviour. But I am not convinced it is always a
> good idea (I would not want it for this case), and it would be hard to
> specify and guarantee the circumstances without it ruining the
> possibility of optimisation from assuming code has defined behaviour.
>
> Compilers with sanitizers do support such traps - gcc with the options
> "-fsanitize-trap=all -fsanitize=null" will trap if the pointer "p" is
> null in this code.
>
>
Possibly...
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-07-23 11:18 +0200 |
| Message-ID | <113sm8v$3mu1j$1@dont-email.me> |
| In reply to | #400349 |
On 2026-07-22 10:41, David Brown wrote: > On 22/07/2026 07:33, Janis Papanagnou wrote: >> On 2026-07-22 02:26, Keith Thompson wrote: >>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>>> There was some recent longish thread with discussions addressing >>>> Undefined Behavior. I just stumbled across a paper from Russ Cox >>>> on that topic with a provoking title. [...] >>> >>> For those who don't follow the link, the full title of the paper is >>> "C and C++ Prioritize Performance over Correctness". (Your >>> paraphrase could be interpreted as advice, which I'm sure is not >>> how you intended it.) >> >> It was actually a (deliberate) "marketing trick" to provoke interest >> by reducing the title to an (IMO) yet more aggravating formulation. >> >> Yes, it was not my intention to suggest performance over correctness. >> (Would anyone?) >> > > Unfortunately, the answer to your final question is yes - In that stripped down and generalized formulation that is true; after posting there immediately formed an image in my mind of companies that have a fast time-to-market strategy as a primary goal on their agenda, and with the help of a strong marketing divisions, and with a crowd of believers in their software products that obviously works (as a couple of prominent vendors proved over decades). My own views on correctness may be (too?) altruistic here, and "peephole" performance tweaks (from aggressively "optimizing" compilers) were rarely an issue.[*] > and that is one of the reasons UB can be a problem. I took Keith's hint as me not having intended to _generally_ suggest performance over correctness. (And he was right, as I said.) In my OP I wrote: "A couple arguments and examples look familiar already, [...].", so it's not that surprising that in your thorough reply you cover arguments previously discussed already. My own opinion on "C" and "its UB" is meanwhile consolidated by the various statements in the previous thread already so - please bear with me - I'll abstain from commenting on details of your post, but thanks for the write-up. Janis [*] We used to approach performance topics primarily by the choice of algorithms and by appropriate data structuring, and in rare cases by optimized isolated modules written in another language (mainly "C"), or in some specific cases also by mathematical or logical functional transformations of algorithms. > [...]
[toc] | [prev] | [standalone]
Page 10 of 10 — ← Prev page 1 … 8 9 [10]
Back to top | Article view | comp.lang.c
csiph-web