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 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 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| 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]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-07-30 19:58 -0700 |
| Message-ID | <114h30s$2bbo8$1@dont-email.me> |
| In reply to | #400626 |
On 7/30/2026 7:44 PM, Chris M. Thomasson wrote: > On 7/30/2026 7:43 PM, Dan Cross wrote: >> In article <114h1v7$2b0po$2@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 7/30/2026 2:00 PM, Lawrence D’Oliveiro wrote: >>>> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote: >>>> >>>>> ... the value of a pointer is the location that it points at. It's >>>>> value is never a number. >>>> >>>> In C, its value is never *directly compatible* with a number. >>> >>> Well, uintptr_t? >> >> That's a type, not a value. > Afait uintptr_t can be set to the NULL and any pointer? Then compared? uintptr_t can be set to NULL, but I am not sure what bit pattern its going to get. The lower level does.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-01 01:25 -0700 |
| Message-ID | <114kain$3erqe$1@dont-email.me> |
| In reply to | #400626 |
On 7/30/2026 7:44 PM, Chris M. Thomasson wrote: > On 7/30/2026 7:43 PM, Dan Cross wrote: >> In article <114h1v7$2b0po$2@dont-email.me>, >> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 7/30/2026 2:00 PM, Lawrence D’Oliveiro wrote: >>>> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote: >>>> >>>>> ... the value of a pointer is the location that it points at. It's >>>>> value is never a number. >>>> >>>> In C, its value is never *directly compatible* with a number. >>> >>> Well, uintptr_t? >> >> That's a type, not a value. > Afait uintptr_t can be set to the NULL and any pointer? Then compared? I think, humm... uintptr_t can be set to a function pointer as well?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-02 23:14 +0200 |
| Message-ID | <114oc02$qbqp$1@dont-email.me> |
| In reply to | #400686 |
On 01/08/2026 10:25, Chris M. Thomasson wrote: > On 7/30/2026 7:44 PM, Chris M. Thomasson wrote: >> On 7/30/2026 7:43 PM, Dan Cross wrote: >>> In article <114h1v7$2b0po$2@dont-email.me>, >>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>> On 7/30/2026 2:00 PM, Lawrence D’Oliveiro wrote: >>>>> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote: >>>>> >>>>>> ... the value of a pointer is the location that it points at. It's >>>>>> value is never a number. >>>>> >>>>> In C, its value is never *directly compatible* with a number. >>>> >>>> Well, uintptr_t? >>> >>> That's a type, not a value. >> Afait uintptr_t can be set to the NULL and any pointer? Then compared? > > I think, humm... uintptr_t can be set to a function pointer as well? You are not making sense here. Any pointer (object pointer or function pointer) can be converted to any integer type. Whether or not the resulting integer value can be converted back to the same pointer is implementation dependent, as is the way the conversions are done. But /if/ any void* pointer can be converted to an integer type without loss of information, then uintptr_t and intptr_t are unsigned and signed types that can be used for the task. They may or may not be able to represent function pointers. In practice, on most systems, uintptr_t works for any data or function pointer. But you have to explicitly convert pointers to the uintptr_t integer type.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-02 14:37 -0700 |
| Message-ID | <114odai$qp0b$1@dont-email.me> |
| In reply to | #400716 |
On 8/2/2026 2:14 PM, David Brown wrote: > On 01/08/2026 10:25, Chris M. Thomasson wrote: >> On 7/30/2026 7:44 PM, Chris M. Thomasson wrote: >>> On 7/30/2026 7:43 PM, Dan Cross wrote: >>>> In article <114h1v7$2b0po$2@dont-email.me>, >>>> Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>>>> On 7/30/2026 2:00 PM, Lawrence D’Oliveiro wrote: >>>>>> On Thu, 30 Jul 2026 06:44:41 -0400, James Kuyper wrote: >>>>>> >>>>>>> ... the value of a pointer is the location that it points at. It's >>>>>>> value is never a number. >>>>>> >>>>>> In C, its value is never *directly compatible* with a number. >>>>> >>>>> Well, uintptr_t? >>>> >>>> That's a type, not a value. >>> Afait uintptr_t can be set to the NULL and any pointer? Then compared? >> >> I think, humm... uintptr_t can be set to a function pointer as well? > > You are not making sense here. > > Any pointer (object pointer or function pointer) can be converted to any > integer type. Whether or not the resulting integer value can be > converted back to the same pointer is implementation dependent, as is > the way the conversions are done. uintptr_t can help us here. They are very useful. > But /if/ any void* pointer can be converted to an integer type without > loss of information, then uintptr_t and intptr_t are unsigned and signed > types that can be used for the task. right. > They may or may not be able to > represent function pointers. In practice, on most systems, uintptr_t > works for any data or function pointer. But you have to explicitly > convert pointers to the uintptr_t integer type. > Can void* always hold a function pointer? I think not. So, that means that uintptr_t cannot always hold a function pointer... Right? However, uintptr_t can always hold a void*
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-08-02 22:51 +0000 |
| Message-ID | <114ohks$rsgh$2@dont-email.me> |
| In reply to | #400718 |
On Sun, 2 Aug 2026 14:37:20 -0700, Chris M. Thomasson wrote: > Can void* always hold a function pointer? I think not. Even on architectures with separate instruction/data spaces, I would say it is reasonable to require that void* can indeed hold a function pointer. This is because you are likely to need a pointer to some environment context for the function to execute in anyway, so the function pointer won’t point directly to the code, but to a descriptor that contains the pointer to the code.
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web