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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-07-28 20:31 -0400 |
| Message-ID | <114bhki$g5po$1@dont-email.me> |
| In reply to | #400485 |
On 2026-07-28 17:00, Johann 'Myrkraverk' Oskarsson wrote:
> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
...>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
NULL is required to be a null pointer constant, for which there are only
two options,
1) an integer constant expression with a value of 0.
or
2) such an expression converted to (void*)
Since 0xDEADBEEF doesn't have a value of 0, it doesn't qualify.
However, is is permissible for the representation of a null pointer to
be the same as the representation of 0xDEADBEEF in one of the integer
types. I'll assume that's what you actually meant, and that NULL is in
fact #defined in a way that conforms to the C standard, such as (10L -
'\012').
>> pointer type,
>>
>> if (! p) { }
>>
>> is basically converted to:
>>
>> if (p == NULL) { }
More accurately, "p == 0". Since 0 and NULL are both null pointer
constants, it shouldn't make any difference, but the actual wording used
by the standard corresponds to "p == 0".
> Now implement
>
> if ( p )
>
> as not
>
> if ( ( int ) p ) ; // !
Yes, that would be an incorrect way of implementing if(p) on such a
platform.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-28 21:26 -0700 |
| Message-ID | <114bvdr$j594$1@kst.eternal-september.org> |
| In reply to | #400497 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2026-07-28 17:00, Johann 'Myrkraverk' Oskarsson wrote:
>> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
> ...>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
>
>
> NULL is required to be a null pointer constant, for which there are only
> two options,
> 1) an integer constant expression with a value of 0.
> or
> 2) such an expression converted to (void*)
As of C23, a null pointer constant can be an integer constant expression
with the value 0, such an expression cast to void*, or the predefined
constant nullptr. (POSIX imposes some additional requirements.)
`(void*)nullptr` is guaranteed to evaluate to a null pointer, but it's
not a null pointer constant.
Note that `(void*)0` is a null pointer constant, but it doesn't qualify
as a definition of the NULL macro. 7.1.2 requires any definition of an
object-like macro in the standard library to "expand to code that is
fully protected by parentheses where necessary, so that it groups in an
arbitrary expression as if it were a single identifier".
Any of `0`, `((void*)0)`, or `nullptr` would be a reasonable expansion
for NULL. Unreasonable but valid definitions include:
#define NULL ('/'/'/'-'/'/'/')
#define NULL (1+1==3)
> Since 0xDEADBEEF doesn't have a value of 0, it doesn't qualify.
Right. It's easy (but incorrect) to assume a correlation between
the fact that a constant 0 (in source code) is a null pointer
constant, and the fact that all-bits-zero (during execution)
is very commonly a representation for a null pointer. There are
historical reasons, but the language is careful does not require
any particular representation for a runtime null pointer.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-07-29 14:57 -0700 |
| Message-ID | <114dsvh$17hcv$2@dont-email.me> |
| In reply to | #400500 |
On 7/28/2026 9:26 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 2026-07-28 17:00, Johann 'Myrkraverk' Oskarsson wrote:
>>> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
>> ...>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
>>
>>
>> NULL is required to be a null pointer constant, for which there are only
>> two options,
>> 1) an integer constant expression with a value of 0.
>> or
>> 2) such an expression converted to (void*)
>
> As of C23, a null pointer constant can be an integer constant expression
> with the value 0, such an expression cast to void*, or the predefined
> constant nullptr. (POSIX imposes some additional requirements.)
>
> `(void*)nullptr` is guaranteed to evaluate to a null pointer, but it's
> not a null pointer constant.
>
> Note that `(void*)0` is a null pointer constant, but it doesn't qualify
> as a definition of the NULL macro. 7.1.2 requires any definition of an
> object-like macro in the standard library to "expand to code that is
> fully protected by parentheses where necessary, so that it groups in an
> arbitrary expression as if it were a single identifier".
>
> Any of `0`, `((void*)0)`, or `nullptr` would be a reasonable expansion
> for NULL. Unreasonable but valid definitions include:
>
> #define NULL ('/'/'/'-'/'/'/')
> #define NULL (1+1==3)
>
>> Since 0xDEADBEEF doesn't have a value of 0, it doesn't qualify.
>
> Right. It's easy (but incorrect) to assume a correlation between
> the fact that a constant 0 (in source code) is a null pointer
> constant, and the fact that all-bits-zero (during execution)
> is very commonly a representation for a null pointer. There are
> historical reasons, but the language is careful does not require
> any particular representation for a runtime null pointer.
>
> [...]
>
The bits of the raw NULL does not have to be 0.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-29 15:33 -0700 |
| Message-ID | <114dv4l$18198$1@kst.eternal-september.org> |
| In reply to | #400569 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 7/28/2026 9:26 PM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>> On 2026-07-28 17:00, Johann 'Myrkraverk' Oskarsson wrote:
>>>> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
>>> ...>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
>>> NULL is required to be a null pointer constant, for which there are only
>>> two options,
>>> 1) an integer constant expression with a value of 0.
>>> or
>>> 2) such an expression converted to (void*)
>>
>> As of C23, a null pointer constant can be an integer constant
>> expression with the value 0, such an expression cast to void*, or the
>> predefined constant nullptr. (POSIX imposes some additional
>> requirements.) `(void*)nullptr` is guaranteed to evaluate to a null
>> pointer, but it's not a null pointer constant. Note that `(void*)0`
>> is a null pointer constant, but it doesn't qualify as a definition of
>> the NULL macro. 7.1.2 requires any definition of an object-like
>> macro in the standard library to "expand to code that is fully
>> protected by parentheses where necessary, so that it groups in an
>> arbitrary expression as if it were a single identifier".
>>
>> Any of `0`, `((void*)0)`, or `nullptr` would be a reasonable
>> expansion for NULL. Unreasonable but valid definitions include:
>>
>> #define NULL ('/'/'/'-'/'/'/')
>> #define NULL (1+1==3)
>>
>>> Since 0xDEADBEEF doesn't have a value of 0, it doesn't qualify.
>>
>> Right. It's easy (but incorrect) to assume a correlation between
>> the fact that a constant 0 (in source code) is a null pointer
>> constant, and the fact that all-bits-zero (during execution)
>> is very commonly a representation for a null pointer. There are
>> historical reasons, but the language is careful does not require
>> any particular representation for a runtime null pointer.
>> [...]
>
> The bits of the raw NULL does not have to be 0.
You're restating something that was already clearly stated in this
thread, and you're doing it incorrectly.
The NULL macro is a source code construct. It doesn't have "bits",
unless you count the bits making up the characters 'N', 'U', 'L',
'L' (in the source character set, which needn't match the execution
character set).
The thing whose bits don't have to be 0 is a null pointer *value*,
something that exists during execution and can result from an
occurence of NULL in the source code.
The point from upthread is that your suggested (void*)0xDEADBEEF
is not a null pointer constant, and therefore is not a valid
expansion of the NULL macro, *even if* 0xDEADBEEF matches the
run-time representation of a null pointer.
(I normally ignore your posts, but I made an arbitrary exception
in this case.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-07-29 16:22 -0700 |
| Message-ID | <114e20i$190bc$1@dont-email.me> |
| In reply to | #400571 |
On 7/29/2026 3:33 PM, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 7/28/2026 9:26 PM, Keith Thompson wrote:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>> On 2026-07-28 17:00, Johann 'Myrkraverk' Oskarsson wrote:
>>>>> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
>>>> ...>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
>>>> NULL is required to be a null pointer constant, for which there are only
>>>> two options,
>>>> 1) an integer constant expression with a value of 0.
>>>> or
>>>> 2) such an expression converted to (void*)
>>>
>>> As of C23, a null pointer constant can be an integer constant
>>> expression with the value 0, such an expression cast to void*, or the
>>> predefined constant nullptr. (POSIX imposes some additional
>>> requirements.) `(void*)nullptr` is guaranteed to evaluate to a null
>>> pointer, but it's not a null pointer constant. Note that `(void*)0`
>>> is a null pointer constant, but it doesn't qualify as a definition of
>>> the NULL macro. 7.1.2 requires any definition of an object-like
>>> macro in the standard library to "expand to code that is fully
>>> protected by parentheses where necessary, so that it groups in an
>>> arbitrary expression as if it were a single identifier".
>>>
>>> Any of `0`, `((void*)0)`, or `nullptr` would be a reasonable
>>> expansion for NULL. Unreasonable but valid definitions include:
>>>
>>> #define NULL ('/'/'/'-'/'/'/')
>>> #define NULL (1+1==3)
>>>
>>>> Since 0xDEADBEEF doesn't have a value of 0, it doesn't qualify.
>>>
>>> Right. It's easy (but incorrect) to assume a correlation between
>>> the fact that a constant 0 (in source code) is a null pointer
>>> constant, and the fact that all-bits-zero (during execution)
>>> is very commonly a representation for a null pointer. There are
>>> historical reasons, but the language is careful does not require
>>> any particular representation for a runtime null pointer.
>>> [...]
>>
>> The bits of the raw NULL does not have to be 0.
>
> You're restating something that was already clearly stated in this
> thread, and you're doing it incorrectly.
>
> The NULL macro is a source code construct. It doesn't have "bits",
> unless you count the bits making up the characters 'N', 'U', 'L',
> 'L' (in the source character set, which needn't match the execution
> character set).
>
> The thing whose bits don't have to be 0 is a null pointer *value*,
> something that exists during execution and can result from an
> occurence of NULL in the source code.
>
> The point from upthread is that your suggested (void*)0xDEADBEEF
> is not a null pointer constant, and therefore is not a valid
> expansion of the NULL macro, *even if* 0xDEADBEEF matches the
> run-time representation of a null pointer.
>
> (I normally ignore your posts, but I made an arbitrary exception
> in this case.)
>
At the system level under C, a NULL can boil down to a pointer value
equal to 0xDEADBEEF. So, the compiler needs to handle that.
at the low level:
if (! p) if p is a pointer type:
if (! __compare_ptr_to_null(p))
deep inside it compares it to 0xDEADBEEF
a system null ptr can be 0xDEADBEEF. This is lower level than the C std.
The compiler just needs to handle it. __compare_ptr_to_null(p) can be a
stub for another pass for if (p == PLATFORM_NULL_BITPATTERN)
Fair enough?
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2026-07-30 07:40 +0100 |
| Message-ID | <114erk4$1gduv$1@dont-email.me> |
| In reply to | #400571 |
On 29/07/2026 23:33, Keith Thompson wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 7/28/2026 9:26 PM, Keith Thompson wrote:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>> On 2026-07-28 17:00, Johann 'Myrkraverk' Oskarsson wrote:
>>>>> On 29/07/2026 4:54 AM, Chris M. Thomasson wrote:
>>>> ...>> say NULL is (void*)0xDEADBEEF, or whatever, for a system. Then for a
>>>> NULL is required to be a null pointer constant, for which there are only
>>>> two options,
>>>> 1) an integer constant expression with a value of 0.
>>>> or
>>>> 2) such an expression converted to (void*)
>>>
>>> As of C23, a null pointer constant can be an integer constant
>>> expression with the value 0, such an expression cast to void*, or the
>>> predefined constant nullptr. (POSIX imposes some additional
>>> requirements.) `(void*)nullptr` is guaranteed to evaluate to a null
>>> pointer, but it's not a null pointer constant. Note that `(void*)0`
>>> is a null pointer constant, but it doesn't qualify as a definition of
>>> the NULL macro. 7.1.2 requires any definition of an object-like
>>> macro in the standard library to "expand to code that is fully
>>> protected by parentheses where necessary, so that it groups in an
>>> arbitrary expression as if it were a single identifier".
>>>
>>> Any of `0`, `((void*)0)`, or `nullptr` would be a reasonable
>>> expansion for NULL. Unreasonable but valid definitions include:
>>>
>>> #define NULL ('/'/'/'-'/'/'/')
>>> #define NULL (1+1==3)
>>>
>>>> Since 0xDEADBEEF doesn't have a value of 0, it doesn't qualify.
>>>
>>> Right. It's easy (but incorrect) to assume a correlation between
>>> the fact that a constant 0 (in source code) is a null pointer
>>> constant, and the fact that all-bits-zero (during execution)
>>> is very commonly a representation for a null pointer. There are
>>> historical reasons, but the language is careful does not require
>>> any particular representation for a runtime null pointer.
>>> [...]
>>
>> The bits of the raw NULL does not have to be 0.
>
> You're restating something that was already clearly stated in this
> thread, and you're doing it incorrectly.
>
> The NULL macro is a source code construct. It doesn't have "bits",
> unless you count the bits making up the characters 'N', 'U', 'L',
> 'L' (in the source character set, which needn't match the execution
> character set).
>
> The thing whose bits don't have to be 0 is a null pointer *value*,
> something that exists during execution and can result from an
> occurence of NULL in the source code.
>
> The point from upthread is that your suggested (void*)0xDEADBEEF
> is not a null pointer constant, and therefore is not a valid
> expansion of the NULL macro, *even if* 0xDEADBEEF matches the
> run-time representation of a null pointer.
>
> (I normally ignore your posts, but I made an arbitrary exception
> in this case.)
>
Can a pointer have a value of zero, but not be a null pointer?
This, for example, thinks that p ends up as a null pointer.
But there is no constant 0.
Probably I'm confused.
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
char *p = malloc(1);
printf("p = %p\n", (void*) p);
do
{
p--;
printf("p is%s null, p = %p\n", p ? " not" : "", (void*) p);
}
while (p);
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-07-30 06:48 +0000 |
| Subject | Re: Prioritize Correctness over Performance |
| Message-ID | <114es4e$1gg4f$1@dont-email.me> |
| In reply to | #400576 |
On Thu, 30 Jul 2026 07:40:04 +0100, Richard Harnden wrote: > Can a pointer have a value of zero, but not be a null pointer? C doesn’t define any special pointer values, other than the null pointer. The null pointer can be compared for equality with (a suitable cast of) the integer literal 0 (I’m not sure, it might be that arbitrary integer expressions evaluating to 0 are not allowed), but that is not considered grounds for concluding/requiring that the bit pattern for the null pointer is actually equal to the integer value 0.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-07-30 06:50 -0400 |
| Subject | Re: Prioritize Correctness over Performance |
| Message-ID | <114fa9e$1mred$1@dont-email.me> |
| In reply to | #400577 |
On 2026-07-30 02:48, Lawrence D’Oliveiro wrote: > On Thu, 30 Jul 2026 07:40:04 +0100, Richard Harnden wrote: > >> Can a pointer have a value of zero, but not be a null pointer? > > C doesn’t define any special pointer values, other than the null > pointer. The null pointer can be compared for equality with (a > suitable cast of) the integer literal 0 (I’m not sure, it might be > that arbitrary integer expressions evaluating to 0 are not allowed), True. Only integer constant expressions with a value of 0 qualify as null pointer constants. If an integer variable named zero had a value of zero, then "zero" is an integer expression with a value of zero, but because it's not a constant expression, conversion of "zero" to a pointer type is not guaranteed to produce a null pointer constant. However, on most implementations, especially those where a pointer object with all-bits-0 does represent a null pointer, that conversion is likely to produce one. You just need to remember that it's not required to do so. However, any integer constant expression, regardless of type, does qualify as a null pointer constant, even 1LL-'\001' > but that is not considered grounds for concluding/requiring that the > bit pattern for the null pointer is actually equal to the integer > value 0. Correct.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-30 03:54 -0700 |
| Subject | Re: Prioritize Correctness over Performance |
| Message-ID | <114fahd$1mrbt$2@kst.eternal-september.org> |
| In reply to | #400577 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Thu, 30 Jul 2026 07:40:04 +0100, Richard Harnden wrote:
>> Can a pointer have a value of zero, but not be a null pointer?
>
> C doesn’t define any special pointer values, other than the null
> pointer. The null pointer can be compared for equality with (a
> suitable cast of) the integer literal 0 (I’m not sure, it might be
> that arbitrary integer expressions evaluating to 0 are not allowed),
> but that is not considered grounds for concluding/requiring that the
> bit pattern for the null pointer is actually equal to the integer
> value 0.
Correct.
The only integer expressions that are null pointer constants are
constant integer expressions with the value 0, but they can be
arbitrarily complex (1-1, 1+1==3, '/'/'/'-'/'/'/'). A non-constant
integer expression that happens to yield 0 is not guaranteed to yield a
null pointer when converted to a pointer type. These:
void *np = (void*)0; // the cast isn't actually needed
int zero = 0;
void *fake_np = (void*)0;
can even assign different values to np and to fake_np. (That's
likely to happen only on implementations where a null pointer
is not represented as all-bits-zero; such an implementation would
have to treat constant expressions specially.)
--
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-30 08:24 -0400 |
| Subject | Re: Prioritize Correctness over Performance |
| Message-ID | <114ffq0$1otmb$1@dont-email.me> |
| In reply to | #400582 |
On 2026-07-30 06:54, Keith Thompson wrote: ...> void *np = (void*)0; // the cast isn't actually needed > int zero = 0; > void *fake_np = (void*)0; I suspect that you intended that to be (void*)zero. > can even assign different values to np and to fake_np.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-30 14:40 -0700 |
| Subject | Re: Prioritize Correctness over Performance |
| Message-ID | <114ggc3$25jib$2@kst.eternal-september.org> |
| In reply to | #400583 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2026-07-30 06:54, Keith Thompson wrote:
> ...> void *np = (void*)0; // the cast isn't actually needed
>> int zero = 0;
>> void *fake_np = (void*)0;
>
> I suspect that you intended that to be (void*)zero.
I did indeed. Thanks.
>> can even assign different values to np and to fake_np.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-07-30 19:39 -0700 |
| Subject | Re: Prioritize Correctness over Performance |
| Message-ID | <114h1ta$2b0po$1@dont-email.me> |
| In reply to | #400577 |
On 7/29/2026 11:48 PM, Lawrence D’Oliveiro wrote: > On Thu, 30 Jul 2026 07:40:04 +0100, Richard Harnden wrote: > >> Can a pointer have a value of zero, but not be a null pointer? > > C doesn’t define any special pointer values, other than the null > pointer. The null pointer can be compared for equality with (a > suitable cast of) the integer literal 0 (I’m not sure, it might be > that arbitrary integer expressions evaluating to 0 are not allowed), > but that is not considered grounds for concluding/requiring that the > bit pattern for the null pointer is actually equal to the integer > value 0. Yup.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-07-30 06:44 -0400 |
| Message-ID | <114f9up$1mm0c$1@dont-email.me> |
| In reply to | #400576 |
On 2026-07-30 02:40, Richard Harnden wrote: > On 29/07/2026 23:33, Keith Thompson wrote: ...>> The NULL macro is a source code construct. It doesn't have "bits", >> unless you count the bits making up the characters 'N', 'U', 'L', >> 'L' (in the source character set, which needn't match the execution >> character set). >> >> The thing whose bits don't have to be 0 is a null pointer *value*, >> something that exists during execution and can result from an >> occurence of NULL in the source code. >> >> The point from upthread is that your suggested (void*)0xDEADBEEF >> is not a null pointer constant, and therefore is not a valid >> expansion of the NULL macro, *even if* 0xDEADBEEF matches the >> run-time representation of a null pointer. >> >> (I normally ignore your posts, but I made an arbitrary exception >> in this case.) >> > > Can a pointer have a value of zero, but not be a null pointer? No, the value of a pointer is the location that it points at. It's value is never a number. It's representation, if misinterpreted as an integer type (which would require type punning), can be 0. On most implementations that representation would represent a null pointer, but it is entirely permitted for it to not be a null pointer, so long as there is some other representation that does represent a null pointer.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-07-30 21:00 +0000 |
| Message-ID | <114ge0v$24ndu$2@dont-email.me> |
| In reply to | #400579 |
On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote: > ... the value of a pointer is the location that it points at. It's > value is never a number. In C, its value is never *directly compatible* with a number.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-30 14:38 -0700 |
| Message-ID | <114gg7o$25jib$1@kst.eternal-september.org> |
| In reply to | #400613 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:
>> ... the value of a pointer is the location that it points at. It's
>> value is never a number.
>
> In C, its value is never *directly compatible* with a number.
Was that meant to be a clarification? It's true and clear
that the value of a pointer is never a number. I don't even know
what "directly compatible" is supposed to mean.
--
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-07-30 21:53 +0000 |
| Message-ID | <114gh4v$24ndu$10@dont-email.me> |
| In reply to | #400613 |
On Thu, 30 Jul 2026 21:00:15 -0000 (UTC), I wrote: > On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote: > >> ... the value of a pointer is the location that it points at. It's >> value is never a number. > > In C, its value is never *directly compatible* with a number. Except integer 0, of course.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-30 15:10 -0700 |
| Message-ID | <114gi5b$25jib$5@kst.eternal-september.org> |
| In reply to | #400617 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Thu, 30 Jul 2026 21:00:15 -0000 (UTC), I wrote:
>> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote:
>>> ... the value of a pointer is the location that it points at. It's
>>> value is never a number.
>>
>> In C, its value is never *directly compatible* with a number.
>
> Except integer 0, of course.
For certain values of "directly compatible", I suppose, though I
still don't know what you mean by that. (The C standard uses the word
"compatible" for types, not for values.)
0 is not a pointer value. The constant 0 is a null pointer constant,
which can be converted, implicitly or explicitly, to a pointer value,
yielding a null pointer. Any integer expression can be converted
to a pointer type, yielding an implementation-defined result (or
a null pointer if the expression is an NPC).
James's original statement that a pointer value is never a number
was both clear and correct. What information or clarity are you
trying to add?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-07-30 19:40 -0700 |
| Message-ID | <114h1v7$2b0po$2@dont-email.me> |
| In reply to | #400613 |
On 7/30/2026 2:00 PM, Lawrence D’Oliveiro wrote: > On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote: > >> ... the value of a pointer is the location that it points at. It's >> value is never a number. > > In C, its value is never *directly compatible* with a number. Well, uintptr_t?
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-07-31 02:43 +0000 |
| Message-ID | <114h24r$9nm$1@reader1.panix.com> |
| In reply to | #400624 |
In article <114h1v7$2b0po$2@dont-email.me>, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >On 7/30/2026 2:00 PM, Lawrence D’Oliveiro wrote: >> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote: >> >>> ... the value of a pointer is the location that it points at. It's >>> value is never a number. >> >> In C, its value is never *directly compatible* with a number. > >Well, uintptr_t? That's a type, not a value. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-07-30 19:44 -0700 |
| Message-ID | <114h26m$2b0po$3@dont-email.me> |
| In reply to | #400625 |
On 7/30/2026 7:43 PM, Dan Cross wrote: > In article <114h1v7$2b0po$2@dont-email.me>, > Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 7/30/2026 2:00 PM, Lawrence D’Oliveiro wrote: >>> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote: >>> >>>> ... the value of a pointer is the location that it points at. It's >>>> value is never a number. >>> >>> In C, its value is never *directly compatible* with a number. >> >> Well, uintptr_t? > > That's a type, not a value. Afait uintptr_t can be set to the NULL and any pointer? Then compared?
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web