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 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-04-05 03:01 +0100 |
| Message-ID | <874jpv84uv.fsf@bsb.me.uk> |
| In reply to | #169815 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <87zg7n89zw.fsf@bsb.me.uk>, > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>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. >> >>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. >>This is not, technically speaking, a bug since I have no reason to >>suppose the code was intended to be portable across all conforming C >>implementations, but I'd have pointed it out, had I been a reviewer, >>since it's an unnecessary distraction to the reader. >> >>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. > > The authors, bluntly, wrong: the behavior of realloc() when the > size argument is 0, the implementation is, as it always has > been since C89, implementation defined. I got the impression they knew that. However, in C89, realloc(ptr, 0) must behave like free(ptr). That changed, I think, in C99 with the removal of that guarantee. There is some evidence that they are little confused about that guarantee having been lost, thought of course it is still permitted. > Moreoever, there's no > way to tell whether the underlying object was actually free'd or > not from the return alone, and checking `errno` is not portable. Yes. > The proposal to make realloc with size 0 UB is not bad here: > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf I did not see any explanation there. What's wrong with leaving it implementation defined? Is the motivation to tidy up an historical mess? > The authors tried to make it out like their code was portable > and well-defined. It was not. I did not get that impression. I thought their point was simply that the code is not undefined and that being implementation defined is safer than being undefined. I think the code is poor, and I would not want it in any code base of mine. It can leak memory (in two different ways) but it does not have formally undefined behaviour. > That combined with the little quips about "neurodivergent" ideas > or about marijuana legalization (really?) smack of proud > ignorance. That they can't understand at all what `unreachable` > may be used for makes me think that they may not have as good of > a handle on the language as they claim. I didn't like the tone at all, and I was actually rather surprised by it, given the publisher. But maybe that specific journal is not a very serious one. I'd never heard of it before today. > Oh, and among the people championing having `malloc(0)` return a > non-NULL pointer were Rob Pike and Doug McIlroy. Not that one > need appeal to authority, but the article's authors would have > done well to at least, perhaps, listen to some of the viewpoints > of folks from the lab where C was born before pouring derision > on ideas that they didn't seem to have a great understanding of. They didn't discuss that implementation option at all and I agree that they should have done. But did they pour scorn on it? I only ask because I don't want to read it again! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-05 13:29 +0000 |
| Message-ID | <u0jt3l$cmu$1@reader2.panix.com> |
| In reply to | #169818 |
In article <874jpv84uv.fsf@bsb.me.uk>,
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>[snip]
>>>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.
>>
>> The authors, bluntly, wrong: the behavior of realloc() when the
>> size argument is 0, the implementation is, as it always has
>> been since C89, implementation defined.
>
>I got the impression they knew that. However, in C89, realloc(ptr, 0)
>must behave like free(ptr). That changed, I think, in C99 with the
>removal of that guarantee. There is some evidence that they are little
>confused about that guarantee having been lost, thought of course it is
>still permitted.
Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero
and *ptr* is not a null pointer, the object it points to is
freed."
C99 removes that language, presumably because C89 did not
mandate a particular return value for realloc() in the case
where it behaves like free(), meaning that it is impossible
to tell from the return value alone whether it freed anything
or not. Ben, you already know this, for but others who are
reading along, consider the following:
size_t size = SOMETHING;
char *nptr, *ptr = malloc(size);
// Do something. Error checking elided for brevity.
// Assume that somehow, size is set to zero.
nptr = realloc(ptr, size /* 0 */);
if (nptr == NULL) {
// Now what? Did we fail?
// Or did realloc just,
// if (size == 0) free(ptr);
// return ptr;
// ?
return;
}
// So nptr != NULL.... Ok.
ptr = realloc(nptr, size /* still zero... */);
// Did we just double-free? Or did we malloc()?
// Without also checking size, it's impossible to tell.
>> Moreoever, there's no
>> way to tell whether the underlying object was actually free'd or
>> not from the return alone, and checking `errno` is not portable.
>
>Yes.
>
>> The proposal to make realloc with size 0 UB is not bad here:
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf
>
>I did not see any explanation there. What's wrong with leaving it
>implementation defined? Is the motivation to tidy up an historical
>mess?
I believe that's correct. The original specification in C89 was
arguably a mistake; the interface, as specified, was almost
impossible to use correctly and, as perverse as I find UB in
general, I feel like the committee made the right decision here.
>> The authors tried to make it out like their code was portable
>> and well-defined. It was not.
>
>I did not get that impression. I thought their point was simply that
>the code is not undefined and that being implementation defined is safer
>than being undefined.
>
>I think the code is poor, and I would not want it in any code base of
>mine. It can leak memory (in two different ways) but it does not have
>formally undefined behaviour.
That is true, but the behavior is implementation-defined and on
some platforms, their code will simply be wrong in the sense of
having a memory leak or worse.
>> That combined with the little quips about "neurodivergent" ideas
>> or about marijuana legalization (really?) smack of proud
>> ignorance. That they can't understand at all what `unreachable`
>> may be used for makes me think that they may not have as good of
>> a handle on the language as they claim.
>
>I didn't like the tone at all, and I was actually rather surprised by
>it, given the publisher. But maybe that specific journal is not a very
>serious one. I'd never heard of it before today.
Queue is meant to be, "for the practitioner." But as the
comment I left on the ACM digital library said, this makes
practitioners look ignorant.
I am very disappointed in ACM here.
>> Oh, and among the people championing having `malloc(0)` return a
>> non-NULL pointer were Rob Pike and Doug McIlroy. Not that one
>> need appeal to authority, but the article's authors would have
>> done well to at least, perhaps, listen to some of the viewpoints
>> of folks from the lab where C was born before pouring derision
>> on ideas that they didn't seem to have a great understanding of.
>
>They didn't discuss that implementation option at all and I agree that
>they should have done. But did they pour scorn on it? I only ask
>because I don't want to read it again!
I would argue that they did, yes. They went on at length about
how it zero-sized objects are an incredibly bad idea, without
giving any consideration to _why_ one might want to use one;
they did the same with `unreachable`.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-04-05 17:15 +0200 |
| Message-ID | <u0k3au$3uelq$1@dont-email.me> |
| In reply to | #169827 |
On 05/04/2023 15:29, Dan Cross wrote: > In article <874jpv84uv.fsf@bsb.me.uk>, > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >> I got the impression they knew that. However, in C89, realloc(ptr, 0) >> must behave like free(ptr). That changed, I think, in C99 with the >> removal of that guarantee. There is some evidence that they are little >> confused about that guarantee having been lost, thought of course it is >> still permitted. > > Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero > and *ptr* is not a null pointer, the object it points to is > freed." > I don't have a C89 reference handy, but I don't think realloc(ptr, 0) has ever been required to behave like free(ptr). That is one of the allowed behaviours, but it is not the only one. In particular, even if it first acts like free(ptr), it can then allocate a zero-size buffer afterwards. Thus it may not be behaving like free(ptr) alone - it can do more. And if you don't take that into account, your code will leak memory.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-04-05 15:27 +0000 |
| Message-ID | <NrgXL.1274531$MVg8.611500@fx12.iad> |
| In reply to | #169831 |
David Brown <david.brown@hesbynett.no> writes: >On 05/04/2023 15:29, Dan Cross wrote: >> In article <874jpv84uv.fsf@bsb.me.uk>, >> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > >>> I got the impression they knew that. However, in C89, realloc(ptr, 0) >>> must behave like free(ptr). That changed, I think, in C99 with the >>> removal of that guarantee. There is some evidence that they are little >>> confused about that guarantee having been lost, thought of course it is >>> still permitted. >> >> Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero >> and *ptr* is not a null pointer, the object it points to is >> freed." >> > >I don't have a C89 reference handy, but I don't think realloc(ptr, 0) >has ever been required to behave like free(ptr). That is one of the >allowed behaviours, but it is not the only one. In particular, even if >it first acts like free(ptr), it can then allocate a zero-size buffer >afterwards. Thus it may not be behaving like free(ptr) alone - it can >do more. And if you don't take that into account, your code will leak >memory. The Single Unix Specification notes: "If the size of the space requested is zero, the behavior shall be implementation-defined: either a null pointer is returned, or the behavior shall be as if the size were some non-zero value, except that the behavior is undefined if the returned pointer is used to access an object. If the space cannot be allocated, the object shall remain unchanged."
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-05 10:40 -0700 |
| Message-ID | <87mt3mgrda.fsf@nosuchdomain.example.com> |
| In reply to | #169831 |
David Brown <david.brown@hesbynett.no> writes:
> On 05/04/2023 15:29, Dan Cross wrote:
>> In article <874jpv84uv.fsf@bsb.me.uk>,
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>>> I got the impression they knew that. However, in C89, realloc(ptr, 0)
>>> must behave like free(ptr). That changed, I think, in C99 with the
>>> removal of that guarantee. There is some evidence that they are little
>>> confused about that guarantee having been lost, thought of course it is
>>> still permitted.
>> Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero
>> and *ptr* is not a null pointer, the object it points to is
>> freed."
>
> I don't have a C89 reference handy, but I don't think realloc(ptr, 0)
> has ever been required to behave like free(ptr). That is one of the
> allowed behaviours, but it is not the only one. In particular, even
> if it first acts like free(ptr), it can then allocate a zero-size
> buffer afterwards. Thus it may not be behaving like free(ptr) alone -
> it can do more. And if you don't take that into account, your code
> will leak memory.
ISO C90:
7.10.3 Memory management functions
[...]
If the space cannot be allocated, a null pointer is returned. If
the size of the space requested is zero, the behavior is
implementation-defined; the value returned shall be either a
null pointer or a unique pointer.
...
7.10.3.4 The realloc function
Synopsis
#include <stdlib.h>
void *realloc(void *ptr, size_t size);
Description
The `realloc` function changes the size of the object pointed
to by `ptr` to the size specified by `size`. The contents of
the object shall be unchanged up to the lesser of the new and
old sizes. If the new size is larger, the value of the newly allocated portion of the object is indeterminate. If `ptr` is a
null pointer, the `realloc` function behaves like the `malloc`
function for the specified size. Otherwise, if `ptr` does not
match a pointer earlier returned by the `calloc`, `malloc`, or
`realloc` function, or if the space has been deallocated by a call
to the `free` or `realloc` function. the behavior is undefined.
If the space cannot be allocated, the object pointed to by `ptr`
is unchanged. If `size` is zero and `ptr` is not a null pointer,
the object it points to is freed.
Returns
The `realloc` function returns either a null pointer or a pointer
to the possibly moved allocated space.
ISO C99 expands the "Memory management functions" description:
If the size of the space requested is zero, the behavior is
implementation- defined: either a null pointer is returned, 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.
Where C90 says that realloc changes the size of the object, C99 says
that it deallocates the old object and allocates a new one. This isn't
a change in behavior, but it more accurately describes what's going on.
If `ptr` is a null pointer, the `realloc function behaves like the
`malloc` function for the specified size. Otherwise, if `ptr` does
not match a pointer earlier returned by the `calloc`, `malloc`, or
`realloc` function, or if the space has been deallocated by a call
to the `free` or `realloc` function, the behavior is undefined. If
memory for the new object cannot be allocated, the old object is not
deallocated and its value is unchanged.
Returns
The `realloc` function returns a pointer to the new object (which
may have the same value as a pointer to the old object), or a null
pointer if the new object could not be allocated.
C11 makes a few minor changes (adding references to aligned_alloc and
"fundamental alignment requirement").
C17 makes a few minor changes, but nothing relevant to the current
discussion.
C23 (N3096 draft) makes some more changes:
Any bytes in the new object beyond the size of the old object have
[indeterminate->unspecified] values.
Otherwise, if ptr does not match a pointer earlier returned by a
memory management function, or if the space has been deallocated by
a call to the free or realloc function, [+or if the size is zero+],
the behavior is undefined.
References:
C99 draft: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
C11 draft: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
C23 draft: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-05 18:55 +0000 |
| Message-ID | <u0kg6f$2qa$1@reader2.panix.com> |
| In reply to | #169831 |
In article <u0k3au$3uelq$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 05/04/2023 15:29, Dan Cross wrote:
>> In article <874jpv84uv.fsf@bsb.me.uk>,
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>>> I got the impression they knew that. However, in C89, realloc(ptr, 0)
>>> must behave like free(ptr). That changed, I think, in C99 with the
>>> removal of that guarantee. There is some evidence that they are little
>>> confused about that guarantee having been lost, thought of course it is
>>> still permitted.
>>
>> Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero
>> and *ptr* is not a null pointer, the object it points to is
>> freed."
>
>I don't have a C89 reference handy, but I don't think realloc(ptr, 0)
>has ever been required to behave like free(ptr). That is one of the
>allowed behaviours, but it is not the only one. In particular, even if
>it first acts like free(ptr), it can then allocate a zero-size buffer
>afterwards. Thus it may not be behaving like free(ptr) alone - it can
>do more. And if you don't take that into account, your code will leak
>memory.
What I quoted above is the actual text from C89. To repeat:
"If *size* is zero and *ptr* is not a null pointer,
the object it points to is freed."
(C89, sec 7.10.3.3.)
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-04-06 00:37 +0200 |
| Message-ID | <u0kt7r$24ku$1@dont-email.me> |
| In reply to | #169838 |
On 05/04/2023 20:55, Dan Cross wrote: > In article <u0k3au$3uelq$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> On 05/04/2023 15:29, Dan Cross wrote: >>> In article <874jpv84uv.fsf@bsb.me.uk>, >>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >> >>>> I got the impression they knew that. However, in C89, realloc(ptr, 0) >>>> must behave like free(ptr). That changed, I think, in C99 with the >>>> removal of that guarantee. There is some evidence that they are little >>>> confused about that guarantee having been lost, thought of course it is >>>> still permitted. >>> >>> Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero >>> and *ptr* is not a null pointer, the object it points to is >>> freed." >> >> I don't have a C89 reference handy, but I don't think realloc(ptr, 0) >> has ever been required to behave like free(ptr). That is one of the >> allowed behaviours, but it is not the only one. In particular, even if >> it first acts like free(ptr), it can then allocate a zero-size buffer >> afterwards. Thus it may not be behaving like free(ptr) alone - it can >> do more. And if you don't take that into account, your code will leak >> memory. > > What I quoted above is the actual text from C89. To repeat: > > "If *size* is zero and *ptr* is not a null pointer, > the object it points to is freed." > > (C89, sec 7.10.3.3.) > > - Dan C. > I am not disagreeing with that. My point is what happens /after/ the pointer ptr is freed. As far as I can tell (and I could be wrong), the function can behave in a manner similar to malloc(0) - it can either do no allocation and return a null pointer (in which case the whole thing is like free(ptr)), or it could allocate a zero-size object and return a unique pointer. (Or it could try to do such an allocation, and fail, possibly affecting errno.) It is this aspect that is, as far as I can tell, implementation dependent and non-portable.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-05 17:40 -0700 |
| Message-ID | <87edoxhmgr.fsf@nosuchdomain.example.com> |
| In reply to | #169845 |
David Brown <david.brown@hesbynett.no> writes:
> On 05/04/2023 20:55, Dan Cross wrote:
>> In article <u0k3au$3uelq$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 05/04/2023 15:29, Dan Cross wrote:
>>>> In article <874jpv84uv.fsf@bsb.me.uk>,
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>>>> I got the impression they knew that. However, in C89, realloc(ptr, 0)
>>>>> must behave like free(ptr). That changed, I think, in C99 with the
>>>>> removal of that guarantee. There is some evidence that they are little
>>>>> confused about that guarantee having been lost, thought of course it is
>>>>> still permitted.
>>>>
>>>> Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero
>>>> and *ptr* is not a null pointer, the object it points to is
>>>> freed."
>>>
>>> I don't have a C89 reference handy, but I don't think realloc(ptr, 0)
>>> has ever been required to behave like free(ptr). That is one of the
>>> allowed behaviours, but it is not the only one. In particular, even if
>>> it first acts like free(ptr), it can then allocate a zero-size buffer
>>> afterwards. Thus it may not be behaving like free(ptr) alone - it can
>>> do more. And if you don't take that into account, your code will leak
>>> memory.
>> What I quoted above is the actual text from C89. To repeat:
>> "If *size* is zero and *ptr* is not a null pointer,
>> the object it points to is freed."
>> (C89, sec 7.10.3.3.)
>> - Dan C.
>>
>
> I am not disagreeing with that. My point is what happens /after/ the
> pointer ptr is freed. As far as I can tell (and I could be wrong),
> the function can behave in a manner similar to malloc(0) - it can
> either do no allocation and return a null pointer (in which case the
> whole thing is like free(ptr)), or it could allocate a zero-size
> object and return a unique pointer. (Or it could try to do such an
> allocation, and fail, possibly affecting errno.) It is this aspect
> that is, as far as I can tell, implementation dependent and
> non-portable.
If realloc(ptr, 0) returns a null pointer, then its behavior is subtly
different from that of free(), which doesn't return a value. That's a
minor quibble.
The standard doesn't say that any of the memory allocation functions set
errno, so any of them could set it to any non-zero value regardless of
whether they succeed or fail.
Under C89/C90 rules, realloc(ptr, 0) definitely frees the object pointed
to by ptr (assuming it had been allocated properly). The standard
doesn't clearly say what realloc() returns in that case. Common sense
suggests that it behaves like malloc(0), so it returns either a null
pointer or a unique pointer (and the choice is implementation-defined,
so it must be documented). The caller can easily tell whether it
returned a null pointer or not, and in either case it can safely pass
the result to free().
ptr1 = malloc(42);
ptr2 = realloc(ptr1, 0);
// At this point, we know that the 42-byte object has been freed
free(ptr2); // this is safe and avoids any memory leak
In C99 and later, the description of realloc() doesn't specifically
address the case of size==0. But since it says that it deallocates
the old object and allocates a new object, that's covered by the
description in the parent section, which also applies to malloc
and friends. (C89/C90 says realloc changes the size of the object,
which is IMHO rather sloppy wording.) Again, the caller can tell
whether realloc(ptr, 0) returned a null pointer or not, and can
safely pass it to free() either way.
C17 adds this (which I missed before):
If size is zero and memory for the new object is not allocated, it
is implementation-defined whether the old object is deallocated.
Presumably for an implementation where malloc(0) returns a null pointer,
this would not apply. But for an implementation where malloc(0) returns
a unique pointer (like malloc(1) except that dereferencing it has
undefined behavior), that allocation might fail.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-12 05:46 -0700 |
| Message-ID | <86a5zd2rpx.fsf@linuxsc.com> |
| In reply to | #169846 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Under C89/C90 rules, realloc(ptr, 0) definitely frees the object
> pointed to by ptr (assuming it had been allocated properly). The
> standard doesn't clearly say what realloc() returns in that case.
The C90 standard does say what realloc() returns in that case (of
course whether it says so clearly is a subjective question). The
return value is dictated by the two penultimate sentences in the
general description at the beginning of section 7.10.3, "Memory
management functions":
[...] If the space cannot be allocated, a null pointer is
returned. If the size of the space requested is zero, the
behavior is implementation-defined; the value returned shall
be either a null pointer or a unique pointer. [...]
That description is consistent with the 'Returns' portion of
section 7.10.3.4 "The realloc function", which says:
The realloc function returns either a null pointer or a
pointer to the possibly moved allocated space.
> Common sense suggests that it behaves like malloc(0), so it
> returns either a null pointer or a unique pointer (and the choice
> is implementation-defined, so it must be documented).
I don't think any common sense is needed. There is nothing in the
description under 7.10.3.4 that contradicts the general description
given in 7.10.3, so that specification must be followed.
Incidentally, note that it is always possible for realloc(ptr,0) to
return a non-null value (when ptr is non-null), because if nothing
else the original value of ptr could be returned, to be the 'unique
pointer'. The same is true for any other call to realloc() when
the requested size is less than or equal to the current size.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-06 12:34 +0000 |
| Message-ID | <u0me93$n86$2@reader2.panix.com> |
| In reply to | #169845 |
In article <u0kt7r$24ku$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 05/04/2023 20:55, Dan Cross wrote: >> In article <u0k3au$3uelq$1@dont-email.me>, >> David Brown <david.brown@hesbynett.no> wrote: >>> On 05/04/2023 15:29, Dan Cross wrote: >>>> In article <874jpv84uv.fsf@bsb.me.uk>, >>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >>> >>>>> I got the impression they knew that. However, in C89, realloc(ptr, 0) >>>>> must behave like free(ptr). That changed, I think, in C99 with the >>>>> removal of that guarantee. There is some evidence that they are little >>>>> confused about that guarantee having been lost, thought of course it is >>>>> still permitted. >>>> >>>> Indeed, you are correct. From C89, 7.10.3.3: "if *size* is zero >>>> and *ptr* is not a null pointer, the object it points to is >>>> freed." >>> >>> I don't have a C89 reference handy, but I don't think realloc(ptr, 0) >>> has ever been required to behave like free(ptr). That is one of the >>> allowed behaviours, but it is not the only one. In particular, even if >>> it first acts like free(ptr), it can then allocate a zero-size buffer >>> afterwards. Thus it may not be behaving like free(ptr) alone - it can >>> do more. And if you don't take that into account, your code will leak >>> memory. >> >> What I quoted above is the actual text from C89. To repeat: >> >> "If *size* is zero and *ptr* is not a null pointer, >> the object it points to is freed." >> >> (C89, sec 7.10.3.3.) > >I am not disagreeing with that. My point is what happens /after/ the >pointer ptr is freed. As far as I can tell (and I could be wrong), the >function can behave in a manner similar to malloc(0) - it can either do >no allocation and return a null pointer (in which case the whole thing >is like free(ptr)), or it could allocate a zero-size object and return a >unique pointer. (Or it could try to do such an allocation, and fail, >possibly affecting errno.) It is this aspect that is, as far as I can >tell, implementation dependent and non-portable. Ah, I see what you mean; the issue is with the composition of functionality, not a quibble about whether the original pointer is freed. I believe you are correct, and I believe the diversity of implementation opinions (and assumptions in real-world code based on those opinions) is what caused the commitee to make this change. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | John Forkosh <forkosh@panix.com> |
|---|---|
| Date | 2023-04-06 05:42 +0000 |
| Message-ID | <u0lm3j$8iu$1@reader2.panix.com> |
| In reply to | #169831 |
David Brown <david.brown@hesbynett.no> wrote:
> Dan Cross wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>>> I got the impression they knew that. However, in C89,
>>> realloc(ptr, 0) must behave like free(ptr).
>>> That changed, I think, in C99 with the removal of that
>>> guarantee. There is some evidence that they are little
>>> confused about that guarantee having been lost, thought
>>> of course it is still permitted.
>>
>> Indeed, you are correct. From C89, 7.10.3.3:
>> "if *size* is zero and *ptr* is not a null pointer,
>> the object it points to is freed."
>
> I don't have a C89 reference handy, but I don't think
> realloc(ptr, 0) has ever been required to behave like
> free(ptr). That is one of the allowed behaviours, but
> it is not the only one. In particular, even if it
> first acts like free(ptr), it can then allocate a
> zero-size buffer afterwards. Thus it may not be behaving
> like free(ptr) alone - it can do more. And if you don't
> take that into account, your code will leak memory.
So why all the fuss? If that's an issue for anyone,
they can just write the simplest glue function imaginable,
e.g.,
void *realloc0 ( void *ptr, size_t size ) {
void *reptr = NULL;
if ( size < 1 ) {
if ( ptr != NULL ) free(ptr); }
else reptr = realloc(ptr,size);
return ( reptr ); }
--
John Forkosh ( mailto: j@f.com where j=john and f=forkosh )
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-04-07 12:16 +0200 |
| Message-ID | <u0oqii$pg6c$1@dont-email.me> |
| In reply to | #169850 |
On 06/04/2023 07:42, John Forkosh wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> Dan Cross wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>>>> I got the impression they knew that. However, in C89,
>>>> realloc(ptr, 0) must behave like free(ptr).
>>>> That changed, I think, in C99 with the removal of that
>>>> guarantee. There is some evidence that they are little
>>>> confused about that guarantee having been lost, thought
>>>> of course it is still permitted.
>>>
>>> Indeed, you are correct. From C89, 7.10.3.3:
>>> "if *size* is zero and *ptr* is not a null pointer,
>>> the object it points to is freed."
>>
>> I don't have a C89 reference handy, but I don't think
>> realloc(ptr, 0) has ever been required to behave like
>> free(ptr). That is one of the allowed behaviours, but
>> it is not the only one. In particular, even if it
>> first acts like free(ptr), it can then allocate a
>> zero-size buffer afterwards. Thus it may not be behaving
>> like free(ptr) alone - it can do more. And if you don't
>> take that into account, your code will leak memory.
>
> So why all the fuss? If that's an issue for anyone,
> they can just write the simplest glue function imaginable,
> e.g.,
> void *realloc0 ( void *ptr, size_t size ) {
> void *reptr = NULL;
> if ( size < 1 ) {
> if ( ptr != NULL ) free(ptr); }
> else reptr = realloc(ptr,size);
> return ( reptr ); }
>
Well, yes, that would seem the sensible solution. If you want code to
be reasonably portable, you have to avoid implementation-dependent
behaviour like this, especially when implementations vary so widely in
their details and we are talking about easily detectable corner cases.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-04-07 11:38 +0000 |
| Message-ID | <20230407042121.909@kylheku.com> |
| In reply to | #169850 |
On 2023-04-06, John Forkosh <forkosh@panix.com> wrote:
> void *realloc0 ( void *ptr, size_t size ) {
> void *reptr = NULL;
> if ( size < 1 ) {
That's a silly way to spell size == 0, when size is an
unsigned type, which size_t is required to be.
The special case we want to handle is when size is zero, so
test for that, rather that by an indirect inequality that
mentions a different, irrelevant value.
> if ( ptr != NULL ) free(ptr); }
This check is pointless; free is required to work on null pointers.
> else reptr = realloc(ptr,size);
> return ( reptr ); }
Consider:
return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
which avoids multiple returns, variable assignment, and
verbiage.
--
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-04-09 07:23 -0700 |
| Message-ID | <86r0st3zj0.fsf@linuxsc.com> |
| In reply to | #169859 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
[miscellaneous suggestions taken out]
> On 2023-04-06, John Forkosh <forkosh@panix.com> wrote:
>
>> void *realloc0 ( void *ptr, size_t size ) {
>> void *reptr = NULL;
>> if ( size < 1 ) {
>> if ( ptr != NULL ) free(ptr); }
>> else reptr = realloc(ptr,size);
>> return ( reptr ); }
>
> Consider:
>
> return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>
> which avoids multiple returns, variable assignment, and
> verbiage.
I agree with the general tone of this suggestion. Unfortunately
however the particular code suggested might not compile (because
the macro NULL might be #define'd to be 0, which can result in an
error). Writing the function this way:
void *
realloc0( void *p, size_t size ){
return size == 0 ? free( p ), p = 0 : realloc( p, size );
}
is an easy way to avoid that implementation dependency.
(Some people may prefer writing 'p = NULL' after the call to
free(); my preference in this case is to write 'p = 0', as
shown. But that question is orthogonal to the main point about
avoiding the potential compilation error.)
[toc] | [prev] | [next] | [standalone]
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-09 17:04 +0200 |
| Message-ID | <u0uk66$1or41$1@dont-email.me> |
| In reply to | #169882 |
Tim Rentsch ha scritto:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
> [miscellaneous suggestions taken out]
>
>> On 2023-04-06, John Forkosh <forkosh@panix.com> wrote:
>>
>>> void *realloc0 ( void *ptr, size_t size ) {
>>> void *reptr = NULL;
>>> if ( size < 1 ) {
>>> if ( ptr != NULL ) free(ptr); }
>>> else reptr = realloc(ptr,size);
>>> return ( reptr ); }
>>
>> Consider:
>>
>> return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>>
>> which avoids multiple returns, variable assignment, and
>> verbiage.
>
> I agree with the general tone of this suggestion. Unfortunately
> however the particular code suggested might not compile (because
> the macro NULL might be #define'd to be 0, which can result in an
> error). Writing the function this way:
>
> void *
> realloc0( void *p, size_t size ){
> return size == 0 ? free( p ), p = 0 : realloc( p, size );
> }
>
> is an easy way to avoid that implementation dependency.
>
If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
on autocast and use an explicit one instead.
>
> (Some people may prefer writing 'p = NULL' after the call to
> free(); my preference in this case is to write 'p = 0', as
> shown. But that question is orthogonal to the main point about
> avoiding the potential compilation error.)
>
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-09 19:34 +0000 |
| Message-ID | <u0v3vh$df3$1@reader2.panix.com> |
| In reply to | #169883 |
In article <u0uk66$1or41$1@dont-email.me>, jak <nospam@please.ty> wrote:
>Tim Rentsch ha scritto:
>>[snip]
>> I agree with the general tone of this suggestion. Unfortunately
>> however the particular code suggested might not compile (because
>> the macro NULL might be #define'd to be 0, which can result in an
>> error). Writing the function this way:
>>
>> void *
>> realloc0( void *p, size_t size ){
>> return size == 0 ? free( p ), p = 0 : realloc( p, size );
>> }
>>
>> is an easy way to avoid that implementation dependency.
>
>If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
>on autocast and use an explicit one instead.
What "dependency" would that avoid, other than a dependency on
the C standard?
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 09:45 +0200 |
| Message-ID | <u10erc$23rhg$1@dont-email.me> |
| In reply to | #169885 |
Dan Cross ha scritto:
> In article <u0uk66$1or41$1@dont-email.me>, jak <nospam@please.ty> wrote:
>> Tim Rentsch ha scritto:
>>> [snip]
>>> I agree with the general tone of this suggestion. Unfortunately
>>> however the particular code suggested might not compile (because
>>> the macro NULL might be #define'd to be 0, which can result in an
>>> error). Writing the function this way:
>>>
>>> void *
>>> realloc0( void *p, size_t size ){
>>> return size == 0 ? free( p ), p = 0 : realloc( p, size );
>>> }
>>>
>>> is an easy way to avoid that implementation dependency.
>>
>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
>> on autocast and use an explicit one instead.
>
> What "dependency" would that avoid, other than a dependency on
> the C standard?
>
> - Dan C.
>
Why are you asking me this? Perhaps you consider being portability if
you move the source code to another machine with the same operating
system, same compiler, same compiler version.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-10 14:52 +0000 |
| Message-ID | <u117rb$9r2$2@reader2.panix.com> |
| In reply to | #169894 |
In article <u10erc$23rhg$1@dont-email.me>, jak <nospam@please.ty> wrote:
>Dan Cross ha scritto:
>> In article <u0uk66$1or41$1@dont-email.me>, jak <nospam@please.ty> wrote:
>>> Tim Rentsch ha scritto:
>>>> [snip]
>>>> I agree with the general tone of this suggestion. Unfortunately
>>>> however the particular code suggested might not compile (because
>>>> the macro NULL might be #define'd to be 0, which can result in an
>>>> error). Writing the function this way:
>>>>
>>>> void *
>>>> realloc0( void *p, size_t size ){
>>>> return size == 0 ? free( p ), p = 0 : realloc( p, size );
>>>> }
>>>>
>>>> is an easy way to avoid that implementation dependency.
>>>
>>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
>>> on autocast and use an explicit one instead.
>>
>> What "dependency" would that avoid, other than a dependency on
>> the C standard?
>
>Why are you asking me this?
Because you are the one who suggested there is some kind of
"dependency" in Tim's code?
>Perhaps you consider being portability if
>you move the source code to another machine with the same operating
>system, same compiler, same compiler version.
This has nothing to do with that. Tim's code was correct and
portable.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 17:29 +0200 |
| Message-ID | <u11a0u$27j9d$1@dont-email.me> |
| In reply to | #169900 |
Dan Cross ha scritto:
> In article <u10erc$23rhg$1@dont-email.me>, jak <nospam@please.ty> wrote:
>> Dan Cross ha scritto:
>>> In article <u0uk66$1or41$1@dont-email.me>, jak <nospam@please.ty> wrote:
>>>> Tim Rentsch ha scritto:
>>>>> [snip]
>>>>> I agree with the general tone of this suggestion. Unfortunately
>>>>> however the particular code suggested might not compile (because
>>>>> the macro NULL might be #define'd to be 0, which can result in an
>>>>> error). Writing the function this way:
>>>>>
>>>>> void *
>>>>> realloc0( void *p, size_t size ){
>>>>> return size == 0 ? free( p ), p = 0 : realloc( p, size );
>>>>> }
>>>>>
>>>>> is an easy way to avoid that implementation dependency.
>>>>
>>>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
>>>> on autocast and use an explicit one instead.
>>>
>>> What "dependency" would that avoid, other than a dependency on
>>> the C standard?
>>
>> Why are you asking me this?
>
> Because you are the one who suggested there is some kind of
> "dependency" in Tim's code?
>
>> Perhaps you consider being portability if
>> you move the source code to another machine with the same operating
>> system, same compiler, same compiler version.
>
> This has nothing to do with that. Tim's code was correct and
> portable.
>
> - Dan C.
>
Correct for sure but you and I don't have the same concept of portable.
There are compilers that don't accept things like this:
char val;
int *pi;
pi = (int *)&val;
because if you assigned a value to *pi you would be using unallocated
memory and if you really want to do that you need a left cast:
((char *)pi) = &val;
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 11:48 -0400 |
| Message-ID | <u11b4s$27go8$2@dont-email.me> |
| In reply to | #169904 |
On 4/10/23 11:29, jak wrote: ... > char val; > int *pi; > > pi = (int *)&val; > > because if you assigned a value to *pi you would be using unallocated > memory The problem with that code has nothing to do with the problem Tim was talking about, nor does it have anything to do with unallocated memory. It has undefined behavior if &val points to a memory location that is not correctly aligned to hold an 'int' (6.3.2.3p7). More importantly, even if it is correctly aligned, the value stored in pi cannot be used to access an 'int', because it doesn't point at an int object. > ... and if you really want to do that you need a left cast: > > ((char *)pi) = &val; The left hand side of an assignment is required to be a modifiable lvalue (6.5.16p2). The result of a pointer conversion is not an lvalue.
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web