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 194 — 21 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] 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
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 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Aidan Kehoe <kehoea@parhasard.net> |
|---|---|
| Date | 2026-08-06 23:01 +0100 |
| Subject | Re: Malicious Computer Architecture |
| Message-ID | <27253.1071.416806.842336@parhasard.net> |
| In reply to | #400823 |
Ar an cúigiú lá de mí Lúnasa, scríobh Johann Oskarsson: > On 04/08/2026 2:51 AM, Aidan Kehoe wrote: > > Hello Aidan, > > We haven't spoken for a long time, and I guess we're moving in different > social circles now. I spent 2012-present debugging people, and until 2021ish without the time away from that to maintain a social circle or do any XEmacs work. My social circle just shrank! > You will find it amusing that my patch to the FreeBSD kernel, the one > that kind of tunes the TCP/IP stack, is presumably used by Whatsapp as > well. > > At least, that's the rumor I heard; I wouldn't know the truth as I don't > work for Whatsapp. I thought only 5ch and Netflix had sites large > enough to make use of it. Well, sites both large enough, and hosted on > FreeBSD. > > I promised myself to look into it later, and if I'm right -- at least, > that my patch is still there and all -- I'll let you know. Good. > It's always fun to know that whenever someone streams from Netflix, the > TCP/IP patch I applied is being used; though I cannot say that it > streams through my code; it wasn't that kind of patch. > > And I didn't, and don't work for Netflix either. > > I hope you're also leaving trails of patches in various operating > systems that everyone on the planet, more or less, makes use of. There’s enough to do with XEmacs plus running a business plus a three year old daughter plus a fiancée, that I don’t anticipate any OS patches from me this decade. Still, I save lives, and more importantly, prevent large strokes. > > Ar an triú lá de mí Lúnasa, scríobh Johann Oskarsson: > > > > > 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. > > > > The habit when I read comp.lang.c it was to assert that standard C was > > all that was worth discussing (yes, yes, it’s phrased as standard C is on > > topic, everything else isn’t; but there wasn’t the activity in the > > architecture-specific groups for them to be helpful when I was reading > > it). This is even more ridiculous; almost all the C infrastructure out > > there relies on what is undefined behaviour by the letter of the > > standard. But it’s still C, and it’s worth understanding and worth > > writing. > > Yes, I remember that. I believe I came across a FAQ, probably comp.os. > msdos.programmer, that said because comp.lang.c was full of standard > thumping trolls, a lot of regular programming, even Win32 got discussed > there. Yes, I'll quote. > > > Why does the newsgroup seem to be so C-oriented sometimes? > > There are two reasons. First, comp.lang.c and > > comp.lang.pascal have evolved in different > > directions. Comp.lang.pascal has split into discussions > > about individual Pascal compilers. comp.lang.pascal.borland > > welcomes discussion specific to Turbo Pascal, and the other > > new groups likewise. Turbo Pascal programmers tend to find > > DOS questions welcomed in comp.lang.pascal.borland, so that > > comp.os.msdos.programmer gets less of the "DOS in Turbo > > Pascal" traffic. On the other hand, comp.lang.c has stayed > > closer to talking only about the C language, and > > vendor-specific or operating-system-specific questions are > > not welcome. This tends to push questions about disks, DOS > > file structure, video, the keyboard, TSRs, etc. to > > comp.os.msdos.programmer even when those programs are > > written in C. > > So my take on it, is that the standard thumping trolls in comp.lang.c were > already a problem in the 90s. They just didn't know it, didn't care, and > nobody challenged them about it. Until now. Most of my comp.lang.c was the turn of the millennium. I don’t have the desire or spare time at the moment to read more newsgroups, and I’m happy with my command of C. > I am challenging their rule. And they can whine, and they can bluster, > but nobody cares about their mistaken sense of prestige and power. > > They claim my cross posting is annoying. As far as I'm aware, I'm > basically screaming into the void with my cross posts, because there > isn't enough traffic in the other groups to warrant complaints about it. Fight on! Alternatively put the time into XEmacs (or packages) work, which is, a better use of your time. (From my perspective, and probably in the grand scheme of things; neither of is likely to make any difference to comp.lang.c.) > > Oh well, thank you the autoconf maintainers, thank you the cmake > > maintainers, shame about the difficulty with cross-compiling. > > On that subject, I have to agree. I've largely given up on both for my own > projects. The problems with these tools isn't when they work, it's when they > don't. It can be a nightmare to get to the first build on a platform where > the build system doesn't work. Well, it’s just one more platform to learn. I would love to move XEmacs to cmake, given it would unify the POSIX and Windows build systems, but it would be a huge investment of time to port it over, because I know autoconf but I don’t know cmake. > I currently believe both tools make porting to a /different enough platform/ > basically impossible. And that's based on hard earned experience. My understanding is that cmake just requires a C compiler, no shell, no other dependencies, so it should manage a different enough platform that has a C compiler without problems. This is its attraction over autoconf, which requires /bin/sh at least, and pragmatically more of POSIX. > > > 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 > > > > I haven’t gone into the weeds of the GNU Emacs native-compiled function > > implementation, but it has to be doing something similar. The functions > > are not in the data segment, they’re not in BSS, they’re not on the > > stack; that leaves the heap. > > And not to mention the operating system interfaces. I'll name mmap(), > and Win32 has its equivalent, and while I'm not sure, OpenVMS might be > different too. > > All of them return the equivalent of void *. So what are the programmers of > the JVM, CLR, and other virtual machines to do? They'll have to rely on > this "undefined behaviour." Well, they have to port to the various platforms, that’s all. And hope the platform defines the behaviour. > > > > > * 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. > > > > Note that GCC on AMD64 produces function pointers that are one-byte > > aligned, which to me is a similar philosophy. There cannot be any > > performance advantage to that. > > Can you please expand on that? I'm not sure what you mean, and I hope > it doesn't create function pointers at strictly odd addresses, because > that's what it sounds like to me. https://lidell.nu/xemacs-buildbot/#/builders/14/builds/690 throws an assertion failure because I was storing a function pointer into a Lisp fixnum, which has 63 bits of precision. The least significant bit of the function pointer was set. -- ‘As I sat looking up at the Guinness ad, I could never figure out / How your man stayed up on the surfboard after fourteen pints of stout’ (C. Moore)
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-04 14:58 +0200 |
| Subject | A Case for Impurity: The Applied Pi Calculus (Re: Malicious Computer Architecture) |
| Message-ID | <114snlo$uj7n$2@solani.org> |
| In reply to | #400738 |
Hi, How it started: The Applied Pi Calculus: Mobile Values, New Names, and Secure Communication Martín Abadi et al. - Google Brain https://arxiv.org/abs/1609.03003 How its going: Dynamic Control Flow in Large-Scale Machine Learning Martín Abadi et al. - Google Brain https://research.google/pubs/dynamic-control-flow-in-large-scale-machine-learning/ Have Fun! Bye Johann 'Myrkraverk' Oskarsson schrieb: > 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.
[toc] | [prev] | [next] | [standalone]
| From | Mild Shock <janburse@fastmail.fm> |
|---|---|
| Date | 2026-08-04 15:10 +0200 |
| Subject | The Sandcastle of Paul Taraus Interactors (Re: A Case for Impurity: The Applied Pi Calculus) |
| Message-ID | <114sod0$ujln$3@solani.org> |
| In reply to | #400816 |
Hi,
While Paul Taraus Interactors were somewhere
between stackfull and stackless coroutines,
they were still a castle built on sand.
What was the comms? An interactor was a child
of a parent, and had only two comms, input "next"
and output "the". And there was not much
asynchronizity. But look at the new
library(misc/intercom) that provides ADA
Rendez Vous in Dogelog Player for Java:
:- ensure_loaded(library(misc/intercom)).
producer(C) :-
between(1,10,X),
Y is X*X,
send(C,[Y]),
fail.
producer(_).
consumer(C) :-
between(1,10,_),
recv(C,[Y]),
write(Y), nl,
fail.
consumer(_).
As the show case shows, it even works with
cooperating coroutines. I have looked at it
for 5 hours straight, its beautiful:
?- cpu_chan_new(C), create_task(producer(C)),
create_task(consumer(C)), sleep(1000).
1
4
9
16
25
36
49
64
81
100
C = 0rReference.
Bye
Mild Shock schrieb:
> Hi,
>
> How it started:
>
> The Applied Pi Calculus: Mobile Values,
> New Names, and Secure Communication
> Martín Abadi et al. - Google Brain
> https://arxiv.org/abs/1609.03003
>
> How its going:
>
> Dynamic Control Flow in
> Large-Scale Machine Learning
> Martín Abadi et al. - Google Brain
> https://research.google/pubs/dynamic-control-flow-in-large-scale-machine-learning/
>
>
> Have Fun!
>
> Bye
>
> Johann 'Myrkraverk' Oskarsson schrieb:
>> 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.
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-03 05:34 -0700 |
| Message-ID | <114q1sr$1a0sa$2@kst.eternal-september.org> |
| In reply to | #400736 |
Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]
> dlsym requires that pointer-to-function is compatible with a void*
Well, sort of.
A technical quibble is that "compatible" has a specific meaning in c,
and void* can never be compatible with any pointer-to-function type.
But I know what you meant by "compatible".
dlsym() is a POSIX-specific function that returns the address of a
symbol looked up by its name. It can be the address of an object
or of a function. The only real requirement is that an address
returned by dlsym() for a function identifier can be usefully
converted to a function pointer of the appropriate type and used to
call the function. It doesn't require that *all* function pointers
are losslessly convertible to and from void*.
For example, an implementation could have, say, 32-bit void* and
64-bit function pointers, but guarantee all functions whose addresses
can be obtained by dlsym() are within a 32-bit address space.
I don't know of any implementations that work this way, but it's
allowed by both C and POSIX.
--
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 13:04 -0700 |
| Message-ID | <114qs94$1k64l$1@dont-email.me> |
| In reply to | #400736 |
On 8/3/2026 2:41 AM, Richard Harnden wrote: > 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* Shit, off the top of my head I cannot remember if that function is POSIX. I think it is. So, POSIX puts a lot of prerequisites for any system to say its POSIX compliant.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-08-04 00:52 +0000 |
| Subject | Re: Prioritize Correctness Over Performance |
| Message-ID | <114rd4c$1ov3f$2@dont-email.me> |
| In reply to | #400769 |
On Mon, 3 Aug 2026 13:04:50 -0700, Chris M. Thomasson wrote:
> Shit, off the top of my head I cannot remember if that function is
> POSIX.
This is usually mentioned in the man pages.
<https://manpages.debian.org/dlsym(3)> says:
STANDARDS
dlsym()
POSIX.1-2008.
dlvsym()
GNU.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-08-04 14:22 +0000 |
| Subject | Re: Prioritize Correctness Over Performance |
| Message-ID | <AAmcS.1832$Z7Ef.1040@fx46.iad> |
| In reply to | #400795 |
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes: >On Mon, 3 Aug 2026 13:04:50 -0700, Chris M. Thomasson wrote: > >> Shit, off the top of my head I cannot remember if that function is >> POSIX. > >This is usually mentioned in the man pages. Usually is insufficient. Use the source, Luke. https://pubs.opengroup.org/onlinepubs/9799919799/
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-03 05:25 -0700 |
| Message-ID | <114q1cb$1a0sa$1@kst.eternal-september.org> |
| In reply to | #400734 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> 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.
Almost certainly, but that's not guaranteed by the standard.
The requirement is that converting a void* to [u]intptr_t and back
again yields a result that compares equal to the original pointer.
A conforming implementation could have 32-bit pointers and 64-bit
[u]intptr_t, even of 32-bit integer types are available. I can't
think of a good reason for an implementation to do that.
> 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 first think carefully whether storing pointer values in integer
objects is really an appropriate thing to do. Sometimes it is,
but I've seen code that did so needlessly and incorrectly.
Let pointers be pointers (unless there's a specific reason not to).
[...]
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-03 15:10 +0200 |
| Message-ID | <114q3vl$1am6d$1@dont-email.me> |
| In reply to | #400740 |
On 03/08/2026 14:25, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> 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.
>
> Almost certainly, but that's not guaranteed by the standard.
>
That's true, of course - but it would be a strange implementation that
did not use the "best" size for the job. ("Best" does not necessarily
mean "smallest".) Theoretically, there may be tradeoffs and no single
"ideal" size here. In practice, however, it would be very unlikely that
there will be a more efficient type than "uintptr_t" for the task of
holding the results of converting a pointer to an integer type.
> The requirement is that converting a void* to [u]intptr_t and back
> again yields a result that compares equal to the original pointer.
>
> A conforming implementation could have 32-bit pointers and 64-bit
> [u]intptr_t, even of 32-bit integer types are available. I can't
> think of a good reason for an implementation to do that.
>
It would have been a reasonable choice for the x32 ABI (where pointers
are 32 bit, but otherwise 64-bit instructions are generated). After
all, for normal x86-64, uint_fast32_t is 64-bit. But AFAIK x32 has
32-bit uintptr_t.
>> 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 first think carefully whether storing pointer values in integer
> objects is really an appropriate thing to do. Sometimes it is,
> but I've seen code that did so needlessly and incorrectly.
>
> Let pointers be pointers (unless there's a specific reason not to).
>
Agreed entirely.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-03 13:16 -0700 |
| Message-ID | <114qsuf$1k97b$3@dont-email.me> |
| In reply to | #400740 |
On 8/3/2026 5:25 AM, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> 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. > > Almost certainly, but that's not guaranteed by the standard. > > The requirement is that converting a void* to [u]intptr_t and back > again yields a result that compares equal to the original pointer. > > A conforming implementation could have 32-bit pointers and 64-bit > [u]intptr_t, even of 32-bit integer types are available. I can't > think of a good reason for an implementation to do that. > >> 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 first think carefully whether storing pointer values in integer > objects is really an appropriate thing to do. Sometimes it is, > but I've seen code that did so needlessly and incorrectly. Fwiw, its generally useful for lock/wait free algorithms. > > Let pointers be pointers (unless there's a specific reason not to). > > [...] >
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2026-08-03 20:29 -0400 |
| Message-ID | <114rbq0$1op2s$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? If uintptr_t is supported, then any pointer value can be converted to that type, The result of the conversion is implementation-defined integer value. It does not mean that the pointer's value was an integer before the conversion - it's the conversion itself that produced the integer. And conversely, it also does not mean that the integer's value after the conversion was the pointer's value before the conversion.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-03 17:55 -0700 |
| Message-ID | <114rd9b$1o8k3$2@kst.eternal-september.org> |
| In reply to | #400792 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> 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?
>
> If uintptr_t is supported, then any pointer value can be converted to
> that type, The result of the conversion is implementation-defined
> integer value. It does not mean that the pointer's value was an integer
> before the conversion - it's the conversion itself that produced the
> integer. And conversely, it also does not mean that the integer's value
> after the conversion was the pointer's value before the conversion.
And now for the usual pedantic quibbles.
Certain guarantees apply to object pointer types, not to function pointer
types.
Any pointer value can be converted to any integer type, and vice
versa. The result of such a conversion is implementation-defined
in most cases, and is not necessarily meaningful except in a few
specified cases.
A value of any object pointer type can be converted to void* and back
again, and the result compares equal to the original pointer.
If uintptr_t exists, then any void* value can be converted to intptr_t
and back again, and the resulting void* value compares equal to the
original pointer. Likewise for intptr_t. (uintptr_t feels vaguely more
appropriate to me, but there's no such implication in the standard.)
It seems obvious that a value of any object pointer type can be
converted to uintptr_t and back again without loss of information,
but I don't think the standard actually guarantees it. You can convert
an int* to void*, then to uintptr_t, then back to void*, and then back
to int*, and the result is guaranteed to compare equal to the original
int*. If you skip the intermediate void*, I don't *think* the standard
guaranteed that it works the same way. It would take a deliberately
perverse implementation to make this not work as expected.
There are no guarantees about converting between uintptr_t and
function pointer types, beyond the requirements that apply to all
pointer and integer types.
All function pointer types are convertible to all (other) function
pointer types without loss of information -- but not to or from
integer or object pointer types.
The standard doesn't say that function pointers can be converted to
object pointer types or vice versa -- no does it say that they can't.
My conclusion is that the behavior of such a conversion is undefined
by omission. (There was a lengthy and unproductive discussion about
this here a few years ago.) IMHO it would be better for the standard
to say that such conversions yield implementation-defined results.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-04 09:12 +0200 |
| Message-ID | <114s3dm$1ug6o$1@dont-email.me> |
| In reply to | #400796 |
On 04/08/2026 02:55, Keith Thompson wrote: > All function pointer types are convertible to all (other) function > pointer types without loss of information -- but not to or from > integer or object pointer types. > > The standard doesn't say that function pointers can be converted to > object pointer types or vice versa -- no does it say that they can't. > My conclusion is that the behavior of such a conversion is undefined > by omission. (There was a lengthy and unproductive discussion about > this here a few years ago.) IMHO it would be better for the standard > to say that such conversions yield implementation-defined results. > I think it would be better for the standards to say that it is implementation defined whether or not you can convert between function pointers and object pointers (or maybe just void*), and that if the implementation allows it, then the conversion must be information-preserving in both directions. Then you know that it either "just works", or that the implementation knows it can't handle it and can give a compile-time error (even when given explicit casts). The worst possible choice it is implementation-defined so that on a hypothetical system with fat function pointers and simple data pointers (or vice-versa), conversions have to be defined (such as by truncation) but silently fail to work as the programmer expects. My preference is always towards having things like this either work fully, or give a compile-time error. Leaving the behaviour undefined, as it is now, lets implementations do what they want - including the behaviour I described - and is, IMHO, better than your suggestion.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-21 05:49 -0700 |
| Message-ID | <86wltjzli9.fsf@linuxsc.com> |
| In reply to | #400796 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > The standard doesn't say that function pointers can be converted to > object pointer types or vice versa -- no does it say that they can't. > My conclusion is that the behavior of such a conversion is undefined > by omission. This understanding isn't right, or at best incomplete. A statement like "a pointer to an object type may be converted to a pointer to a different object type" is not a definition of behavior but a statement about what is part of the C language. The C standard lists all cases where a conversion may be done to or from a pointer type; for pointers, any case where there is not an explicit allowance is not part of the C language. Because there is no explicit allowance, an implementation is free to reject any translation unit that calls for such a conversion. Because there is no requirement for a diagnostic, an implementation is free to accept programs that do call for such a conversion. Certainly if an implementation accepts a program that converts an object pointer to a function pointer, or vice versa, then the behavior of any such construct is undefined; but implementations are not obliged to accept any program whose source indicates any such conversion.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-21 10:38 -0700 |
| Message-ID | <116a2es$gkc1$1@kst.eternal-september.org> |
| In reply to | #401399 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> The standard doesn't say that function pointers can be converted to
>> object pointer types or vice versa -- no does it say that they can't.
>> My conclusion is that the behavior of such a conversion is undefined
>> by omission.
>
> This understanding isn't right, or at best incomplete.
[snip]
I disagree.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-08-21 18:25 +0000 |
| Message-ID | <VK0iS.12497$0gM6.10509@fx43.iad> |
| In reply to | #401410 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> The standard doesn't say that function pointers can be converted to >>> object pointer types or vice versa -- no does it say that they can't. >>> My conclusion is that the behavior of such a conversion is undefined >>> by omission. >> >> This understanding isn't right, or at best incomplete. >[snip] > >I disagree. Perhaps Tim was being humorous and referring to the missing 'r' after the double hyphen.... I doubt it tho.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-24 10:15 -0700 |
| Message-ID | <86fr03xwvq.fsf@linuxsc.com> |
| In reply to | #401410 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> The standard doesn't say that function pointers can be converted to
>>> object pointer types or vice versa -- no does it say that they can't.
>>> My conclusion is that the behavior of such a conversion is undefined
>>> by omission.
>>
>> This understanding isn't right, or at best incomplete.
>
> [snip]
>
> I disagree.
Well, let's explore that. Here is the context that was snipped:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> The standard doesn't say that function pointers can be converted to
>> object pointer types or vice versa -- no does it say that they can't.
>> My conclusion is that the behavior of such a conversion is undefined
>> by omission.
>
> This understanding isn't right, or at best incomplete. A statement
> like "a pointer to an object type may be converted to a pointer to a
> different object type" is not a definition of behavior but a statement
> about what is part of the C language. The C standard lists all cases
> where a conversion may be done to or from a pointer type; for
> pointers, any case where there is not an explicit allowance is not
> part of the C language. Because there is no explicit allowance, an
> implementation is free to reject any translation unit that calls for
> such a conversion. Because there is no requirement for a diagnostic,
> an implementation is free to accept programs that do call for such a
> conversion. Certainly if an implementation accepts a program that
> converts an object pointer to a function pointer, or vice versa, then
> the behavior of any such construct is undefined; but implementations
> are not obliged to accept any program whose source indicates any such
> conversion.
We start with a simple program:
// file integer.c
int
main( void ){
return 0;
}
void *
integer_to_pointer( long x ){
return (void*) x;
}
There is no problem with this program. It is in fact strictly
conforming. The cast to (void*) would have potential undefined
behavior if it were executed but since the function is never called
of course that doesn't happen. We can compile and execute it:
gcc -std=c99 -pedantic -o integer-gcc integer.c
./integer-gcc ; echo $?
0
clang -std=c99 -pedantic -o integer-clang integer.c
./integer-clang ; echo $?
0
To continue the exploration, we consider a slightly different
program:
// file floating.c
int
main( void ){
return 0;
}
void *
floating_to_pointer( double x ){
return (void*) x;
}
The only difference (not counting the change in function name)
between floating.c and integer.c is the type of the function
parameter, which has a real floating type rather than an integer
type. How does that difference affect program semantics? An easy
way to investigate that question is to try compiling and running it
(one long line of output was wrapped):
gcc -std=c99 -pedantic -o floating-gcc floating.c
floating.c: In function 'floating_to_pointer':
floating.c:10:4: error: cannot convert to a pointer type
return (void*) x;
^~~~~~
{no executable was produced}
clang -std=c99 -pedantic -o floating-clang floating.c
floating.c:10:20: error: operand of type 'double' cannot be cast
{wrapped here} to a pointer type
return (void*) x;
^
1 error generated.
{no executable was produced}
Both gcc and clang consider floating.c to have a fatal error, caused
by trying to convert the double parameter x to (void*). The
reasoning underlying this decision is fairly straightforward. The C
standard says an integer may be converted to any pointer type; in
contrast, the standard does not say floating values may be converted
to any kind of pointer type. Because the standard does not include
any such provision, floating.c is attempting to use a feature not
specified in the C standard. Because floating.c is trying to use a
feature not specified, it is not strictly conforming. Because
floating.c is not strictly conforming, the standard does not require
it to be accepted. Because there is no requirement that floating.c
be accepted, both gcc and clang choose to give an error and reject
it. I don't see any other chain of reasoning that would allow these
compilers to summarily dismiss floating.c. So I think we can feel
fairly confident that the reasoning above explains the rationale for
these compilers to not allow floating.c.
Now let's look at converting a pointer-to-function to an object
pointer type. Here is a program to help investigate that:
// file pointers.c
int
main( void ){
return 0;
}
void *
function_pointer_to_object_pointer( void x(void) ){
return (void*) x;
}
The relationship between floating types and pointer types is
analogous to the relationship beween function pointer types and
object pointer types: the C standard explicitly allows some
conversions of these types, but the standard does not say that a
function pointer type may be converted to an object pointer type,
just as it does not say that a floating type may be converted to a
pointer type. What may we expect for the semantics of pointers.c?
As before, we try compiling (two long lines of output wrapped):
gcc -std=c99 -pedantic -o pointers-gcc-warnings pointers.c
pointers.c: In function 'function_pointer_to_object_pointer':
pointers.c:10:12: warning: ISO C forbids conversion of function pointer
{wrapped here} to object pointer type [-Wpedantic]
return (void*) x;
^
./pointers-gcc-warnings ; echo $?
0
gcc -std=c99 -pedantic-errors -o pointers-gcc-errors pointers.c
pointers.c: In function 'function_pointer_to_object_pointer':
pointers.c:10:12: error: ISO C forbids conversion of function pointer
{wrapped here} to object pointer type [-Wpedantic]
return (void*) x;
^
{no executable was produced}
clang -std=c99 -pedantic -o pointers-clang pointers.c
./pointers-clang ; echo $?
0
(Here we have run gcc twice, first giving option -pedantic and next
giving option -pedantic-errors.) The behaviors of gcc and clang are
different: clang compiles pointers.c without giving any diagnostics,
but gcc gives a diagnostic saying "ISO C forbids conversion of
function pointer to object pointer type [-Wpedantic]", which is only
a warning under -pedantic but an error under -pedantic-errors.
In both cases how the compilers behave is consistent with the C
standard. There is no requirement to accept pointers.c, using the
same reasoning explained above, and gcc makes that choice, rejecting
pointers.c when -pedantic-errors is in force. At the same time
though there is no requirement /not/ to accept pointers.c, and clang
chooses to accept it without complaint. (Of course diagnostics may
be given whether a program is accepted or not.)
Note that if converting a floating type or a function pointer type
to a (void*) were only undefined behavior, and not more than that,
then all of these programs would be strictly conforming, and so
would have to be accepted. But that doesn't match how the compilers
behave.
Note also that the behaviors of gcc and clang are consistent with
what I said before, which was given in the re-inserted excerpt
above.
Considering all that, what is your current assessment? Is it your
position that your understanding of the C standard is somehow better
than not only how I read it but also how it is understood by both
gcc developers and clang developers? Or have you changed your
views?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-02 19:01 -0700 |
| Message-ID | <114osqc$urbi$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.
Lawrence, you've never explained what you mean here by "directly
compatible". Will you please do so?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-08-03 19:59 +0000 |
| Message-ID | <114qrv6$1vf$1@reader1.panix.com> |
| In reply to | #400731 |
In article <114osqc$urbi$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >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. > >Lawrence, you've never explained what you mean here by "directly >compatible". Will you please do so? Or, will he please not. Lawrence is a well-known troll. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-30 03:50 -0700 |
| Message-ID | <114fa9a$1mrbt$1@kst.eternal-september.org> |
| In reply to | #400576 |
Richard Harnden <richard.nospam@gmail.invalid> writes:
[...]
> Can a pointer have a value of zero, but not be a null pointer?
I'm not sure what you mean by that. "zero" is not a value of any
pointer type.
> 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;
> }
The very first `p--` has undefined behavior, since it attempts
to cause p to point before the beginning of an allocated object.
It might very well result in p==NULL eventually (after about 100
trillion iterations on my system), but that doesn't mean anything.
A much simpler illegitimate way to generate something that looks and
probably acts like a null pointer on most implementations is:
char *p;
memset(&p, 0, sizeof p);
A compiler make assumptions that prevent the code from doing what you
might expect.
A null pointer value can be validly obtained by converting a null
pointer constant to a pointer type, or as the result of some library
functions (e.g., malloc(SIZE_MAX) unless it actually succeeds),
or by copying an existing null pointer value.
--
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]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web