Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #169806 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2023-04-03 18:20 -0500 |
| Last post | 2023-08-29 04:45 -0700 |
| Articles | 20 on this page of 182 — 29 participants |
Back to article view | Back to comp.lang.c
"Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Lynn McGuire <lynnmcguire5@gmail.com> - 2023-04-03 18:20 -0500
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Jim Kelly <invalid@invalid.net> - 2023-04-04 04:00 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Lynn McGuire <lynnmcguire5@gmail.com> - 2023-04-04 14:49 -0500
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Rene Kita <mail@rkta.de> - 2023-04-04 09:56 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan gazelle@shell.xmission.com (Kenny McCormack) - 2023-04-04 12:20 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan scott@slp53.sl.home (Scott Lurndal) - 2023-04-04 13:50 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Rene Kita <mail@rkta.de> - 2023-04-05 08:49 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan gazelle@shell.xmission.com (Kenny McCormack) - 2023-04-05 09:23 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-05 13:07 +0000
(realloc) Angels and pins (Was: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan) gazelle@shell.xmission.com (Kenny McCormack) - 2023-04-05 14:12 +0000
Re: (realloc) Angels and pins (Was: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan) cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-05 17:09 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 20:16 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-05 21:03 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-11 04:05 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-05 17:05 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-04 11:30 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Lynn McGuire <lynnmcguire5@gmail.com> - 2023-04-04 14:51 -0500
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 01:10 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-05 00:42 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Opus <ifonly@youknew.org> - 2023-04-05 02:55 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 03:01 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-05 13:29 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-05 17:15 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan scott@slp53.sl.home (Scott Lurndal) - 2023-04-05 15:27 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-05 10:40 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-05 18:55 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-06 00:37 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-05 17:40 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-12 05:46 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-06 12:34 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan John Forkosh <forkosh@panix.com> - 2023-04-06 05:42 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-07 12:16 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Kaz Kylheku <864-117-4973@kylheku.com> - 2023-04-07 11:38 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-09 07:23 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-09 17:04 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-09 19:34 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 09:45 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 14:52 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 17:29 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 11:48 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 18:10 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 12:19 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-04-10 09:55 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 10:41 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 11:22 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Bart <bc@freeuk.com> - 2023-04-10 21:22 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 14:22 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-10 22:36 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Bart <bc@freeuk.com> - 2023-04-11 00:11 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 11:34 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 15:37 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 11:57 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 17:26 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 14:27 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 18:45 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-11 04:50 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Spiros Bousbouras <spibou@gmail.com> - 2023-04-10 15:58 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 12:08 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 17:27 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-11 04:47 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 10:26 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 14:51 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 11:20 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 15:35 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 12:04 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 17:34 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 11:24 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-04-11 16:17 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Bart <bc@freeuk.com> - 2023-04-11 18:13 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-04-11 17:58 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-09 12:41 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 09:31 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 09:46 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 16:29 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 16:37 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 11:26 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 17:43 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 12:19 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 18:35 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Öö Tiib <ootiib@hot.ee> - 2023-04-10 10:02 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 20:14 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 11:34 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ike Naar <ike@sdf.org> - 2023-04-10 21:47 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-10 23:04 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Öö Tiib <ootiib@hot.ee> - 2023-04-11 01:08 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 11:26 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Öö Tiib <ootiib@hot.ee> - 2023-04-11 02:43 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-11 15:14 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 11:35 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 12:09 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-11 19:46 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-04-11 22:44 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-12 09:46 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-12 02:35 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-04-13 22:26 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-09 06:12 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 13:10 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 19:11 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan scott@slp53.sl.home (Scott Lurndal) - 2023-04-10 17:22 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 19:33 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 19:41 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan scott@slp53.sl.home (Scott Lurndal) - 2023-04-10 18:13 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 11:30 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 10:53 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 11:25 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 11:25 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 11:13 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 20:27 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 11:54 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 21:01 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 19:06 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 21:20 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 19:46 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 13:17 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 13:16 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 14:54 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 20:44 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-11 05:01 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-11 11:27 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 11:41 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-11 12:50 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-12 09:51 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-12 09:12 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 09:58 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 09:54 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 11:21 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 17:58 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-11 05:31 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 09:50 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-09 12:44 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-09 20:19 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-09 12:55 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-09 21:44 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-09 19:53 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 20:33 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-16 07:18 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-05 12:53 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-06 12:30 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-08 18:46 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-09 19:35 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 09:07 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-07-20 22:35 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan vallor <vallor@cultnix.org> - 2023-07-22 12:54 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-22 22:04 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan vallor <vallor@cultnix.org> - 2023-07-24 10:44 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-22 16:28 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan vallor <vallor@cultnix.org> - 2023-07-24 08:38 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-07-24 18:55 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan om@iki.fi (Otto J. Makela) - 2023-07-26 11:30 +0300
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-26 19:28 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-07 13:08 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-08-15 12:01 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 15:49 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-08-28 23:42 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Spiros Bousbouras <spibou@gmail.com> - 2023-08-29 00:51 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-08-29 01:20 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-05 18:24 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Phil Carmody <pc+usenet@asdf.org> - 2023-04-17 09:25 +0300
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-18 11:56 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-05-02 07:12 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Phil Carmody <pc+usenet@asdf.org> - 2023-05-07 09:37 +0300
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 09:09 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-04-04 21:19 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 03:36 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Opus <ifonly@youknew.org> - 2023-04-05 05:10 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Richard Damon <Richard@Damon-Family.org> - 2023-04-05 07:54 -0400
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Opus <ifonly@youknew.org> - 2023-04-05 21:31 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-16 06:12 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-05 09:20 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-05 10:07 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 20:23 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-05 21:20 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-06 17:03 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-06 20:34 +0000
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-07 00:25 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-19 08:56 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-06 19:40 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-04-08 02:37 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-08 21:04 +0100
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-05-02 06:22 -0700
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-09 16:00 +0200
Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Michael S <already5chosen@yahoo.com> - 2023-08-29 04:45 -0700
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-07-20 09:07 -0700 |
| Message-ID | <86a5vq1s8y.fsf@linuxsc.com> |
| In reply to | #169886 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86v8i54yk5.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> I think you misunderstood my comment. I didn't mean to say >> anything about what the authors say about the evolution of >> realloc(). I meant only that the code they gave works just fine >> (not counting the problem when 'sizeof (int) == 1' that Ben B >> pointed out) -- importantly, under the assumptions that the >> authors explicitly stated -- and that they didn't say anything >> about whether the code is portable or well-defined if considered >> outside of those assumptions. The authors may have some opinions >> about whether the code /should/ work in general, but they don't >> make any claims about whether it /does/ work in general, and that >> point is the only one I mean to address. > > No, I understood that, but I disagree: I believe that they were > trying to make a more general statement, beyond simply the > circumstances they outlined. Then I think that either you are misreading what they say or you are seeing something that isn't there. I went back and thoroughly reviewed the paper, carefully reading each sentence. In no case did any statement fall outside the bounds I outlined above.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-07-20 22:35 +0000 |
| Message-ID | <u9ccrl$i2q$1@reader2.panix.com> |
| In reply to | #170969 |
In article <86a5vq1s8y.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: > >> In article <86v8i54yk5.fsf@linuxsc.com>, >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >>> I think you misunderstood my comment. I didn't mean to say >>> anything about what the authors say about the evolution of >>> realloc(). I meant only that the code they gave works just fine >>> (not counting the problem when 'sizeof (int) == 1' that Ben B >>> pointed out) -- importantly, under the assumptions that the >>> authors explicitly stated -- and that they didn't say anything >>> about whether the code is portable or well-defined if considered >>> outside of those assumptions. The authors may have some opinions >>> about whether the code /should/ work in general, but they don't >>> make any claims about whether it /does/ work in general, and that >>> point is the only one I mean to address. >> >> No, I understood that, but I disagree: I believe that they were >> trying to make a more general statement, beyond simply the >> circumstances they outlined. > >Then I think that either you are misreading what they say >or you are seeing something that isn't there. I went back >and thoroughly reviewed the paper, carefully reading each >sentence. In no case did any statement fall outside the >bounds I outlined above. Maybe I am; truthfully, I haven't given it (the article) much thought since it came up months ago now. Let's look at the relevant section of the article (thankfully it has been edited since initially published to remove some of the more offensive language: the slur about "neurodivergent ideas" is gone), with some commentary about where I'm coming from interspersed: |The C89 and C99 standards committees strongly recommended that |allocation interfaces malloc, calloc, and realloc return a null |pointer in response to zero-byte requests.3,6 This implies that |realloc(p,0) should unconditionally free(p) and return NULL: No |new allocation happens in this case, so there's no possibility |of an allocation failure. For brevity, let "zero-null" denote |allocator implementations that comply with the C89/C99 |guidance. Ok. Here the author suggests that the C89 and C99 standards suggest that `malloc(0)` really ought to return NULL. |The Swiss-Army-knife aspect of realloc is daunting at first, |but this interface rewards patient study. Soon you realize that |zero-null realloc was thoughtfully designed to enable elegant |dynamic arrays that do exactly the right thing under all |circumstances, obviating the need for clunky and error-prone |code to handle grow-from-zero and shrink-to-zero as special |cases. This seems specious, at best. Doug McIlroy implemented realloc and this is the opposite of what he requested when it was standardized: https://www.tuhs.org/pipermail/tuhs/2015-September/007452.html Note that the original author of `realloc` requested that `realloc(0)` retun something other than NULL. That directly contradicts the author's suggestion that `realloc` was "thoughtfully designed to enable elegant dynamic arrays". Moreover, the `realloc0` function that was discussed here does not strike me as either "clunky" or "error-prone", and makes the authors' code well-defined on any implementation. Given their noxious code style, it's litearlly a one-line fix. Sure, I suppose it's subjective? |Figure 1 illustrates idiomatic realloc via a simple stack that |grows with every push() and shrinks with every pop(). Pointer S |and counter N (lines 1 and 2) represent the stack: S points to |an array of N strictly positive ints. Because they are |statically allocated, initially the pointer is NULL and the |counter is zero, indicating an empty stack. Function resize |(lines 4-10) resizes the stack to a given new capacity, |checking for arithmetic overflow (line 6) before calling |realloc and checking the return value for memory exhaustion |(line 8). Allocation failure is inferred when a nonzero new |size is requested but NULL is returned; zero-null realloc also |returns NULL when the second argument is zero, but this does |not indicate an allocation failure because no allocation was |attempted. (Checking errno doesn't enable portable code to |detect allocation failure because the C standards don't say |how out-of-memory affects errno.) Thanks to zero-null realloc's |versatility, the resize function need not consider whether the |stack is growing from zero or shrinking to zero or re-sizing in |some other way; everything Just Works regardless. This paragraph is the root of my objection; particularly the first sentence. This code is described as "idiomatic", but according to whom? Moreover, that sentence doesn't explicitly mention "zero-null realloc"; they defer discussion of that until later in the paragraph (if it were me, I'd have prefaced the entire thing with something like, "For implementations that provide zero-null semantics, ..."). Critically, they _don't describe what happens outside of their zero-null semantic model_. Would replacing the `realloc` call in their code with the ternary expression discussed earlier in this thread not be "idiomatic"? Could an argument be made that it is even more idiomatic to use an `if` statement here to guard against the `realloc(0)` case? They go on: |The code of figure 1 follows a few simple rules implicit in the |semantics of zero-null realloc. Functions push and pop (lines |12-23) access the stack only via subscripts on S, because |realloc may move the array to a different location in memory. |They never dereference S when N is zero. The resize function |resists the temptation of reckless S = realloc(S,...), which |destroys the entry point into the array when allocation fails, |thereby leaking memory and losing data. It strikes me that every thing they mention in this paragraph is equally applicable outside of the zero-null semantic model they defined. |I've been seeing code resembling figure 1 for 30 years, |starting with the work of an older schoolmate who had bothered |to read the fine manual; the clarity and simplicity of his code |left a deep impression. In the decades since then I have |repeatedly found idiomatic realloc in serious production code, |usually while scanning for p = realloc(p,...) bugs. What does this mean? What fine manual did the author's schoolmate read? What does it mean to have used this code (or something rather like it for 30 years) if not that it was portable? Were the authors using the same platform the entire time, with no upgrades? I very much doubt it. |Imagine, then, my dismay when I learned that C23 declares |realloc(ptr,0) to be undefined behavior, thereby pulling the |rug out from under a widespread and exemplary pattern |deliberately condoned by C89 through C11. So much for stare |decisis. Compile idiomatic realloc code as C23 and the compiler |might maul the source in most astonishing ways and your machine |could ignite at runtime. "...thereby pulling the rug out from under a widespread and exemplary pattern deliberately condoned by C89 through C11." Say what now? This pattern has been implementation defined- defined, and thus always fraught, for decades now. The scenario mentioned (upgrading a compiler or library) could blow the code up with C11, too; granted, the failure case might not be so dramatic as spontaneous combustion; recompilation or relinking with an upgraded compiler or library could change to "zero non-null" semantics and mask allocation failures. I think a reasonable reader could see the language and use of words like, "widespread", "exemplary" and "condoned" by earlier standards, not to mention "idiomatic" and conclude the authors suggest there is some level of portability to this code that is not, in fact there. For the record, a reasonable reader could conclude the opposite, as well; I merely suggest that it is ambiguous. When combined with their incorrect statements about the motivation behind the design of `realloc` and the overall tone of the article, I'm not giving them the benefit of the doubt. I did talk to JeanHyde about the motivation, and it sure seemed reasonable to me: the root issue has caused production failures in the wild. In other words, code like the authors' "exemplary" example caused real outages. Everyone agreed that the situation with regard to making `realloc` UB sucked, but it was the best of a set of bad options. The people on the committee are not ignorant fools, after all. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2023-07-22 12:54 +0000 |
| Message-ID | <u9gjin$3pvhi$1@dont-email.me> |
| In reply to | #170992 |
On Thu, 20 Jul 2023 22:35:33 -0000 (UTC), cross@spitfire.i.gajendra.net (Dan Cross) wrote in <u9ccrl$i2q$1@reader2.panix.com>: > (thankfully it has been > edited since initially published to remove some of the more offensive > language: the slur about "neurodivergent ideas" is gone) I can attest to seeing that in one of the earlier releases of the document. I wonder if the ACM ever published a post mortem / mea culpa for any of that...or did they sweep it under the rug and hope nobody noticed? I've done a smattering of C programming since the 90's. I hope they don't ruin the language, its stability is part of its appeal. Learned C using "Learn C Now" from Microsoft in the 90's. This was a C editor and compiler, but you couldn't save the executables, only run them. Anyway, many years later, while using gcc, I ran into a problem: I was using string constants to allocate string space, and gcc stopped allowing that by default. "-fwriteable-strings I think is the flag to allow it, but it got me thinking about safety in software, and I learned to not be as foolish with my programming. So some changes to C are good, sometimes -- just not sure these kids can steer nowadays. ;) -- -v
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-07-22 22:04 +0100 |
| Message-ID | <87wmyrmze6.fsf@bsb.me.uk> |
| In reply to | #171063 |
vallor <vallor@cultnix.org> writes: > Anyway, many years later, while using gcc, I ran into a > problem: I was using string constants to allocate > string space, and gcc stopped allowing that by default. > "-fwriteable-strings I think is the flag to > allow it, but it got me thinking about safety > in software, and I learned to not be as > foolish with my programming. Did you know you can write char writable[] = "this string determines the size and initial value"; ? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2023-07-24 10:44 +0000 |
| Message-ID | <u9lkm3$i26a$2@dont-email.me> |
| In reply to | #171115 |
On Sat, 22 Jul 2023 22:04:17 +0100, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote in <87wmyrmze6.fsf@bsb.me.uk>: > vallor <vallor@cultnix.org> writes: > >> Anyway, many years later, while using gcc, I ran into a problem: I was >> using string constants to allocate string space, and gcc stopped >> allowing that by default. >> "-fwriteable-strings I think is the flag to allow it, but it got me >> thinking about safety in software, and I learned to not be as foolish >> with my programming. > > Did you know you can write > > char writable[] = "this string determines the size and initial value"; > > ? <facepalm> Well, I do now...though I never even thought to try it, as anything that seems like writing to an actual string constant appears to be a 3rd rail to me now... I wrote a proof-of-concept program to compare behavior for writing past bounds for strings declared in this way, strdup()'ed, and malloc()'ed. valgrind segfaults on it, but it compiles and runs on its own. (Would be willing to post it with the caveat that its behavior is undefined.) -- -v
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-07-22 16:28 -0700 |
| Message-ID | <87edkzmsqn.fsf@nosuchdomain.example.com> |
| In reply to | #171063 |
vallor <vallor@cultnix.org> writes:
[...]
> Anyway, many years later, while using gcc, I ran into a
> problem: I was using string constants to allocate
> string space, and gcc stopped allowing that by default.
> "-fwriteable-strings I think is the flag to
> allow it, but it got me thinking about safety
> in software, and I learned to not be as
> foolish with my programming.
gcc removed the -fwritable-strings option in 2004. I don't know what
release that change appeared in.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2023-07-24 08:38 +0000 |
| Message-ID | <u9ld9i$i26a$1@dont-email.me> |
| In reply to | #171129 |
On Sat, 22 Jul 2023 16:28:00 -0700, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote in <87edkzmsqn.fsf@nosuchdomain.example.com>: > vallor <vallor@cultnix.org> writes: > [...] >> Anyway, many years later, while using gcc, I ran into a problem: I was >> using string constants to allocate string space, and gcc stopped >> allowing that by default. >> "-fwriteable-strings I think is the flag to allow it, but it got me >> thinking about safety in software, and I learned to not be as foolish >> with my programming. > > gcc removed the -fwritable-strings option in 2004. I don't know what > release that change appeared in. guess I'm showing my age...started the company in 1994. -- -v
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-07-24 18:55 +0000 |
| Message-ID | <u9mhf8$9kk$1@reader2.panix.com> |
| In reply to | #171063 |
In article <u9gjin$3pvhi$1@dont-email.me>, vallor <vallor@cultnix.org> wrote: >On Thu, 20 Jul 2023 22:35:33 -0000 (UTC), cross@spitfire.i.gajendra.net >(Dan Cross) wrote in <u9ccrl$i2q$1@reader2.panix.com>: > >> (thankfully it has been >> edited since initially published to remove some of the more offensive >> language: the slur about "neurodivergent ideas" is gone) > >I can attest to seeing that in one of the >earlier releases of the document. > >I wonder if the ACM ever published a post >mortem / mea culpa for any of that...or did they sweep it >under the rug and hope nobody noticed? To my knowledge, no; it was just silently removed. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | om@iki.fi (Otto J. Makela) |
|---|---|
| Date | 2023-07-26 11:30 +0300 |
| Message-ID | <875y67yt0e.fsf@tigger.extechop.net> |
| In reply to | #171227 |
cross@spitfire.i.gajendra.net (Dan Cross) wrote: > In article <u9gjin$3pvhi$1@dont-email.me>, vallor <vallor@cultnix.org> wrote: >> On Thu, 20 Jul 2023 22:35:33 -0000 (UTC), cross@spitfire.i.gajendra.net >> (Dan Cross) wrote in <u9ccrl$i2q$1@reader2.panix.com>: >>> [ https://queue.acm.org/detail.cfm?id=3588242 ] >>> (thankfully it has been edited since initially published to remove >>> some of the more offensive language: the slur about "neurodivergent >>> ideas" is gone) >> >> I can attest to seeing that in one of the earlier releases of the document. >> >> I wonder if the ACM ever published a post mortem / mea culpa for any >> of that...or did they sweep it under the rug and hope nobody noticed? > > To my knowledge, no; it was just silently removed. Archive.org still has a snapshot from 2023-04-04 with that in it: As C89 was taking shape, the neurodivergent notion of a "zero-length object" was making the rounds: Proponents argued that a non-null pointer to such an object should be returned for zero-byte allocation requests. https://web.archive.org/web/20230404195105/https://queue.acm.org/detail.cfm?id=3588242 But the 2023-04-09 version has been edited to remove it: As C89 was taking shape, the notion of a "zero-length object" was making the rounds: Proponents argued that a non-null pointer to such an object should be returned for zero-byte allocation requests. https://web.archive.org/web/20230409001708/https://queue.acm.org/detail.cfm?id=3588242
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-07-26 19:28 +0000 |
| Message-ID | <20230726122237.753@kylheku.com> |
| In reply to | #171271 |
On 2023-07-26, Otto J. Makela <om@iki.fi> wrote: > cross@spitfire.i.gajendra.net (Dan Cross) wrote: > >> In article <u9gjin$3pvhi$1@dont-email.me>, vallor <vallor@cultnix.org> wrote: >>> On Thu, 20 Jul 2023 22:35:33 -0000 (UTC), cross@spitfire.i.gajendra.net >>> (Dan Cross) wrote in <u9ccrl$i2q$1@reader2.panix.com>: >>>> [ https://queue.acm.org/detail.cfm?id=3588242 ] >>>> (thankfully it has been edited since initially published to remove >>>> some of the more offensive language: the slur about "neurodivergent >>>> ideas" is gone) >>> >>> I can attest to seeing that in one of the earlier releases of the document. >>> >>> I wonder if the ACM ever published a post mortem / mea culpa for any >>> of that...or did they sweep it under the rug and hope nobody noticed? >> >> To my knowledge, no; it was just silently removed. > > Archive.org still has a snapshot from 2023-04-04 with that in it: > > As C89 was taking shape, the neurodivergent notion of a > "zero-length object" was making the rounds: Proponents argued > that a non-null pointer to such an object should be returned for > zero-byte allocation requests. > > https://web.archive.org/web/20230404195105/https://queue.acm.org/detail.cfm?id=3588242 > > But the 2023-04-09 version has been edited to remove it: Haha! Who is the neuro? He who can wrap his head around the concept of zero, or he who struggles with zero length due to a learning disability? Of course they removed it; ranting against a straightforward concept that neurotypical grade school children can wrap their heads around made them look like fools, separately from the remark also being offensive to some people. Note that they didn't replace "neurodivergent" with something else like "puzzing", "odd", "counterintuitive" or any other mild pejorative; it was just removed. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-07 13:08 -0700 |
| Message-ID | <86y1imbopb.fsf@linuxsc.com> |
| In reply to | #170992 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86a5vq1s8y.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> cross@spitfire.i.gajendra.net (Dan Cross) writes: >> >>> In article <86v8i54yk5.fsf@linuxsc.com>, >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> I think you misunderstood my comment. I didn't mean to say >>>> anything about what the authors say about the evolution of >>>> realloc(). I meant only that the code they gave works just fine >>>> (not counting the problem when 'sizeof (int) == 1' that Ben B >>>> pointed out) -- importantly, under the assumptions that the >>>> authors explicitly stated -- and that they didn't say anything >>>> about whether the code is portable or well-defined if considered >>>> outside of those assumptions. The authors may have some opinions >>>> about whether the code /should/ work in general, but they don't >>>> make any claims about whether it /does/ work in general, and that >>>> point is the only one I mean to address. >>> >>> No, I understood that, but I disagree: I believe that they were >>> trying to make a more general statement, beyond simply the >>> circumstances they outlined. >> >> Then I think that either you are misreading what they say >> or you are seeing something that isn't there. I went back >> and thoroughly reviewed the paper, carefully reading each >> sentence. In no case did any statement fall outside the >> bounds I outlined above. > > Maybe I am; truthfully, I haven't given it (the article) much > thought since it came up months ago now. > > Let's look at the relevant section of the article (thankfully it > has been edited since initially published to remove some of the > more offensive language: the slur about "neurodivergent ideas" > is gone), with some commentary about where I'm coming from > interspersed: I appreciate you making an effort to write a thoughtful reply. I will try to respond in kind. > |The C89 and C99 standards committees strongly recommended that > |allocation interfaces malloc, calloc, and realloc return a null > |pointer in response to zero-byte requests.3,6 This implies that > |realloc(p,0) should unconditionally free(p) and return NULL: No > |new allocation happens in this case, so there's no possibility > |of an allocation failure. For brevity, let "zero-null" denote > |allocator implementations that comply with the C89/C99 > |guidance. > > Ok. Here the author suggests that the C89 and C99 standards > suggest that `malloc(0)` really ought to return NULL. Note that he doesn't say the C89/C99 standards but the standards committees. The comments he's talking about are given in the C Rationale documents (and so indicated by the footnote numbers), which of course were written by committee members. You might want to take a look at those documents, or at least the later one, C99 Rationale V5 (dated April 2003); there are five or six paragraphs talking about this question. > |The Swiss-Army-knife aspect of realloc is daunting at first, > |but this interface rewards patient study. Soon you realize that > |zero-null realloc was thoughtfully designed to enable elegant > |dynamic arrays that do exactly the right thing under all > |circumstances, obviating the need for clunky and error-prone > |code to handle grow-from-zero and shrink-to-zero as special > |cases. > > This seems specious, at best. Doug McIlroy implemented realloc > and this is the opposite of what he requested when it was > standardized: > https://www.tuhs.org/pipermail/tuhs/2015-September/007452.html > > Note that the original author of `realloc` requested that > `realloc(0)` retun something other than NULL. That directly > contradicts the author's suggestion that `realloc` was > "thoughtfully designed to enable elegant dynamic arrays". The paper does not say that. What it does say (with my emphasis added) is that "_zero-null_ realloc was thoughtfully designed" to have the mentioned property, which I believe it was. Personally I find dynamic arrays done using zero-null realloc semantics to be cleaner than those using McIlroy-style semantics (and also cleaner than those that have to work with both). The paper does not make any statement that I can see about the design process of zero-nonnull realloc; clearly that version of realloc is considered worse, in the paper's view, than zero-null realloc, but it doesn't say anything about how that version was designed. > Moreover, the `realloc0` function that was discussed here does > not strike me as either "clunky" or "error-prone", and makes the > authors' code well-defined on any implementation. Given their > noxious code style, it's litearlly a one-line fix. Sure, I > suppose it's subjective? You are offering a different comparison than what he is talking about. There is no question that having to write an extra function (whether realloc0 or a similar one) takes more effort and is more likely to cause error than simply layering on top of a zero-null realloc (which always does a free and returns null for a requested size of zero). The sentence you quote is talking about the zero-null style of realloc, and nothing more than that. > |Figure 1 illustrates idiomatic realloc via a simple stack that > |grows with every push() and shrinks with every pop(). Pointer S > |and counter N (lines 1 and 2) represent the stack: S points to > |an array of N strictly positive ints. Because they are > |statically allocated, initially the pointer is NULL and the > |counter is zero, indicating an empty stack. Function resize > |(lines 4-10) resizes the stack to a given new capacity, > |checking for arithmetic overflow (line 6) before calling > |realloc and checking the return value for memory exhaustion > |(line 8). Allocation failure is inferred when a nonzero new > |size is requested but NULL is returned; zero-null realloc also > |returns NULL when the second argument is zero, but this does > |not indicate an allocation failure because no allocation was > |attempted. (Checking errno doesn't enable portable code to > |detect allocation failure because the C standards don't say > |how out-of-memory affects errno.) Thanks to zero-null realloc's > |versatility, the resize function need not consider whether the > |stack is growing from zero or shrinking to zero or re-sizing in > |some other way; everything Just Works regardless. > > This paragraph is the root of my objection; particularly the > first sentence. This code is described as "idiomatic", but > according to whom? I believe you are misunderstanding the author's intent. He means the usage of realloc() is idiomatic, not that the example code is idiomatic. And I think that calling the way realloc() is used here idiomatic is a fair statement; certainly I expect there would be no problem finding plenty of examples in existing code that employ a similar usage. > Moreover, that sentence doesn't explicitly > mention "zero-null realloc"; they defer discussion of that > until later in the paragraph (if it were me, I'd have prefaced > the entire thing with something like, "For implementations that > provide zero-null semantics, ..."). I think this suggested re-write changes the meaning. Clearly the paragraph is making a point about zero-null semantics, but the code is not meant to be limited to using zero-null realloc. > Critically, they _don't > describe what happens outside of their zero-null semantic > model_. Would replacing the `realloc` call in their code with > the ternary expression discussed earlier in this thread not be > "idiomatic"? Could an argument be made that it is even more > idiomatic to use an `if` statement here to guard against the > `realloc(0)` case? The code is there to help make a point a zero-null realloc, so I think it's fair that it doesn't talk about what happens under a McIlroy-style realloc. However, the code is written so as to be usable under both kinds of realloc, so let's look at what the behavior is under the various C standards. The code always works without any problems on systems that have a zero-null malloc and realloc. On systems that have a McIlroy-style allocator: Under C89/C90 rules, the code always works without any problems. Under C99 and C11 rules, the code always works, except that it can have an undiagnosed memory leak (on some but not all of those systems) if a resize to zero cannot allocate a new object. Under C17 rules, there is basically an implementation-defined choice between C89/C90 rules and C99/C11 rules. So if the choice is one way the code always works, and if the choice is the other way an undiagnosed memory leak is possible (depending on the particular implementation-defined choices made). Furthermore, although a memory leak is possible in principle, in practice it's unlikely to occur: it's almost never the case that there isn't enough memory to allocate a minimal-sized object, and moreover it is always possible to successfully realloc to a smaller size, because if nothing else the original pointer could be returned unchanged. So the implementation would need to have done a poor job implementing realloc to be unsuccessful changing to a size of zero. I don't like memory leaks any more than the next person, but this case seems like it's pretty far down the priority list. > They go on: > > |The code of figure 1 follows a few simple rules implicit in the > |semantics of zero-null realloc. Functions push and pop (lines > |12-23) access the stack only via subscripts on S, because > |realloc may move the array to a different location in memory. > |They never dereference S when N is zero. The resize function > |resists the temptation of reckless S = realloc(S,...), which > |destroys the entry point into the array when allocation fails, > |thereby leaking memory and losing data. > > It strikes me that every thing they mention in this paragraph is > equally applicable outside of the zero-null semantic model they > defined. Yes, I think that's right, but on the other hand up to this point in the paper zero-null realloc is the only kind that's been talked about; the McIlroy-style realloc isn't discussed until later. > |I've been seeing code resembling figure 1 for 30 years, > |starting with the work of an older schoolmate who had bothered > |to read the fine manual; the clarity and simplicity of his code > |left a deep impression. In the decades since then I have > |repeatedly found idiomatic realloc in serious production code, > |usually while scanning for p = realloc(p,...) bugs. > > What does this mean? What fine manual did the author's > schoolmate read? Obviously I don't know. It may have been an early C standard or even just a draft, or the classic book by Bill Plauger, or some unrelated work on programming correctness and style. Whatever the manual may have been, I think the point is clear, namely, that simple code and simple interfaces go hand-in-hand, and simple code is easier to write using a zero-null malloc/realloc. > What does it mean to have used this code (or > something rather like it for 30 years) if not that it was > portable? Were the authors using the same platform the entire > time, with no upgrades? I very much doubt it. This usage pattern works correctly on all zero-null systems, and some zero-nonnull systems. On some, but not all, zero-nonnull systems it works fine except that there may be undiagnosed memory leaks. For most applications I expect there is no practical difference between the two. For the relatively few applications where it does matter, probably the code would choose a different overall strategy for doing memory allocation, and not use realloc at all (or use it very sparingly). > |Imagine, then, my dismay when I learned that C23 declares > |realloc(ptr,0) to be undefined behavior, thereby pulling the > |rug out from under a widespread and exemplary pattern > |deliberately condoned by C89 through C11. So much for stare > |decisis. Compile idiomatic realloc code as C23 and the compiler > |might maul the source in most astonishing ways and your machine > |could ignite at runtime. > > "...thereby pulling the rug out from under a widespread and > exemplary pattern deliberately condoned by C89 through C11." > Say what now? This pattern has been implementation defined- > defined, and thus always fraught, for decades now. The scenario > mentioned (upgrading a compiler or library) could blow the code > up with C11, too; granted, the failure case might not be so > dramatic as spontaneous combustion; recompilation or relinking > with an upgraded compiler or library could change to "zero > non-null" semantics and mask allocation failures. You're overstating the case here. The realloc usage pattern shown in the paper works for both kinds of realloc. It does have, like I said, a potential for undiagnosed memory leaks in unusual cases. The potential consequences for a to-zero realloc being undefined behavior are much worse. > I think a reasonable reader could see the language and use of > words like, "widespread", "exemplary" and "condoned" by earlier > standards, not to mention "idiomatic" and conclude the authors > suggest there is some level of portability to this code that is > not, in fact there. For the record, a reasonable reader could > conclude the opposite, as well; I merely suggest that it is > ambiguous. I think the degree of portability is in fact pretty high, and higher than you estimate it to be. In any case I think the paper isn't making any claims about portability outside of the kinds of implementations the paper is discussing. > When combined with their incorrect statements about the > motivation behind the design of `realloc` and the overall tone > of the article, I'm not giving them the benefit of the doubt. Like I said above, the statement about the design of zero-null realloc was not incorrect, it was misunderstood. My comments on what the paper says have been only about content, not about tone. I understand that you don't like the tone, and that's okay. But I think how you are reacting to the tone is getting in the way, at least to some extent, of reading the content objectively. > I did talk to JeanHyde about the motivation, and it sure seemed > reasonable to me: the root issue has caused production failures > in the wild. In other words, code like the authors' "exemplary" > example caused real outages. Those two things are not the same. It may very well be that using realloc to a zero size has caused production failures. But we do not know from that statement that the realloc usage that was discussed in the paper is what caused the problems. There are lots of different ways realloc might be used or misused. > Everyone agreed that the situation > with regard to making `realloc` UB sucked, but it was the best > of a set of bad options. The people on the committee are not > ignorant fools, after all. Like my old boss used to say, there's a difference between knowledge and wisdom. I am very skeptical of the idea that there is no better choice than undefined behavior.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-08-15 12:01 +0000 |
| Message-ID | <ubfpdu$8em$1@reader2.panix.com> |
| In reply to | #171780 |
In article <86y1imbopb.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>> In article <86a5vq1s8y.fsf@linuxsc.com>,
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>
>>>> In article <86v8i54yk5.fsf@linuxsc.com>,
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>>
>>>>> I think you misunderstood my comment. I didn't mean to say
>>>>> anything about what the authors say about the evolution of
>>>>> realloc(). I meant only that the code they gave works just fine
>>>>> (not counting the problem when 'sizeof (int) == 1' that Ben B
>>>>> pointed out) -- importantly, under the assumptions that the
>>>>> authors explicitly stated -- and that they didn't say anything
>>>>> about whether the code is portable or well-defined if considered
>>>>> outside of those assumptions. The authors may have some opinions
>>>>> about whether the code /should/ work in general, but they don't
>>>>> make any claims about whether it /does/ work in general, and that
>>>>> point is the only one I mean to address.
>>>>
>>>> No, I understood that, but I disagree: I believe that they were
>>>> trying to make a more general statement, beyond simply the
>>>> circumstances they outlined.
>>>
>>> Then I think that either you are misreading what they say
>>> or you are seeing something that isn't there. I went back
>>> and thoroughly reviewed the paper, carefully reading each
>>> sentence. In no case did any statement fall outside the
>>> bounds I outlined above.
>>
>> Maybe I am; truthfully, I haven't given it (the article) much
>> thought since it came up months ago now.
>>
>> Let's look at the relevant section of the article (thankfully it
>> has been edited since initially published to remove some of the
>> more offensive language: the slur about "neurodivergent ideas"
>> is gone), with some commentary about where I'm coming from
>> interspersed:
>
>I appreciate you making an effort to write a thoughtful reply. I
>will try to respond in kind.
Certainly. But I confess that I find it very hard to have this
conversation (or any, really) with spans of weeks or months
between posts.
>> |The C89 and C99 standards committees strongly recommended that
>> |allocation interfaces malloc, calloc, and realloc return a null
>> |pointer in response to zero-byte requests.3,6 This implies that
>> |realloc(p,0) should unconditionally free(p) and return NULL: No
>> |new allocation happens in this case, so there's no possibility
>> |of an allocation failure. For brevity, let "zero-null" denote
>> |allocator implementations that comply with the C89/C99
>> |guidance.
>>
>> Ok. Here the author suggests that the C89 and C99 standards
>> suggest that `malloc(0)` really ought to return NULL.
>
>Note that he doesn't say the C89/C99 standards but the standards
>committees. The comments he's talking about are given in the C
>Rationale documents (and so indicated by the footnote numbers),
>which of course were written by committee members. You might
>want to take a look at those documents, or at least the later
>one, C99 Rationale V5 (dated April 2003); there are five or six
>paragraphs talking about this question.
I did when this discucussion first came up, but I don't see that
being particularly relevant here. In particular, it's not clear
that they're referring to the rationale, and if they were, they
could have simply stated that.
>> |The Swiss-Army-knife aspect of realloc is daunting at first,
>> |but this interface rewards patient study. Soon you realize that
>> |zero-null realloc was thoughtfully designed to enable elegant
>> |dynamic arrays that do exactly the right thing under all
>> |circumstances, obviating the need for clunky and error-prone
>> |code to handle grow-from-zero and shrink-to-zero as special
>> |cases.
>>
>> This seems specious, at best. Doug McIlroy implemented realloc
>> and this is the opposite of what he requested when it was
>> standardized:
>> https://www.tuhs.org/pipermail/tuhs/2015-September/007452.html
>>
>> Note that the original author of `realloc` requested that
>> `realloc(0)` retun something other than NULL. That directly
>> contradicts the author's suggestion that `realloc` was
>> "thoughtfully designed to enable elegant dynamic arrays".
>
>The paper does not say that. What it does say (with my emphasis
>added) is that "_zero-null_ realloc was thoughtfully designed" to
>have the mentioned property, which I believe it was.
I see no basis to believe that. Of course you may choose to,
and there's certainly nothing wrong with that, but I find it
hard to believe that it was anything other than an in-situ
interpretation made by an implementor somewhere.
Thsi is similar to how filenames starting with a '.' are
ommitted from the default output of the Unix `ls` command not
because of a conscious design decision, but because of a bug
that was simply codified over time.
A fact I have learned is that very often systems just evolve
with no clear defining principles behind that evolution. For
example, the group at Bell Labs has acknowledged that much of
what makes up the "standard C library" is simply the set of
functions that were found useful by the maintainers of 7th
Edition Unix.
>Personally
>I find dynamic arrays done using zero-null realloc semantics to
>be cleaner than those using McIlroy-style semantics (and also
>cleaner than those that have to work with both). The paper does
>not make any statement that I can see about the design process
>of zero-nonnull realloc; clearly that version of realloc is
>considered worse, in the paper's view, than zero-null realloc,
>but it doesn't say anything about how that version was designed.
>
>> Moreover, the `realloc0` function that was discussed here does
>> not strike me as either "clunky" or "error-prone", and makes the
>> authors' code well-defined on any implementation. Given their
>> noxious code style, it's litearlly a one-line fix. Sure, I
>> suppose it's subjective?
>
>You are offering a different comparison than what he is talking
>about.
Am I? Absent the author chiming in here, that's speculation.
>There is no question that having to write an extra
>function (whether realloc0 or a similar one) takes more effort
>and is more likely to cause error than simply layering on top of
>a zero-null realloc (which always does a free and returns null
>for a requested size of zero). The sentence you quote is talking
>about the zero-null style of realloc, and nothing more than that.
Then let's modify their code without a new function.
static int resize(const size_t nu) {
int *t = NULL;
if (nu > SIZE_MAX / sizeof *S) return TOOBIG;
if (nu && ((t = realloc(S, nu * sizeof *S)) == NULL) return ALLOCFAIL;
S = t;
N = nu; return 0;
}
Again, it's subjective (and honestly, that style, copied from
the authors, is beyond hideous...), but this really isn't much
different from the original, and doesn't involve an extra
function at all and once again, sidesteps the entire problem.
>> |Figure 1 illustrates idiomatic realloc via a simple stack that
>> |grows with every push() and shrinks with every pop(). Pointer S
>> |and counter N (lines 1 and 2) represent the stack: S points to
>> |an array of N strictly positive ints. Because they are
>> |statically allocated, initially the pointer is NULL and the
>> |counter is zero, indicating an empty stack. Function resize
>> |(lines 4-10) resizes the stack to a given new capacity,
>> |checking for arithmetic overflow (line 6) before calling
>> |realloc and checking the return value for memory exhaustion
>> |(line 8). Allocation failure is inferred when a nonzero new
>> |size is requested but NULL is returned; zero-null realloc also
>> |returns NULL when the second argument is zero, but this does
>> |not indicate an allocation failure because no allocation was
>> |attempted. (Checking errno doesn't enable portable code to
>> |detect allocation failure because the C standards don't say
>> |how out-of-memory affects errno.) Thanks to zero-null realloc's
>> |versatility, the resize function need not consider whether the
>> |stack is growing from zero or shrinking to zero or re-sizing in
>> |some other way; everything Just Works regardless.
>>
>> This paragraph is the root of my objection; particularly the
>> first sentence. This code is described as "idiomatic", but
>> according to whom?
>
>I believe you are misunderstanding the author's intent. He means
>the usage of realloc() is idiomatic, not that the example code is
>idiomatic.
That is an interpretation, but not what I believe was meant.
You may reasonably disagree but again, without the author to
address the question, we're both speculating.
>And I think that calling the way realloc() is used
>here idiomatic is a fair statement; certainly I expect there
>would be no problem finding plenty of examples in existing code
>that employ a similar usage.
This looks almost like every other use of realloc I've ever
seen. If they're all similarly "idiomatic" then calling them
"idiomatic" is a fairly content-free statement.
>> Moreover, that sentence doesn't explicitly
>> mention "zero-null realloc"; they defer discussion of that
>> until later in the paragraph (if it were me, I'd have prefaced
>> the entire thing with something like, "For implementations that
>> provide zero-null semantics, ...").
>
>I think this suggested re-write changes the meaning. Clearly the
>paragraph is making a point about zero-null semantics, but the
>code is not meant to be limited to using zero-null realloc.
Then why not say that? Why talk about zero-null realloc at
length in this context without mentioning non-zero-null realloc
at all? "Oh by the way...you can use this with the other kind,
but it's not as nice because..." would actually serve to drive
their point home, if that was truly what they intended.
>> Critically, they _don't
>> describe what happens outside of their zero-null semantic
>> model_. Would replacing the `realloc` call in their code with
>> the ternary expression discussed earlier in this thread not be
>> "idiomatic"? Could an argument be made that it is even more
>> idiomatic to use an `if` statement here to guard against the
>> `realloc(0)` case?
>
>The code is there to help make a point a zero-null realloc, so I
>think it's fair that it doesn't talk about what happens under a
>McIlroy-style realloc.
Really? I think that significantly weakens their argument and
makes it murky for no good reason.
>However, the code is written so as to be
>usable under both kinds of realloc, so let's look at what the
>behavior is under the various C standards. The code always
>works without any problems on systems that have a zero-null
>malloc and realloc. On systems that have a McIlroy-style
>allocator:
>
>Under C89/C90 rules, the code always works without any problems.
>
>Under C99 and C11 rules, the code always works, except that it
>can have an undiagnosed memory leak (on some but not all of those
>systems) if a resize to zero cannot allocate a new object.
>
>Under C17 rules, there is basically an implementation-defined
>choice between C89/C90 rules and C99/C11 rules. So if the choice
>is one way the code always works, and if the choice is the other
>way an undiagnosed memory leak is possible (depending on the
>particular implementation-defined choices made).
>
>Furthermore, although a memory leak is possible in principle, in
>practice it's unlikely to occur: it's almost never the case that
>there isn't enough memory to allocate a minimal-sized object, and
>moreover it is always possible to successfully realloc to a
>smaller size, because if nothing else the original pointer could
>be returned unchanged. So the implementation would need to have
>done a poor job implementing realloc to be unsuccessful changing
>to a size of zero. I don't like memory leaks any more than the
>next person, but this case seems like it's pretty far down the
>priority list.
Except that the zero-length allocation _did_ cause production
failures, in some cases security problems, some even remotely
exploitable, and that's precisely why the committee voted to
make the interface UB (unanimously, I might add).
See https://twitter.com/__phantomderp/status/1643674954750197760
and
https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/
>> They go on:
>>
>> |The code of figure 1 follows a few simple rules implicit in the
>> |semantics of zero-null realloc. Functions push and pop (lines
>> |12-23) access the stack only via subscripts on S, because
>> |realloc may move the array to a different location in memory.
>> |They never dereference S when N is zero. The resize function
>> |resists the temptation of reckless S = realloc(S,...), which
>> |destroys the entry point into the array when allocation fails,
>> |thereby leaking memory and losing data.
>>
>> It strikes me that every thing they mention in this paragraph is
>> equally applicable outside of the zero-null semantic model they
>> defined.
>
>Yes, I think that's right, but on the other hand up to this
>point in the paper zero-null realloc is the only kind that's
>been talked about; the McIlroy-style realloc isn't discussed
>until later.
Then the authors have done a disservice to their readers, which
has been my contention all along. They may have good points,
but it's presented in such an awful way that those are dilluted.
>> |I've been seeing code resembling figure 1 for 30 years,
>> |starting with the work of an older schoolmate who had bothered
>> |to read the fine manual; the clarity and simplicity of his code
>> |left a deep impression. In the decades since then I have
>> |repeatedly found idiomatic realloc in serious production code,
>> |usually while scanning for p = realloc(p,...) bugs.
>>
>> What does this mean? What fine manual did the author's
>> schoolmate read?
>
>Obviously I don't know. It may have been an early C standard or
>even just a draft, or the classic book by Bill Plauger, or some
>unrelated work on programming correctness and style. Whatever
>the manual may have been, I think the point is clear, namely,
>that simple code and simple interfaces go hand-in-hand, and
>simple code is easier to write using a zero-null malloc/realloc.
See above. I don't think that's particularly true.
>> What does it mean to have used this code (or
>> something rather like it for 30 years) if not that it was
>> portable? Were the authors using the same platform the entire
>> time, with no upgrades? I very much doubt it.
>
>This usage pattern works correctly on all zero-null systems, and
>some zero-nonnull systems. On some, but not all, zero-nonnull
>systems it works fine except that there may be undiagnosed memory
>leaks. For most applications I expect there is no practical
>difference between the two. For the relatively few applications
>where it does matter, probably the code would choose a different
>overall strategy for doing memory allocation, and not use realloc
>at all (or use it very sparingly).
See above.
>> |Imagine, then, my dismay when I learned that C23 declares
>> |realloc(ptr,0) to be undefined behavior, thereby pulling the
>> |rug out from under a widespread and exemplary pattern
>> |deliberately condoned by C89 through C11. So much for stare
>> |decisis. Compile idiomatic realloc code as C23 and the compiler
>> |might maul the source in most astonishing ways and your machine
>> |could ignite at runtime.
>>
>> "...thereby pulling the rug out from under a widespread and
>> exemplary pattern deliberately condoned by C89 through C11."
>> Say what now? This pattern has been implementation defined-
>> defined, and thus always fraught, for decades now. The scenario
>> mentioned (upgrading a compiler or library) could blow the code
>> up with C11, too; granted, the failure case might not be so
>> dramatic as spontaneous combustion; recompilation or relinking
>> with an upgraded compiler or library could change to "zero
>> non-null" semantics and mask allocation failures.
>
>You're overstating the case here. The realloc usage pattern
>shown in the paper works for both kinds of realloc. It does
>have, like I said, a potential for undiagnosed memory leaks in
>unusual cases. The potential consequences for a to-zero realloc
>being undefined behavior are much worse.
See the linked thread and article above.
>> I think a reasonable reader could see the language and use of
>> words like, "widespread", "exemplary" and "condoned" by earlier
>> standards, not to mention "idiomatic" and conclude the authors
>> suggest there is some level of portability to this code that is
>> not, in fact there. For the record, a reasonable reader could
>> conclude the opposite, as well; I merely suggest that it is
>> ambiguous.
>
>I think the degree of portability is in fact pretty high, and
>higher than you estimate it to be. In any case I think the
>paper isn't making any claims about portability outside of
>the kinds of implementations the paper is discussing.
I think that arguement is undermind by the items linked above.
>> When combined with their incorrect statements about the
>> motivation behind the design of `realloc` and the overall tone
>> of the article, I'm not giving them the benefit of the doubt.
>
>Like I said above, the statement about the design of zero-null
>realloc was not incorrect, it was misunderstood.
Was it, though? Without the authors to confirm that, it's
impossible to say.
>My comments on what the paper says have been only about content,
>not about tone. I understand that you don't like the tone, and
>that's okay. But I think how you are reacting to the tone is
>getting in the way, at least to some extent, of reading the
>content objectively.
Perhaps; I'll concede that I find the tone interferes with the
content. Regardless, they sure do seem to be looking at the
world with blinders on, and I honestly think they're giving them
far too much credit with little reason.
>> I did talk to JeanHyde about the motivation, and it sure seemed
>> reasonable to me: the root issue has caused production failures
>> in the wild. In other words, code like the authors' "exemplary"
>> example caused real outages.
>
>Those two things are not the same. It may very well be that
>using realloc to a zero size has caused production failures. But
>we do not know from that statement that the realloc usage that
>was discussed in the paper is what caused the problems. There
>are lots of different ways realloc might be used or misused.
That's a fair point, but then the authors' trivial example of a
growable buffer wasn't particularly interesting.
>> Everyone agreed that the situation
>> with regard to making `realloc` UB sucked, but it was the best
>> of a set of bad options. The people on the committee are not
>> ignorant fools, after all.
>
>Like my old boss used to say, there's a difference between
>knowledge and wisdom. I am very skeptical of the idea that
>there is no better choice than undefined behavior.
Intelligence is knowing that a tomato is a fruit; wisdom is
knowing not to put it in fruit salad. Comp.lang.c is a place
where someone will come around to tell you that they have a
wonderful fruit salad recipe that incorporates tomatoes and
that you are objectively wrong if you don't care for it.
Given the many demands put on the committee from various parties
and the real-world issues involved, I think they made a
reasonable choice. What would you have done differently?
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-28 15:49 -0700 |
| Message-ID | <86r0nmwzn2.fsf@linuxsc.com> |
| In reply to | #172260 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
I have read through your comments. There are just a few points
where I have a response, plus at the end a more overall reaction.
> [...] I confess that I find it very hard to have this
> conversation (or any, really) with spans of weeks or months
> between posts.
Yes, I'm really sorry about that. I'm trying to do better.
> Except that the zero-length allocation _did_ cause production
> failures, [...]
>
> See https://twitter.com/__phantomderp/status/1643674954750197760
> and
> https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/
AFAICT the twitter link is just a reference to the second URL.
The paper at the second link is not concerned with what we are
discussing; it doesn't mention using realloc(). The problem
does concern "re-allocation" but the paper says this:
Re-allocation is a combination of free and malloc. If the
size of the re-allocation is 0, it is simply a free.
Any questions about realloc() don't come into the picture here.
> Then let's modify their code without a new function.
>
> static int resize(const size_t nu) {
> int *t = NULL;
> if (nu > SIZE_MAX / sizeof *S) return TOOBIG;
> if (nu && ((t = realloc(S, nu * sizeof *S)) == NULL) return ALLOCFAIL;
> S = t;
> N = nu; return 0;
> }
>
> Again, it's subjective (and honestly, that style, copied from
> the authors, is beyond hideous...), but this really isn't much
> different from the original, and doesn't involve an extra
> function at all and once again, sidesteps the entire problem.
(The line with the complicated if() has an extra left parenthesis
but that is easily remedied.)
This code leaks memory, for reasons having nothing to do with
using realloc(). Ironically it illustrates a point given in the
Kelly/Pan paper about zero-null realloc().
> [...]
Reading through your comments was disappointing. In your earlier
posting I had the impression that you were largely reacting to the
tone of the original paper. Here it seems like you were still
doing that even while you were responding to my remarks. The
tone of my remarks is not at all like that of the paper.
Your comments haven't given me any reason to think the points in
the Kelly/Pan paper are off base. If anything, just the opposite.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-08-28 23:42 +0000 |
| Message-ID | <ucjbd4$k8c$1@reader2.panix.com> |
| In reply to | #173112 |
In article <86r0nmwzn2.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>I have read through your comments. There are just a few points
>where I have a response, plus at the end a more overall reaction.
>
>> [...] I confess that I find it very hard to have this
>> conversation (or any, really) with spans of weeks or months
>> between posts.
>
>Yes, I'm really sorry about that. I'm trying to do better.
I'm sorry, but it's been nearly two weeks and this was almost
missed under a deluge of spam. Following this discussion is
simply too difficult given the amounts of time between your
responses.
Tim, I have a lot of respect for you, I really do (perhaps you
don't recall but we've corresponded several times), but without
more timely interaction this conversation is impossible for me
to maintain. I appreciate that you are trying to do better, but
it's just too awkward and honestly slightly irksome that you
would respond after so much time has elapsed.
>> Except that the zero-length allocation _did_ cause production
>> failures, [...]
>>
>> See https://twitter.com/__phantomderp/status/1643674954750197760
>> and
>> https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/
>
>AFAICT the twitter link is just a reference to the second URL.
The twitter thread is from the co-chair of the C23 committee
when asked about the realloc(..., 0)-is-UB change.
>The paper at the second link is not concerned with what we are
>discussing; it doesn't mention using realloc(). The problem
>does concern "re-allocation" but the paper says this:
>
> Re-allocation is a combination of free and malloc. If the
> size of the re-allocation is 0, it is simply a free.
>
>Any questions about realloc() don't come into the picture here.
I think the committee cochair, and the person who wrote the
paper suggesting that realloc(..., 0), become UB, would find
that surprising as that was the example they cited when asked
about this issue. (Note that JeanHyde and Seacord both weighed
in on that Twitter thread. Of course, Twitter seems to be
broken at the moment, so I find it hard to see.
>> Then let's modify their code without a new function.
>>
>> static int resize(const size_t nu) {
>> int *t = NULL;
>> if (nu > SIZE_MAX / sizeof *S) return TOOBIG;
>> if (nu && ((t = realloc(S, nu * sizeof *S)) == NULL) return ALLOCFAIL;
>> S = t;
>> N = nu; return 0;
>> }
>>
>> Again, it's subjective (and honestly, that style, copied from
>> the authors, is beyond hideous...), but this really isn't much
>> different from the original, and doesn't involve an extra
>> function at all and once again, sidesteps the entire problem.
>
>(The line with the complicated if() has an extra left parenthesis
>but that is easily remedied.)
>
>This code leaks memory, for reasons having nothing to do with
>using realloc().
Indeed it does. Easily remedied.
// Why is this style so ugly?
static int resize(const size_t nu) {
int *t = NULL;
if (nu > SIZE_MAX / sizeof *S) return TOOBIG;
if (nu) { if ((t = realloc(S, nu * sizeof *S)) == NULL) return ALLOCFAIL; }
else free(S);
S = t;
N = nu; return 0;
}
>Ironically it illustrates a point given in the
>Kelly/Pan paper about zero-null realloc().
The Queue article potentially leaked memory (if a zero-length
allocation failed), which is a pattern that has led to
production failures, so I respectfully disagree.
I'd suggest it says more about trying to respond quickly in an
informal manner, and while mantaining this hideous style.
If it were me, I'd probably write this as:
static int
resize(const size_t nu)
{
int *t;
if (nu > SIZE_MAX / sizeof(*S))
return TOOBIG;
if (nu == 0) {
free(S);
S = NULL;
N = 0;
return 0;
}
t = realloc(S, nu * sizeof(*S));
if (t == NULL)
return ALLOCFAIL;
S = t;
N = nu;
return 0;
}
Handling the exceptional cases explicitly up front, a la
Dijkstra's guarded clauses.
>> [...]
>
>Reading through your comments was disappointing. In your earlier
>posting I had the impression that you were largely reacting to the
>tone of the original paper. Here it seems like you were still
>doing that even while you were responding to my remarks. The
>tone of my remarks is not at all like that of the paper.
I'm sorry if you feel that I was responding to your tone (which
I agree was totally unlike the Queue article); that was not my
intention, so please accept my apologies if that's how it came
across.
>Your comments haven't given me any reason to think the points in
>the Kelly/Pan paper are off base. If anything, just the opposite.
The point I have tried repeatedly to make here is that
reasonable readers can come away with different interpretations
of the Queue article.
You evidently have an interpretation that you have come to
regarding its points and validity. While I maintain that much
of that is based on speculation, I'm really not trying to
change your mind: merely explain the reasoning behind _my_
interpretation.
I do maintain that the tone and some of the content of the
Queue article is objectively offensive (particularly before the
slur about neurodivergence was removed), and I would advise
caution before we disparage those on the committee as being
either uninformed or unwise. Consider that they may be privy
to a lot of things that we, here, are not.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2023-08-29 00:51 +0000 |
| Message-ID | <Y6Oy4M3MEjvyiR0tr@bongo-ra.co> |
| In reply to | #173124 |
On Mon, 28 Aug 2023 23:42:28 -0000 (UTC) cross@spitfire.i.gajendra.net (Dan Cross) wrote: > In article <86r0nmwzn2.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >cross@spitfire.i.gajendra.net (Dan Cross) writes: > >> See https://twitter.com/__phantomderp/status/1643674954750197760 > >> and > >> https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/ > > > >AFAICT the twitter link is just a reference to the second URL. > > The twitter thread is from the co-chair of the C23 committee > when asked about the realloc(..., 0)-is-UB change. > > >The paper at the second link is not concerned with what we are > >discussing; it doesn't mention using realloc(). The problem > >does concern "re-allocation" but the paper says this: > > > > Re-allocation is a combination of free and malloc. If the > > size of the re-allocation is 0, it is simply a free. > > > >Any questions about realloc() don't come into the picture here. > > I think the committee cochair, and the person who wrote the > paper suggesting that realloc(..., 0), become UB, would find > that surprising as that was the example they cited when asked > about this issue. (Note that JeanHyde and Seacord both weighed > in on that Twitter thread. Of course, Twitter seems to be > broken at the moment, so I find it hard to see. So members of the C standard committee are discussing issues of the standard on twitter ? Now *that's* scary.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-08-29 01:20 +0000 |
| Message-ID | <ucjh5j$msg$1@reader2.panix.com> |
| In reply to | #173131 |
In article <Y6Oy4M3MEjvyiR0tr@bongo-ra.co>, Spiros Bousbouras <spibou@gmail.com> wrote: >On Mon, 28 Aug 2023 23:42:28 -0000 (UTC) >cross@spitfire.i.gajendra.net (Dan Cross) wrote: >> In article <86r0nmwzn2.fsf@linuxsc.com>, >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >cross@spitfire.i.gajendra.net (Dan Cross) writes: >> >> See https://twitter.com/__phantomderp/status/1643674954750197760 >> >> and >> >> https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/ >> > >> >AFAICT the twitter link is just a reference to the second URL. >> >> The twitter thread is from the co-chair of the C23 committee >> when asked about the realloc(..., 0)-is-UB change. >> >> >The paper at the second link is not concerned with what we are >> >discussing; it doesn't mention using realloc(). The problem >> >does concern "re-allocation" but the paper says this: >> > >> > Re-allocation is a combination of free and malloc. If the >> > size of the re-allocation is 0, it is simply a free. >> > >> >Any questions about realloc() don't come into the picture here. >> >> I think the committee cochair, and the person who wrote the >> paper suggesting that realloc(..., 0), become UB, would find >> that surprising as that was the example they cited when asked >> about this issue. (Note that JeanHyde and Seacord both weighed >> in on that Twitter thread. Of course, Twitter seems to be >> broken at the moment, so I find it hard to see. > >So members of the C standard committee are discussing issues of the standard >on twitter ? Now *that's* scary. More like responding to questions about this particular issue, mostly because it was easy for me to contact JeanHyde there. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-05 18:24 -0700 |
| Message-ID | <86wmx4nlfs.fsf@linuxsc.com> |
| In reply to | #173124 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86r0nmwzn2.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> cross@spitfire.i.gajendra.net (Dan Cross) writes: >> >> I have read through your comments. There are just a few points >> where I have a response, plus at the end a more overall reaction. >> >>> [...] I confess that I find it very hard to have this >>> conversation (or any, really) with spans of weeks or months >>> between posts. >> >> Yes, I'm really sorry about that. I'm trying to do better. > > I'm sorry, but it's been nearly two weeks and this was almost > missed under a deluge of spam. Following this discussion is > simply too difficult given the amounts of time between your > responses. > > Tim, I have a lot of respect for you, I really do (perhaps you > don't recall but we've corresponded several times), but without > more timely interaction this conversation is impossible for me > to maintain. Okay. Thank you for your comments.
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2023-04-17 09:25 +0300 |
| Message-ID | <87leirkotx.fsf@zotaspaz.fatphil.org> |
| In reply to | #169815 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > That combined with the little quips about "neurodivergent" ideas You've put that word in quotes, yet I don't see it in the article. Has the article changed, or have you just dereferenced a null pointer? However, oh my, that example code they include is almost comically ugly, and I'd even go as far as to say unidiomatic for the language: https://dl.acm.org/cms/attachment/html/10.1145/3588242/assets/html/db9_fig1.png That's even more hilarious given their later emphasis on use of idioms. Phil -- We are no longer hunters and nomads. No longer awed and frightened, as we have gained some understanding of the world in which we live. As such, we can cast aside childish remnants from the dawn of our civilization. -- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-18 11:56 +0000 |
| Message-ID | <u1m0ib$p9c$1@reader2.panix.com> |
| In reply to | #170021 |
In article <87leirkotx.fsf@zotaspaz.fatphil.org>, Phil Carmody <pc+usenet@asdf.org> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >> That combined with the little quips about "neurodivergent" ideas > >You've put that word in quotes, yet I don't see it in the article. >Has the article changed, or have you just dereferenced a null pointer? The text appears to have been changed, and "neurodivergent" removed. My comment on the DL site quoted the original, if anyone wants to see what it said: https://dl.acm.org/doi/10.1145/3588242 It's rather disappointing that they did it with no acknowledgement, but I'm happy to see it gone. >However, oh my, that example code they include is almost comically ugly, >and I'd even go as far as to say unidiomatic for the language: > https://dl.acm.org/cms/attachment/html/10.1145/3588242/assets/html/db9_fig1.png >That's even more hilarious given their later emphasis on use of idioms. Yes, atrocious, isn't it? The entire argument is a straw-man: the recently discussed `realloc0` would have made the code perfectly portable and eliminated the argument entirely. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-05-02 07:12 -0700 |
| Message-ID | <86mt2m2571.fsf@linuxsc.com> |
| In reply to | #170021 |
Phil Carmody <pc+usenet@asdf.org> writes: [...] > However, oh my, that example code they include is almost comically > ugly, and I'd even go as far as to say unidiomatic for the language: > https://dl.acm.org/cms/attachment/html/ > 10.1145/3588242/assets/html/db9_fig1.png > That's even more hilarious given their later emphasis on use of > idioms. The code in the paper is written not to be an example of production quality code but to illustrate what the authors are saying about using realloc(). The code is knowingly simplified to do that. The paper points out this simplification later on, in point 1 of the "Drills" section: "Figure 1's stack sacrifices speed for clarity and brevity", along with a reference to Kernighan and Pike's book "The Practice of Programming". I suspect lots of people react to the paper mainly on the basis of their impression of this code, without understanding why the code is there or what it is meant to illustrate.
[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