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 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2023-05-07 09:37 +0300 |
| Message-ID | <87v8h4bqb7.fsf@zotaspaz.fatphil.org> |
| In reply to | #170165 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > 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. You've confused simplification with uglification. You've even overlooked that the freakish ugliness wasn't even consistent. 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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-07-20 09:09 -0700 |
| Message-ID | <865y6e1s5y.fsf@linuxsc.com> |
| In reply to | #170196 |
Phil Carmody <pc+usenet@asdf.org> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> 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. > > You've confused simplification with uglification. You've even > overlooked that the freakish ugliness wasn't even consistent. I'm stating their view, not my own.
[toc] | [prev] | [next] | [standalone]
| From | Lowell Gilbert <lgusenet@be-well.ilk.org> |
|---|---|
| Date | 2023-04-04 21:19 -0400 |
| Message-ID | <44v8ib15yl.fsf@be-well.ilk.org> |
| In reply to | #169814 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Lynn McGuire <lynnmcguire5@gmail.com> writes: > >> On 4/4/2023 6:30 AM, Dan Cross wrote: >>> In article <u0fn0g$34scf$1@dont-email.me>, >>> Lynn McGuire <lynnmcguire5@gmail.com> wrote: >>>> "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly >>>> with Special Guest Borer Yekai Pan >>>> https://queue.acm.org/detail.cfm?id=3588242 >>>> [snip] >>> Yikes. That article is truly awful. >>> ACM should be ashamed. >>> - Dan C. >> >> Written by real programmers, not journalists. What do you expect ? Not >> everyone is Donald Knuth or Niklaus Wirth. > > I would expect a more serious tone from an ACM publication, but the > journal (ACMQUEUE) is one I don't know and it may well have a more > relaxed editorial policy than I am used to. I don't like hyperbole and > sarcasm in technical publications but I am not "down with the kids" > these days. Queue is Not An Academic Journal. Because, apparently, working software professionals never read academic journals, so it's critical to make clear that they aren't one. Not that they're necessarily all that wrong. > I agree with the authors that the change declaring realloc(..., 0) to be > undefined is worrying, but I can't follow their reasoning about the > history. They suggest something had already happened in C17 that set C > on a course towards this "breaking change" but I can't find what they > refer to. I think they're saying that before C17, realloc to a size of zero was implementation defined, and that C17 changed that to it being undefined. That isn't quite right, because it was implementation-defined both before and after. But (I think; I don't have a full copy of C17 at hand) the limitations were changed, and realloc to a size of zero was explicitly described as obsolescent. Unless I'm mistaken factually (possible, as I mentioned) I think it's reasonable to consider C17 to be moving towards disallowing the behaviour. The article's author(s) liked being able to assume that realloc to zero size would reliably be equivalent to freeing the object pointed to and setting the pointer to null. This was never a portable assumption, but their implementation no longer has the option of specifying the behaviour. This does cause what previously may have been perfectly reasonable code to now be undefined. Be well. -- Lowell Gilbert, embedded/networking software engineer http://be-well.ilk.org/~lowell/
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-04-05 03:36 +0100 |
| Message-ID | <87sfdf6ooe.fsf@bsb.me.uk> |
| In reply to | #169817 |
Lowell Gilbert <lgusenet@be-well.ilk.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Lynn McGuire <lynnmcguire5@gmail.com> writes: >> >>> On 4/4/2023 6:30 AM, Dan Cross wrote: >>>> In article <u0fn0g$34scf$1@dont-email.me>, >>>> Lynn McGuire <lynnmcguire5@gmail.com> wrote: >>>>> "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly >>>>> with Special Guest Borer Yekai Pan >>>>> https://queue.acm.org/detail.cfm?id=3588242 >>>>> [snip] >>>> Yikes. That article is truly awful. >>>> ACM should be ashamed. >>>> - Dan C. >>> >>> Written by real programmers, not journalists. What do you expect ? Not >>> everyone is Donald Knuth or Niklaus Wirth. >> >> I would expect a more serious tone from an ACM publication, but the >> journal (ACMQUEUE) is one I don't know and it may well have a more >> relaxed editorial policy than I am used to. I don't like hyperbole and >> sarcasm in technical publications but I am not "down with the kids" >> these days. > > Queue is Not An Academic Journal. Because, apparently, working software > professionals never read academic journals, so it's critical to make > clear that they aren't one. > > Not that they're necessarily all that wrong. Yes, I see it's described as a magazine. >> I agree with the authors that the change declaring realloc(..., 0) to be >> undefined is worrying, but I can't follow their reasoning about the >> history. They suggest something had already happened in C17 that set C >> on a course towards this "breaking change" but I can't find what they >> refer to. > > I think they're saying that before C17, realloc to a size of zero was > implementation defined, and that C17 changed that to it being > undefined. That isn't quite right, because it was implementation-defined > both before and after. But (I think; I don't have a full copy of C17 at > hand) the limitations were changed, and realloc to a size of zero was > explicitly described as obsolescent. Unless I'm mistaken factually > (possible, as I mentioned) I think it's reasonable to consider > C17 to be moving towards disallowing the behaviour. I only have a draft of C17. The fact that C standards cost a lot of money is a valid point. I can't justify paying anything just to be able to chat on comp.lang.c about some finer points. The draft I have suggests that C17 just codified what implementation currently do: "If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned to indicate an error, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object." and more specifically in realloc: "If size is zero and memory for the new object is not allocated, it is implementation-defined whether the old object is deallocated. If the old object is not deallocated, its value shall be unchanged." But this may not be the final wording. > The article's author(s) liked being able to assume that realloc to > zero size would reliably be equivalent to freeing the object pointed > to and setting the pointer to null. ... and returning a null pointer. > This was never a portable > assumption, but their implementation no longer has the option of > specifying the behaviour. This does cause what previously may have > been perfectly reasonable code to now be undefined. I don't think the code was ever perfectly reasonable, but I took their point to be simply that it was not undefined as it will become. I was probably being a bit generous. I thought they knew is was not good code, but that it was, at least, never undefined because care was taken with the use of the returned pointer and it does not assume that realloc(ptr, 0) return NULL. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Opus <ifonly@youknew.org> |
|---|---|
| Date | 2023-04-05 05:10 +0200 |
| Message-ID | <u0ior1$3oeqh$3@dont-email.me> |
| In reply to | #169819 |
Le 05/04/2023 à 04:36, Ben Bacarisse a écrit : > I don't think the code was ever perfectly reasonable, but I took their > point to be simply that it was not undefined as it will become. Yeah, to be fair, in standard versions before C17, this was a bit of a grey area. While the behavior of realloc (like malloc and calloc) *regarding the new allocation* was clearly implementation-defined, the behavior as to the old object passed as parameter was, at best, implicit. "The realloc function deallocates the old object pointed to by ptr and returns a pointer to a new object that has the size specified by size." The implicit part is that we could assume from the above that whatever the size parameter is, the realloc function starts by deallocating the old object, and what happens after that is implementation-defined if size is 0. C17 makes it more explicit and definitely makes it clear that even the deallocation is implementation-defined in this case. So this was at least known for sure with C17 that the deallocation itself was implementation-defined. Nothing new. But the old phrasing was so unexplicit that it was reasonable not to count on any particular behavior. Reading the article and the point about the cost of the standard, it's not completely clear the author(s) had really read the previous versions very attentively anyway. What it really shows IMO and is backed up by experience is that many, if not most C developers have never read the C std anyway and many assume they know C from their own experience and the behavior of the particular tools they have used. Whether this would change if the standard became a free download remains to be seen. I am skeptical. Drafts are not hard to get ahold of and late drafts are usually close enough to the final text.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-04-05 07:54 -0400 |
| Message-ID | <jkdXL.2028861$9sn9.1277919@fx17.iad> |
| In reply to | #169820 |
On 4/4/23 11:10 PM, Opus wrote: > Le 05/04/2023 à 04:36, Ben Bacarisse a écrit : >> I don't think the code was ever perfectly reasonable, but I took their >> point to be simply that it was not undefined as it will become. > > Yeah, to be fair, in standard versions before C17, this was a bit of a > grey area. While the behavior of realloc (like malloc and calloc) > *regarding the new allocation* was clearly implementation-defined, the > behavior as to the old object passed as parameter was, at best, implicit. > > "The realloc function deallocates the old object pointed to by > ptr and returns a pointer to a new object that has the size > specified by size." > > The implicit part is that we could assume from the above that whatever > the size parameter is, the realloc function starts by deallocating the > old object, and what happens after that is implementation-defined if > size is 0. > > C17 makes it more explicit and definitely makes it clear that even the > deallocation is implementation-defined in this case. So this was at > least known for sure with C17 that the deallocation itself was > implementation-defined. Nothing new. > > But the old phrasing was so unexplicit that it was reasonable not to > count on any particular behavior. > > Reading the article and the point about the cost of the standard, it's > not completely clear the author(s) had really read the previous versions > very attentively anyway. > > What it really shows IMO and is backed up by experience is that many, if > not most C developers have never read the C std anyway and many assume > they know C from their own experience and the behavior of the particular > tools they have used. > > Whether this would change if the standard became a free download remains > to be seen. I am skeptical. Drafts are not hard to get ahold of and late > drafts are usually close enough to the final text. > The issue is that realloc DOESN'T start by deallocating the old buffer, but must allocate the new buffer (possibly just resizing the existing buffer in place), and then copying the data if needed. One key point is that if the new allocation failed, then the old buffer was guaranteed to still be allocated and was usable, and this was indicated by returning a null pointer. We thus have a conflict in the definition of the API for realloc. If a zero size parameter means act like free, then realloc has no non-null value it can return to indicate "success", so needs to return null, but that means that a null return doesn't mean the input pointer is still valid. Thus the speciification, and code trying hard to conform to that specification, needs a lot of words/code to handle the size 0 final case. Also, this goes back to the idea that malloc could return unique 0-byte allocations as an implementation option (because some chose to to that way back when). This is a option that has some uses, but also makes some code harder to maintain. And for such a system, a call with a 0 size would return a non-null pointer, so realloc(ptr, 0) wasn't the equivalent of a free, as it returned a pointer that should eventually be actually free'd.
[toc] | [prev] | [next] | [standalone]
| From | Opus <ifonly@youknew.org> |
|---|---|
| Date | 2023-04-05 21:31 +0200 |
| Message-ID | <u0kiaf$gcc$1@dont-email.me> |
| In reply to | #169825 |
Le 05/04/2023 à 13:54, Richard Damon a écrit : > On 4/4/23 11:10 PM, Opus wrote: >> Le 05/04/2023 à 04:36, Ben Bacarisse a écrit : >>> I don't think the code was ever perfectly reasonable, but I took their >>> point to be simply that it was not undefined as it will become. >> >> Yeah, to be fair, in standard versions before C17, this was a bit of a >> grey area. While the behavior of realloc (like malloc and calloc) >> *regarding the new allocation* was clearly implementation-defined, the >> behavior as to the old object passed as parameter was, at best, implicit. >> >> "The realloc function deallocates the old object pointed to by >> ptr and returns a pointer to a new object that has the size >> specified by size." >> >> The implicit part is that we could assume from the above that whatever >> the size parameter is, the realloc function starts by deallocating the >> old object, and what happens after that is implementation-defined if >> size is 0. >> >> C17 makes it more explicit and definitely makes it clear that even the >> deallocation is implementation-defined in this case. So this was at >> least known for sure with C17 that the deallocation itself was >> implementation-defined. Nothing new. >> >> But the old phrasing was so unexplicit that it was reasonable not to >> count on any particular behavior. >> >> Reading the article and the point about the cost of the standard, it's >> not completely clear the author(s) had really read the previous >> versions very attentively anyway. >> >> What it really shows IMO and is backed up by experience is that many, >> if not most C developers have never read the C std anyway and many >> assume they know C from their own experience and the behavior of the >> particular tools they have used. >> >> Whether this would change if the standard became a free download >> remains to be seen. I am skeptical. Drafts are not hard to get ahold >> of and late drafts are usually close enough to the final text. >> > > The issue is that realloc DOESN'T start by deallocating the old buffer, > but must allocate the new buffer (possibly just resizing the existing > buffer in place), and then copying the data if needed. All the standard says is what I quoted above. It absolutely doesn't state that it must allocate the new buffer *before* deallocating, even if it appears to make complete sense from a functional POV - since realloc has to copy existing data. So, functionally speaking, I agree that the implementation couldn't do anything else, but in a standard, you have to be extra explicit, and in this case, it wouldn't have been hard to do so. The description STARTS with "The realloc function deallocates the old object pointed to by ptr". It is definitely pretty badly written, at best. A simple algorithm in pseudo-code instead of this relatively confusing sequence of sentences would have done the trick. But as I said, it was described so badly that between this and what you pointed out, it has always been reasonable not to count on any reasonable behavior when passing 0 as size. I have personally never done that, but I certainly have seen it in third-party code, and again it all comes more from relying on the behavior of particular implementations that from a confusing phrasing in the std, which most have not read anyway.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-16 06:12 -0700 |
| Message-ID | <864jpg2coh.fsf@linuxsc.com> |
| In reply to | #169825 |
Richard Damon <Richard@Damon-Family.org> writes: > On 4/4/23 11:10 PM, Opus wrote: > >> Le 05/04/2023 at 04:36, Ben Bacarisse a ecrit: >> >>> I don't think the code was ever perfectly reasonable, but I took >>> their point to be simply that it was not undefined as it will >>> become. >> >> Yeah, to be fair, in standard versions before C17, this was a bit of >> a grey area. While the behavior of realloc (like malloc and calloc) >> *regarding the new allocation* was clearly implementation-defined, >> the behavior as to the old object passed as parameter was, at best, >> implicit. >> >> "The realloc function deallocates the old object pointed to >> by ptr and returns a pointer to a new object that has the >> size specified by size." >> >> The implicit part is that we could assume from the above that >> whatever the size parameter is, the realloc function starts by >> deallocating the old object, and what happens after that is >> implementation-defined if size is 0. >> >> C17 makes it more explicit and definitely makes it clear that even >> the deallocation is implementation-defined in this case. So this >> was at least known for sure with C17 that the deallocation itself >> was implementation-defined. Nothing new. >> >> But the old phrasing was so unexplicit that it was reasonable not >> to count on any particular behavior. >> >> Reading the article and the point about the cost of the standard, >> it's not completely clear the author(s) had really read the >> previous versions very attentively anyway. >> >> What it really shows IMO and is backed up by experience is that >> many, if not most C developers have never read the C std anyway and >> many assume they know C from their own experience and the behavior >> of the particular tools they have used. >> >> Whether this would change if the standard became a free download >> remains to be seen. I am skeptical. Drafts are not hard to get >> ahold of and late drafts are usually close enough to the final >> text. > > The issue is that realloc DOESN'T start by deallocating the old > buffer, but must allocate the new buffer (possibly just resizing > the existing buffer in place), and then copying the data if > needed. > > One key point is that if the new allocation failed, then the old > buffer was guaranteed to still be allocated and was usable, and > this was indicated by returning a null pointer. > > We thus have a conflict in the definition of the API for realloc. > If a zero size parameter means act like free, then realloc has no > non-null value it can return to indicate "success", so needs to > return null, but that means that a null return doesn't mean the > input pointer is still valid. > > Thus the speciification, and code trying hard to conform to that > specification, needs a lot of words/code to handle the size 0 > final case. This summary description is somewhere between misleading and wrong. It implies some things that aren't true, and it glosses over some aspects that are critical to understanding what actually transpired. In the original C standard (ANSI C, aka C89), there is no question that a realloc() call with a size of zero will free() a non-null argument. It is implementation-defined what value is returned in such cases: the return value can be a null pointer, or it can be a "unique pointer", which means a pointer value distinct from any other pointer value obtained by other means (including specifically pointer values returned by other calls to malloc(), realloc(), etc). But the key point is that the original object is always free()'d, and there is no question or ambiguity about that. Ten years later, in C99, the description for realloc() changed. The C99 description says "If memory for the new object cannot be allocated, the old object is not deallocated and its value is unchanged," and does not call out a size of zero as a specific case. A reasonable conjecture is that some implementation was not following the C89/C90 requirement to free the old space in some cases where the new size is zero, and rather than sticking to their guns the ISO C committee changed the rule to accommodate these non-conforming implementations. (I should add that I have not gone looking for evidence to support this conjecture. Still it does seem reasonable as a conjecture.) But notice something else. The revised wording says "If memory for the new object cannot be allocated, ...". But whenever the new size is no larger than the old size, memory for "the new object" always /can/ be allocated, because if nothing else the original pointer could be returned unchanged. There is even an explicit statement in the standard that the pointer to the new object "may have the same value as a pointer to the old object". Wording in the C99 standard doesn't allow the possibility that realloc() with a size of zero could misbehave in the sense that a null pointer could be returned but the old object was not free()'d (in the as-if sense). To be fair, presumably this consequence was unintentional. The C17 standard gives a tacit admission of that oversight in the 'Returns' portion of the realloc() description, changing "or a null pointer if the new object /could/ not be allocated" to "or a null pointer if the new object /has/ not been allocated" (emphasis added). Still, for more than a decade after C99, and years after C11, a reasonable reading of the C standard could give the impression that realloc() with a size of zero would never give a "faulty" return value, and the old pointer value passed to realloc() could safely be forgotten. > Also, this goes back to the idea that malloc could return unique > 0-byte allocations as an implementation option (because some chose > to to that way back when). This is a option that has some uses, > but also makes some code harder to maintain. And for such a > system, a call with a 0 size would return a non-null pointer, so > realloc(ptr, 0) wasn't the equivalent of a free, as it returned a > pointer that should eventually be actually free'd. The idea that unique-pointers-for-size-zero makes code harder to maintain is backwards. Presumably if one knew in advance that the allocation size is zero either malloc() would not be called or rather than calling realloc() the code would just call free() directly. The point is what happens when the size is the result of a calculation, so we don't know in advance that it will be zero. In that case what we /want/ in a non-null pointer, pointing to an object that corresponds to the size requested. Personally I am not a fan of the "unique pointer" style of malloc() and realloc(), but it is consistent and from that perspective makes code easier to maintain, not harder. That is of course assuming no "faulty" return values for realloc() with a size of zero. The ISO C committee should have the courage to require realloc() with a size of zero simply cannot "fail", and always returns a non-null value on those implementations for which malloc(0) can return a non-null value. The proposal that realloc() with a size of zero be undefined behavior is at best remarkably shortsighted.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-05 09:20 -0700 |
| Message-ID | <86lej65mih.fsf@linuxsc.com> |
| In reply to | #169819 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Lowell Gilbert <lgusenet@be-well.ilk.org> writes:
[earlier context]
>>>>>> "Catch-23: The New C Standard,Sets the World on Fire"
>>>>>> https://queue.acm.org/detail.cfm?id=3588242
>>>>>> [snip]
>>>>>
>> I think they're saying that before C17, realloc to a size of zero
>> was implementation defined, and that C17 changed that to it being
>> undefined. That isn't quite right, because it was
>> implementation-defined both before and after. But (I think; I
>> don't have a full copy of C17 at hand) the limitations were
>> changed, and realloc to a size of zero was explicitly described as
>> obsolescent. Unless I'm mistaken factually (possible, as I
>> mentioned) I think it's reasonable to consider C17 to be moving
>> towards disallowing the behaviour.
>
> I only have a draft of C17. The fact that C standards cost a lot of
> money is a valid point. I can't justify paying anything just to be
> able to chat on comp.lang.c about some finer points.
>
> The draft I have suggests that C17 just codified what implementation
> currently do: [...]
I think you can find the C17 information you're looking for by
looking at these two documents:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2438.htm
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-05 10:07 -0700 |
| Message-ID | <86h6tu5kbk.fsf@linuxsc.com> |
| In reply to | #169814 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: [context] >>>> "Catch-23: The New C Standard,Sets the World on Fire" >>>> by Terence Kelly >>>> https://queue.acm.org/detail.cfm?id=3588242 [...] > But their example stack code lends itself to a puzzle: on what > implementation assumptions does it depend? I believe it is not > fully portable for reasons that are unrelated to the realloc > implementation. [...] Can you elaborate on this comment? I don't see what you're getting at.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-04-05 20:23 +0100 |
| Message-ID | <875yaa6sls.fsf@bsb.me.uk> |
| In reply to | #169835 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > > [context] > >>>>> "Catch-23: The New C Standard,Sets the World on Fire" >>>>> by Terence Kelly >>>>> https://queue.acm.org/detail.cfm?id=3588242 > > [...] > >> But their example stack code lends itself to a puzzle: on what >> implementation assumptions does it depend? I believe it is not >> fully portable for reasons that are unrelated to the realloc >> implementation. [...] > > Can you elaborate on this comment? I don't see what you're > getting at. What happens when sizeof int == 1? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-05 21:20 -0700 |
| Message-ID | <868rf563qh.fsf@linuxsc.com> |
| In reply to | #169840 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >> [context] >> >>>>>> "Catch-23: The New C Standard,Sets the World on Fire" >>>>>> by Terence Kelly >>>>>> https://queue.acm.org/detail.cfm?id=3588242 >> >> [...] >> >>> But their example stack code lends itself to a puzzle: on what >>> implementation assumptions does it depend? I believe it is not >>> fully portable for reasons that are unrelated to the realloc >>> implementation. [...] >> >> Can you elaborate on this comment? I don't see what you're >> getting at. > > What happens when sizeof int == 1? Clearly if push() is called when N == SIZE_MAX (which is possible only if sizeof (int) == 1) then the code misbehaves. To me this eventuality is more like an unlikely corner case than it is an implementation assumption. Granted, the misbehavior can occur only on some implementations, but the problem is that the code is wrong, not that it has an implementation dependency. That said, I see now how this situation fits with what you said earlier mentioning "a puzzle" (although it still feels like the phrase "implementation assumptions" is more misdirection than it is something else).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-04-06 17:03 +0100 |
| Message-ID | <87355d576v.fsf@bsb.me.uk> |
| In reply to | #169848 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>> >>> [context] >>> >>>>>>> "Catch-23: The New C Standard,Sets the World on Fire" >>>>>>> by Terence Kelly >>>>>>> https://queue.acm.org/detail.cfm?id=3588242 >>> >>> [...] >>> >>>> But their example stack code lends itself to a puzzle: on what >>>> implementation assumptions does it depend? I believe it is not >>>> fully portable for reasons that are unrelated to the realloc >>>> implementation. [...] >>> >>> Can you elaborate on this comment? I don't see what you're >>> getting at. >> >> What happens when sizeof int == 1? > > Clearly if push() is called when N == SIZE_MAX (which is possible > only if sizeof (int) == 1) then the code misbehaves. To me this > eventuality is more like an unlikely corner case than it is an > implementation assumption. Granted, the misbehavior can occur > only on some implementations, but the problem is that the code is > wrong, not that it has an implementation dependency. That said, > I see now how this situation fits with what you said earlier > mentioning "a puzzle" (although it still feels like the phrase > "implementation assumptions" is more misdirection than it is > something else). I wouldn't say that the code is wrong. It may never have been written to be portable and there may even be a static assert or some other test that checks the assumptions the programmer made. At least that's how I see it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-06 20:34 +0000 |
| Message-ID | <u0nach$rfm$1@reader2.panix.com> |
| In reply to | #169853 |
In article <87355d576v.fsf@bsb.me.uk>, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>[snip] >> Clearly if push() is called when N == SIZE_MAX (which is possible >> only if sizeof (int) == 1) then the code misbehaves. To me this >> eventuality is more like an unlikely corner case than it is an >> implementation assumption. Granted, the misbehavior can occur >> only on some implementations, but the problem is that the code is >> wrong, not that it has an implementation dependency. That said, >> I see now how this situation fits with what you said earlier >> mentioning "a puzzle" (although it still feels like the phrase >> "implementation assumptions" is more misdirection than it is >> something else). > >I wouldn't say that the code is wrong. It may never have been written >to be portable and there may even be a static assert or some other test >that checks the assumptions the programmer made. At least that's how I >see it. It was presented as _idiomatic_ and representative of an "exemplary pattern" (the authors words). They put in a tiny hedge by saying it worked for systems with "zero-NULL" semantics, but it's clear they thought it widely applicable. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-04-07 00:25 +0100 |
| Message-ID | <87r0sw4mqy.fsf@bsb.me.uk> |
| In reply to | #169854 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <87355d576v.fsf@bsb.me.uk>, > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>>[snip] >>> Clearly if push() is called when N == SIZE_MAX (which is possible >>> only if sizeof (int) == 1) then the code misbehaves. To me this >>> eventuality is more like an unlikely corner case than it is an >>> implementation assumption. Granted, the misbehavior can occur >>> only on some implementations, but the problem is that the code is >>> wrong, not that it has an implementation dependency. That said, >>> I see now how this situation fits with what you said earlier >>> mentioning "a puzzle" (although it still feels like the phrase >>> "implementation assumptions" is more misdirection than it is >>> something else). >> >>I wouldn't say that the code is wrong. It may never have been written >>to be portable and there may even be a static assert or some other test >>that checks the assumptions the programmer made. At least that's how I >>see it. > > It was presented as _idiomatic_ and representative of an > "exemplary pattern" (the authors words). > > They put in a tiny hedge by saying it worked for systems > with "zero-NULL" semantics, but it's clear they thought it > widely applicable. I /would/ call that aspect as wrong. It's a awful use of realloc. I was addressing another issue (the failure when sizeof int == 1) which Tim considered a corner case, and I saw as an assumption about the implementation. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-07-19 08:56 -0700 |
| Message-ID | <86edl328vc.fsf@linuxsc.com> |
| In reply to | #169854 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <87355d576v.fsf@bsb.me.uk>, > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> [snip] >>> Clearly if push() is called when N == SIZE_MAX (which is possible >>> only if sizeof (int) == 1) then the code misbehaves. To me this >>> eventuality is more like an unlikely corner case than it is an >>> implementation assumption. Granted, the misbehavior can occur >>> only on some implementations, but the problem is that the code is >>> wrong, not that it has an implementation dependency. That said, >>> I see now how this situation fits with what you said earlier >>> mentioning "a puzzle" (although it still feels like the phrase >>> "implementation assumptions" is more misdirection than it is >>> something else). >> >> I wouldn't say that the code is wrong. It may never have been >> written to be portable and there may even be a static assert or >> some other test that checks the assumptions the programmer made. >> At least that's how I see it. > > It was presented as _idiomatic_ and representative of an > "exemplary pattern" (the authors words). I believe you are misunderstanding what is being represented here. The claim is not that the code in the three function bodies is idiomatic and exemplary (which the paper itself makes clear later in the "Drills" section). Rather it is that the style of use of realloc() is idiomatic and exemplary, which surely is the case for semantics of realloc() that is under discussion. > They put in a tiny hedge by saying it worked for systems > with "zero-NULL" semantics, but it's clear they thought it > widely applicable. Certainly it /was/ applicable for at least the ten years between the C89 standard and the C99 standard, and probably generally applicable for at least several years on either side of that range. As far as the expectations of the user community go, probably it was perceived as being applicable until some time between the C11 standard and the C17 standard.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-06 19:40 -0700 |
| Message-ID | <86zg7k4dp3.fsf@linuxsc.com> |
| In reply to | #169853 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>> >>>> [context] >>>> >>>>>>>> "Catch-23: The New C Standard,Sets the World on Fire" >>>>>>>> by Terence Kelly >>>>>>>> https://queue.acm.org/detail.cfm?id=3588242 >>>> >>>> [...] >>>> >>>>> But their example stack code lends itself to a puzzle: on what >>>>> implementation assumptions does it depend? I believe it is not >>>>> fully portable for reasons that are unrelated to the realloc >>>>> implementation. [...] >>>> >>>> Can you elaborate on this comment? I don't see what you're >>>> getting at. >>> >>> What happens when sizeof int == 1? >> >> Clearly if push() is called when N == SIZE_MAX (which is possible >> only if sizeof (int) == 1) then the code misbehaves. To me this >> eventuality is more like an unlikely corner case than it is an >> implementation assumption. Granted, the misbehavior can occur >> only on some implementations, but the problem is that the code is >> wrong, not that it has an implementation dependency. That said, >> I see now how this situation fits with what you said earlier >> mentioning "a puzzle" (although it still feels like the phrase >> "implementation assumptions" is more misdirection than it is >> something else). > > I wouldn't say that the code is wrong. It may never have been > written to be portable and there may even be a static assert or > some other test that checks the assumptions the programmer made. > At least that's how I see it. I don't disagree. My use of "wrong" was informal. A better phrasing is that as it stands the code has a potential defect. Moreover the defect is in push(), not in the resize() function. At the very least push() could use an 'assert( N < SIZE_MAX )', or something like it, before calling 'resize(N+1)'.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-04-08 02:37 -0700 |
| Message-ID | <67774114-01c7-4a5e-99c3-da4f2c1e5e47n@googlegroups.com> |
| In reply to | #169840 |
On Wednesday, 5 April 2023 at 20:23:42 UTC+1, Ben Bacarisse wrote: > Tim Rentsch <tr.1...@z991.linuxsc.com> writes: > > > Ben Bacarisse <ben.u...@bsb.me.uk> writes: > > > > [context] > > > >>>>> "Catch-23: The New C Standard,Sets the World on Fire" > >>>>> by Terence Kelly > >>>>> https://queue.acm.org/detail.cfm?id=3588242 > > > > [...] > > > >> But their example stack code lends itself to a puzzle: on what > >> implementation assumptions does it depend? I believe it is not > >> fully portable for reasons that are unrelated to the realloc > >> implementation. [...] > > > > Can you elaborate on this comment? I don't see what you're > > getting at. > What happens when sizeof int == 1? > int *s; if (nu > SIZE_MAX / sizeof *s) will fail. Well spotted.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-04-08 21:04 +0100 |
| Message-ID | <875ya63ztk.fsf@bsb.me.uk> |
| In reply to | #169861 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Wednesday, 5 April 2023 at 20:23:42 UTC+1, Ben Bacarisse wrote: >> Tim Rentsch <tr.1...@z991.linuxsc.com> writes: >> >> > Ben Bacarisse <ben.u...@bsb.me.uk> writes: >> > >> > [context] >> > >> >>>>> "Catch-23: The New C Standard,Sets the World on Fire" >> >>>>> by Terence Kelly >> >>>>> https://queue.acm.org/detail.cfm?id=3588242 >> > >> > [...] >> > >> >> But their example stack code lends itself to a puzzle: on what >> >> implementation assumptions does it depend? I believe it is not >> >> fully portable for reasons that are unrelated to the realloc >> >> implementation. [...] >> > >> > Can you elaborate on this comment? I don't see what you're >> > getting at. >> What happens when sizeof int == 1? >> > int *s; > if (nu > SIZE_MAX / sizeof *s) > > will fail. Well spotted. It's not clear where the mistake is. When sizeof int == 1, it's fine to request nu == SIZE_MAX slots, so in some sense, the test is correct! Considered like this, the error is in push when it asks for N+1 slots, because N+1 will then be 0. Once push has passed 0, no test in resize can fix it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-05-02 06:22 -0700 |
| Message-ID | <86r0ry27h1.fsf@linuxsc.com> |
| In reply to | #169814 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[context]
>> "Catch-23: The New C Standard,Sets the World on Fire"
>> https://queue.acm.org/detail.cfm?id=3588242
> I agree with the authors that the change declaring realloc(..., 0)
> to be undefined is worrying, but I can't follow their reasoning
> about the history. They suggest something had already happened in
> C17 that set C on a course towards this "breaking change" but I
> can't find what they refer to.
After reviewing the paper again, and also consulting the C17
draft (n2176), I believe they meant to refer to this item, in
section 7.31.12, paragraph 2:
Invoking realloc with a size argument equal to zero is an
obsolescent feature.
The change to being obsolescent is mentioned in the paper, along
with a reference to the n2176 draft, in the last sentence of the
second to last paragraph before the "Muddling Through" section.
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web