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 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| 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]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-02 16:43 -0700 |
| Message-ID | <114okmr$sjni$1@kst.eternal-september.org> |
| In reply to | #400725 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> 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.
Whether it would be reasonable to require it is a matter of opinion.
(IMHO it isn't.) The fact is that the C standard currently does
not require that, and an implementation where converting a function
pointer to void* loses information can be conforming.
A conforming implementation could have, for example, 64-bit object
pointers and 128-bit function pointers, and that could make sense on
some architectures. The requirement you suggest would force such
implementations to play some trick like making function pointers
point to a descriptor rather than to the function's code, hurting
efficiency for indirect function calls.
There have been changes to the C standard that make some conforming
implementations non-conforming, for example the C23 requirement
for 2's-complement signed integers. A future standard *could* do
something similar. But I see no compelling reason for such a change.
There is a proposal to introduce a new universal function pointer
type called _Any_func*, analogous to but distinct from void* for
object pointer types. Since all function pointer types are already
convertible to each other without loss of information, the case
for _Any_func* isn't quite as compelling as the case for void*.
The idea is to provide a function pointer type that's explicitly
generic (and not callable). In the current proposal, void* and
_Any_func* would be *conditionally* convertible.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3914.htm
--
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-08-03 12:03 -0700 |
| Message-ID | <114qom0$1ip6k$1@dont-email.me> |
| In reply to | #400725 |
On 8/2/2026 3:51 PM, Lawrence D’Oliveiro wrote: > 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. Well, a struct with function pointers in it, yes. We can hold a pointer to said struct in a uintptr_t. That's fine.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-08-03 23:49 +0000 |
| Subject | Re: Prioritize Correctness Over Performance |
| Message-ID | <114r9di$1nlvl$5@dont-email.me> |
| In reply to | #400765 |
On Mon, 3 Aug 2026 12:03:27 -0700, Chris M. Thomasson wrote: > On 8/2/2026 3:51 PM, Lawrence D’Oliveiro wrote: >> >> 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. > > Well, a struct with function pointers in it, yes. We can hold a > pointer to said struct in a uintptr_t. That's fine. In case it wasn’t clear, I was talking about how the underlying implementation has to handle function pointers, not how C programmers might use them in an application program.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-03 19:35 -0700 |
| Subject | Re: Prioritize Correctness Over Performance |
| Message-ID | <114rj5a$1qif9$2@dont-email.me> |
| In reply to | #400789 |
On 8/3/2026 4:49 PM, Lawrence D’Oliveiro wrote: > On Mon, 3 Aug 2026 12:03:27 -0700, Chris M. Thomasson wrote: > >> On 8/2/2026 3:51 PM, Lawrence D’Oliveiro wrote: >>> >>> 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. >> >> Well, a struct with function pointers in it, yes. We can hold a >> pointer to said struct in a uintptr_t. That's fine. > > In case it wasn’t clear, I was talking about how the underlying > implementation has to handle function pointers, Well that is totally implementation defined. > not how C programmers > might use them in an application program. Okay.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-03 08:08 +0800 |
| Subject | MS-DOS memory models (was: Re: Prioritize Performance over Correctness) |
| Message-ID | <XZQbS.135669$yWz9.4256@fx04.ams4> |
| In reply to | #400718 |
On 03/08/2026 5:37 AM, Chris M. Thomasson wrote:
> 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?
Yes, in practice. Everyone has forgotten that the standard verbiage for
allowing function pointers and other pointers to be different was to
account for the different memory models of MS-DOS. Specifically, the
/medium/ memory model was quite popular, and the /compact/ model was
available for the inverse case.
People that need a primer on this subject can just read Raymond
Chen.
https://devblogs.microsoft.com/oldnewthing/20200728-00/?p=104012
>
> However, uintptr_t can always hold a void*
And function pointers, see above.
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-03 10:16 +0200 |
| Message-ID | <114piou$14lmv$2@dont-email.me> |
| In reply to | #400718 |
On 02/08/2026 23:37, Chris M. Thomasson wrote: > 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. Yes, uintptr_t is the type you want to use if you need to handle an object pointer as an integer. Use it for two reasons. First, if the implementation does not support an integer type big enough to hold a void*, then the type "uintptr_t" will not exist in <stdint.h>. I don't know of any such platforms, but if one is made, then a hard compile-time error is far better than hidden problems. Secondly, assuming the type exists, it is the ideal size for the job. So always use "const uintptr_t address = (uintptr_t) pointer;", rather than using "unsigned long" or other guessed type that will be appropriate on some targets and not others. > > >> 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* That is all correct (if uintptr_t exists, of course). On most targets, function pointers are the same size as void* pointers. But there are exceptions, with some small microcontrollers and DSPs having different kinds of pointers with different sizes, depending on the memory space involved. I have yet to see a situation where there was any reason for storing a function address in a "void*" rather than a more appropriate typedef, such as : typedef void (*FVoid)(void); Function pointers can safely be converted to other function pointer types and back again, as long as you have converted to the correct type before calling the function. You have no such guarantees with void* or uintptr_t for function pointers. (You might occasionally need to convert a function pointer to a specific sized integer type on very low-level code, such as setting up interrupt vector tables - but that is all highly non-portable code.) There have been experimental systems designed with wider pointers for data and functions, where the pointers might not fit in any integer type because they contain information about the range of memory section, or security or access control information. And there are systems (either very old, quite niche DSPs, or some microcontrollers) where pointers to different types of data can have different sizes or contain additional address space, memory bank, or byte offset information. Generally speaking, don't convert pointer types to integers unless you actually need to.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2026-08-03 10:41 +0100 |
| Message-ID | <114pno3$16g53$1@dont-email.me> |
| In reply to | #400734 |
On 03/08/2026 09:16, David Brown wrote: > On 02/08/2026 23:37, Chris M. Thomasson wrote: >> 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. > > Yes, uintptr_t is the type you want to use if you need to handle an > object pointer as an integer. Use it for two reasons. > > First, if the implementation does not support an integer type big enough > to hold a void*, then the type "uintptr_t" will not exist in <stdint.h>. > I don't know of any such platforms, but if one is made, then a hard > compile-time error is far better than hidden problems. > > Secondly, assuming the type exists, it is the ideal size for the job. > > So always use "const uintptr_t address = (uintptr_t) pointer;", rather > than using "unsigned long" or other guessed type that will be > appropriate on some targets and not others. > >> >> >>> 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* > > That is all correct (if uintptr_t exists, of course). > > On most targets, function pointers are the same size as void* pointers. > But there are exceptions, with some small microcontrollers and DSPs > having different kinds of pointers with different sizes, depending on > the memory space involved. I have yet to see a situation where there > was any reason for storing a function address in a "void*" rather than a > more appropriate typedef, such as : > > typedef void (*FVoid)(void); dlsym requires that pointer-to-function is compatible with a void* > > Function pointers can safely be converted to other function pointer > types and back again, as long as you have converted to the correct type > before calling the function. You have no such guarantees with void* or > uintptr_t for function pointers. > > (You might occasionally need to convert a function pointer to a specific > sized integer type on very low-level code, such as setting up interrupt > vector tables - but that is all highly non-portable code.) > > There have been experimental systems designed with wider pointers for > data and functions, where the pointers might not fit in any integer type > because they contain information about the range of memory section, or > security or access control information. And there are systems (either > very old, quite niche DSPs, or some microcontrollers) where pointers to > different types of data can have different sizes or contain additional > address space, memory bank, or byte offset information. Generally > speaking, don't convert pointer types to integers unless you actually > need to. >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-03 12:28 +0200 |
| Message-ID | <114pqg5$17lne$1@dont-email.me> |
| In reply to | #400736 |
On 03/08/2026 11:41, Richard Harnden wrote: > On 03/08/2026 09:16, David Brown wrote: >> On most targets, function pointers are the same size as void* >> pointers. But there are exceptions, with some small microcontrollers >> and DSPs having different kinds of pointers with different sizes, >> depending on the memory space involved. I have yet to see a situation >> where there was any reason for storing a function address in a "void*" >> rather than a more appropriate typedef, such as : >> >> typedef void (*FVoid)(void); > > dlsym requires that pointer-to-function is compatible with a void* > As I say, I have yet to see a situation where using void* for function pointers was more appropriate than using a function pointer type. If the OS system calls or standard OS libraries makes it a requirement that function pointers are converted to or from void* for some calls, then of course you need to follow those requirements - it's the people who designed the interfaces that made questionable design choices.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-03 19:23 +0800 |
| Subject | Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) |
| Message-ID | <5T_bS.71191$4Fu9.56234@fx05.ams4> |
| In reply to | #400737 |
On 03/08/2026 6:28 PM, David Brown wrote: > On 03/08/2026 11:41, Richard Harnden wrote: >> On 03/08/2026 09:16, David Brown wrote: > >>> On most targets, function pointers are the same size as void* >>> pointers. But there are exceptions, with some small microcontrollers >>> and DSPs having different kinds of pointers with different sizes, >>> depending on the memory space involved. I have yet to see a >>> situation where there was any reason for storing a function address >>> in a "void*" rather than a more appropriate typedef, such as : >>> >>> typedef void (*FVoid)(void); >> >> dlsym requires that pointer-to-function is compatible with a void* >> > > As I say, I have yet to see a situation where using void* for function > pointers was more appropriate than using a function pointer type. If > the OS system calls or standard OS libraries makes it a requirement that > function pointers are converted to or from void* for some calls, then of > course you need to follow those requirements - it's the people who > designed the interfaces that made questionable design choices. > Nope, you're wrong. You're dead wrong. The world isn't built on C, even though here in comp.lang.c we like to pretend it is. Several language environments allow function generation on the fly, these functions need to be garbage collected. Common Lisp is an example, therefore comp.lang.lisp is added to this discussion. I've also added comp.theory so Mild Shock can comment. You will have to go out of your way to make a computer architecture incompatible with garbage collected and heap allocated binary code, something I've been told SBCL does internally [1] to create an archi- tecture that has different * sizeof ( void * ), and * sizeof ( void (*)( void ) ), and when you do that, I'll just claim you're making a /malicious computer architecture/ and refuse to use it. [1] I've not looked at the code, but told the garbage collector can and will at least move the code around, if not collect it. -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-03 14:01 +0200 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <114pvvh$17lne$2@dont-email.me> |
| In reply to | #400738 |
On 03/08/2026 13:23, Johann 'Myrkraverk' Oskarsson wrote: Would you /please/ stop adding bunches of random newsgroups to posts? You are making a mess of many newsgroups here, filling them with drivel of no interest to the regulars in the groups. Regulars in comp.lang.lisp care about Lisp, not C. Regulars in comp.theory, I presume, care about the theory of computation - not C or Lisp. Usenet groups are not controlled or governed, and no one can stop you making the posts you make. But be very clear on this - your behaviour is seriously anti-social, rude, and counter-productive. A discussion community, such as a Usenet group, "belongs" to the people that follow the group and post there regularly. Filling a group with cross-posts that inevitably fall off-topic is nothing short of vandalism. I am going to make the assumption that your bad habits here are because you genuinely believe the cross-posting to be a good idea and you simply don't understand the consequences, but I sincerely hope that you reconsider. So I will answer your C points below. But you have already alienated several of the C experts in this group - failing to follow the style and standards of a community means you will not get the information or discussions you came here for. If you want to post here on the C language - that would be great, and it's always need to see new people joining in. > On 03/08/2026 6:28 PM, David Brown wrote: >> On 03/08/2026 11:41, Richard Harnden wrote: >>> On 03/08/2026 09:16, David Brown wrote: >> >>>> On most targets, function pointers are the same size as void* >>>> pointers. But there are exceptions, with some small microcontrollers >>>> and DSPs having different kinds of pointers with different sizes, >>>> depending on the memory space involved. I have yet to see a >>>> situation where there was any reason for storing a function address >>>> in a "void*" rather than a more appropriate typedef, such as : >>>> >>>> typedef void (*FVoid)(void); >>> >>> dlsym requires that pointer-to-function is compatible with a void* >>> >> >> As I say, I have yet to see a situation where using void* for function >> pointers was more appropriate than using a function pointer type. If >> the OS system calls or standard OS libraries makes it a requirement >> that function pointers are converted to or from void* for some calls, >> then of course you need to follow those requirements - it's the people >> who designed the interfaces that made questionable design choices. >> > > Nope, you're wrong. You're dead wrong. The world isn't built on C, > even though here in comp.lang.c we like to pretend it is. > You can't jump into a group for a week and pretend to speak for it. People in comp.lang.c do not think the world is built on C - they /know/ that a great deal of key software is built in and on C, they /know/ that a great of cross-language interfaces, APIs, ABIs, and libraries are build around C and C concepts. They know that discussions about C, such as the thread here, are about C. They know that Lisp is not C, nor is C the only programming language, and they know things are done differently in different languages. In C, function pointers and object pointers are different concepts and good design keeps those different concepts separate. Most, but not all, targets for C have a single simple flat memory model in which addresses of data and addresses of code have the same underlying implementation in the hardware - that does not mean it is a good idea to mix these types of pointer at the C language level - especially as there is rarely anything to be gained by it. > Several language environments allow function generation on the fly, > these functions need to be garbage collected. Common Lisp is an > example, therefore comp.lang.lisp is added to this discussion. > Several languages are not C, and are not relevant to C. There are hundreds of real-world programming languages that are not C, and which may or may not allow function generation on the fly - none of them, including Lisp, are relevant here, nor are any of their newsgroups appropriate. And there is no relation between having a common format for data and code pointers, and having support for generating functions at run-time. Python allows run-time function generation, but has no concept of either function pointers or data pointers. C++ allows run-time function generation, but has a clear distinction between data pointers and function pointers (with the same model there as C). > I've also added comp.theory so Mild Shock can comment. Please don't. This is not about computation theory. If someone else wants to join in a C discussion in a C group, talking about C, then that's fine. > > You will have to go out of your way to make a computer architecture > incompatible with garbage collected and heap allocated binary code, > something I've been told SBCL does internally [1] to create an archi- > tecture that has different > > * sizeof ( void * ), and > * sizeof ( void (*)( void ) ), > > and when you do that, I'll just claim you're making a /malicious > computer architecture/ and refuse to use it. > > > [1] I've not looked at the code, but told the garbage collector can > and will at least move the code around, if not collect it. C does not use garbage collection. C does not use "heap allocated binary code". Other languages may do, and may have different ways of addressing or identifying the code. We are talking here about C. And in C, even if function pointers have the same size as void* on most platforms, the two classes of pointers are entirely distinct. You need to go out of your way (via explicit casts) to mix them in some way, and that is very rarely a useful thing to do.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-08-03 22:52 +0800 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <VW1cS.103376$aXr.29782@fx18.ams4> |
| In reply to | #400739 |
On 03/08/2026 8:01 PM, David Brown wrote: > On 03/08/2026 13:23, Johann 'Myrkraverk' Oskarsson wrote: > > Would you /please/ stop adding bunches of random newsgroups to posts? > You are making a mess of many newsgroups here, filling them with drivel > of no interest to the regulars in the groups. Regulars in > comp.lang.lisp care about Lisp, not C. Regulars in comp.theory, I > presume, care about the theory of computation - not C or Lisp. No. The reason being, assholes like Scott Lurndal owe me an apology. There are more of them. When you get the "regulars" to behave like normal human beings, I might too. But that said, none of you know how to behave like regular humans, so why should I bother to respect your "rules." Jut add me to your killfile and be done with it. > > Usenet groups are not controlled or governed, and no one can stop you > making the posts you make. But be very clear on this - your behaviour > is seriously anti-social, rude, and counter-productive. A discussion > community, such as a Usenet group, "belongs" to the people that follow > the group and post there regularly. Filling a group with cross-posts > that inevitably fall off-topic is nothing short of vandalism. I am > going to make the assumption that your bad habits here are because you > genuinely believe the cross-posting to be a good idea and you simply > don't understand the consequences, but I sincerely hope that you > reconsider. So I will answer your C points below. But you have already > alienated several of the C experts in this group - failing to follow the > style and standards of a community means you will not get the > information or discussions you came here for. > No, the "regulars" are extremely anti-social, and quite moronic. You have, over the years, completely ruined your own "space" for conver- sations. I don't need a /C expert/ in my life. I am one. What I need, is at best, humans who know how to be humans. You don't seem to be one, but I'll at least consider to continue to read your reply. > If you want to post here on the C language - that would be great, and > it's always need to see new people joining in. > >> On 03/08/2026 6:28 PM, David Brown wrote: >>> On 03/08/2026 11:41, Richard Harnden wrote: >>>> On 03/08/2026 09:16, David Brown wrote: >>> >>>>> On most targets, function pointers are the same size as void* >>>>> pointers. But there are exceptions, with some small >>>>> microcontrollers and DSPs having different kinds of pointers with >>>>> different sizes, depending on the memory space involved. I have >>>>> yet to see a situation where there was any reason for storing a >>>>> function address in a "void*" rather than a more appropriate >>>>> typedef, such as : >>>>> >>>>> typedef void (*FVoid)(void); >>>> >>>> dlsym requires that pointer-to-function is compatible with a void* >>>> >>> >>> As I say, I have yet to see a situation where using void* for >>> function pointers was more appropriate than using a function pointer >>> type. If the OS system calls or standard OS libraries makes it a >>> requirement that function pointers are converted to or from void* for >>> some calls, then of course you need to follow those requirements - >>> it's the people who designed the interfaces that made questionable >>> design choices. >>> >> >> Nope, you're wrong. You're dead wrong. The world isn't built on C, >> even though here in comp.lang.c we like to pretend it is. >> > > You can't jump into a group for a week and pretend to speak for it. > People in comp.lang.c do not think the world is built on C - they /know/ > that a great deal of key software is built in and on C, they /know/ that > a great of cross-language interfaces, APIs, ABIs, and libraries are > build around C and C concepts. They know that discussions about C, such > as the thread here, are about C. They know that Lisp is not C, nor is C > the only programming language, and they know things are done differently > in different languages. If they don't, why do they act like it? > > In C, function pointers and object pointers are different concepts and > good design keeps those different concepts separate. Most, but not all, > targets for C have a single simple flat memory model in which addresses > of data and addresses of code have the same underlying implementation in > the hardware - that does not mean it is a good idea to mix these types > of pointer at the C language level - especially as there is rarely > anything to be gained by it. > >> Several language environments allow function generation on the fly, >> these functions need to be garbage collected. Common Lisp is an >> example, therefore comp.lang.lisp is added to this discussion. >> > > Several languages are not C, and are not relevant to C. There are > hundreds of real-world programming languages that are not C, and which > may or may not allow function generation on the fly - none of them, > including Lisp, are relevant here, nor are any of their newsgroups > appropriate. You are completely forgetting that many, many languages are implemented in C. Including Appels's Tiger. > > And there is no relation between having a common format for data and > code pointers, and having support for generating functions at run-time. > Python allows run-time function generation, but has no concept of either > function pointers or data pointers. C++ allows run-time function > generation, but has a clear distinction between data pointers and > function pointers (with the same model there as C). I'd like to know, how you intend to implement a heap allocated function, in C, if you cannot just use whatever malloc() returns? > >> I've also added comp.theory so Mild Shock can comment. > > Please don't. This is not about computation theory. If someone else > wants to join in a C discussion in a C group, talking about C, then > that's fine. > We are no longer just talking about C. We are talking about /malicious computer architectures/. >> >> You will have to go out of your way to make a computer architecture >> incompatible with garbage collected and heap allocated binary code, >> something I've been told SBCL does internally [1] to create an archi- >> tecture that has different >> >> * sizeof ( void * ), and >> * sizeof ( void (*)( void ) ), >> >> and when you do that, I'll just claim you're making a /malicious >> computer architecture/ and refuse to use it. >> >> >> [1] I've not looked at the code, but told the garbage collector can >> and will at least move the code around, if not collect it. > > C does not use garbage collection. C does not use "heap allocated > binary code". Other languages may do, and may have different ways of > addressing or identifying the code. We are talking here about C. > > And in C, even if function pointers have the same size as void* on most > platforms, the two classes of pointers are entirely distinct. You need > to go out of your way (via explicit casts) to mix them in some way, and > that is very rarely a useful thing to do. > > Many garbage collectors are implemented in C. Have you used one? -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-03 19:41 +0200 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <114qjs0$1gr0g$1@dont-email.me> |
| In reply to | #400747 |
On 03/08/2026 16:52, Johann 'Myrkraverk' Oskarsson wrote: > On 03/08/2026 8:01 PM, David Brown wrote: >> On 03/08/2026 13:23, Johann 'Myrkraverk' Oskarsson wrote: >> >> Would you /please/ stop adding bunches of random newsgroups to posts? >> You are making a mess of many newsgroups here, filling them with >> drivel of no interest to the regulars in the groups. Regulars in >> comp.lang.lisp care about Lisp, not C. Regulars in comp.theory, I >> presume, care about the theory of computation - not C or Lisp. > > No. The reason being, assholes like Scott Lurndal owe me an apology. > > There are more of them. When you get the "regulars" to behave like > normal human beings, I might too. > > But that said, none of you know how to behave like regular humans, > so why should I bother to respect your "rules." > > Jut add me to your killfile and be done with it. > Okay then. I had some hope that you might be able to bring something useful to a conversation, but that hope seems to be in vain. Since you have such a low opinion of this group, and such a high opinion of your own C knowledge, I'd suggest you leave. You don't want to listen to us, and we don't want to listen to you. There is no point in you posting here, except perhaps for petty vindictiveness.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-03 13:13 -0700 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <114qspl$1k97b$2@dont-email.me> |
| In reply to | #400756 |
On 8/3/2026 10:41 AM, David Brown wrote: > On 03/08/2026 16:52, Johann 'Myrkraverk' Oskarsson wrote: >> On 03/08/2026 8:01 PM, David Brown wrote: >>> On 03/08/2026 13:23, Johann 'Myrkraverk' Oskarsson wrote: >>> >>> Would you /please/ stop adding bunches of random newsgroups to posts? >>> You are making a mess of many newsgroups here, filling them with >>> drivel of no interest to the regulars in the groups. Regulars in >>> comp.lang.lisp care about Lisp, not C. Regulars in comp.theory, I >>> presume, care about the theory of computation - not C or Lisp. >> >> No. The reason being, assholes like Scott Lurndal owe me an apology. >> >> There are more of them. When you get the "regulars" to behave like >> normal human beings, I might too. >> >> But that said, none of you know how to behave like regular humans, >> so why should I bother to respect your "rules." >> >> Jut add me to your killfile and be done with it. >> > Okay then. > > I had some hope that you might be able to bring something useful to a > conversation, but that hope seems to be in vain. I think so. Plonked the mild shock. I tried as well. > Since you have such a low opinion of this group, and such a high opinion > of your own C knowledge, I'd suggest you leave. You don't want to > listen to us, and we don't want to listen to you. There is no point in > you posting here, except perhaps for petty vindictiveness. I almost have to agree.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-03 13:10 -0700 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <114qsjg$1k97b$1@dont-email.me> |
| In reply to | #400747 |
On 8/3/2026 7:52 AM, Johann 'Myrkraverk' Oskarsson wrote: > On 03/08/2026 8:01 PM, David Brown wrote: >> On 03/08/2026 13:23, Johann 'Myrkraverk' Oskarsson wrote: >> >> Would you /please/ stop adding bunches of random newsgroups to posts? >> You are making a mess of many newsgroups here, filling them with >> drivel of no interest to the regulars in the groups. Regulars in >> comp.lang.lisp care about Lisp, not C. Regulars in comp.theory, I >> presume, care about the theory of computation - not C or Lisp. > > No. The reason being, assholes like Scott Lurndal owe me an apology. [...] Oh wow. Are you a sock puppet of the minor shocker? Sigh.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-08-03 14:29 +0000 |
| Subject | Re: Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) |
| Message-ID | <UA1cS.12216$B3ve.269@fx06.iad> |
| In reply to | #400738 |
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >On 03/08/2026 6:28 PM, A respected comp.lang.c poster wrote: >Nope, you're wrong. You're dead wrong. The world isn't built on C, >even though here in comp.lang.c we like to pretend it is. Hey dipshit, you're responding to a post in comp.lang.c and cross-posting your reply to other unrelated groups. Please don't do that.
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web