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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-11 12:50 -0700 |
| Message-ID | <874jpmfbbe.fsf@nosuchdomain.example.com> |
| In reply to | #169961 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> The only real use I have seen for non-prototype function declarations
> is a "general" function pointer in arrays containing mixed function
> pointer types. Such use is no longer allowed in C23. Is that what
> you are concerned about? Normally a better choice of general function
> pointer is "void foo(void)", rather than "int foo()". (In C23, the
> later would now mean "int foo(void)".)
I haven't often had a need for a generic function pointer type (as void*
is a generic object pointer type), but I suggest that using a return
type that's not used elsewhere might be safer. If you use `void(void)`
as a generic function type, there's a risk that a call without a cast
will quietly compile.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-04-12 09:51 +0200 |
| Message-ID | <u15nuh$2uuci$2@dont-email.me> |
| In reply to | #169984 |
On 11/04/2023 21:50, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> The only real use I have seen for non-prototype function declarations >> is a "general" function pointer in arrays containing mixed function >> pointer types. Such use is no longer allowed in C23. Is that what >> you are concerned about? Normally a better choice of general function >> pointer is "void foo(void)", rather than "int foo()". (In C23, the >> later would now mean "int foo(void)".) > > I haven't often had a need for a generic function pointer type (as void* > is a generic object pointer type), but I suggest that using a return > type that's not used elsewhere might be safer. If you use `void(void)` > as a generic function type, there's a risk that a call without a cast > will quietly compile. > That would be even better, yes. But would you not want the non-existent type to be used for a parameter, rather than the return type? (You could use it for both.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-12 09:12 -0700 |
| Message-ID | <87zg7ddqq0.fsf@nosuchdomain.example.com> |
| In reply to | #169994 |
David Brown <david.brown@hesbynett.no> writes:
> On 11/04/2023 21:50, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> The only real use I have seen for non-prototype function declarations
>>> is a "general" function pointer in arrays containing mixed function
>>> pointer types. Such use is no longer allowed in C23. Is that what
>>> you are concerned about? Normally a better choice of general function
>>> pointer is "void foo(void)", rather than "int foo()". (In C23, the
>>> later would now mean "int foo(void)".)
>> I haven't often had a need for a generic function pointer type (as
>> void*
>> is a generic object pointer type), but I suggest that using a return
>> type that's not used elsewhere might be safer. If you use `void(void)`
>> as a generic function type, there's a risk that a call without a cast
>> will quietly compile.
>
> That would be even better, yes. But would you not want the
> non-existent type to be used for a parameter, rather than the return
> type? (You could use it for both.)
You're right, using the nonexistent type for a parameter would catch
more errors; I didn't think about calls in void context.
For example:
struct DO_NOT_USE { int n; };
typedef void func(struct DO_NOT_USE);
You could use it for the return type too, but I don't think that adds
anything.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-10 09:58 -0700 |
| Message-ID | <87leizhdy6.fsf@nosuchdomain.example.com> |
| In reply to | #169908 |
jak <nospam@please.ty> writes:
> James Kuyper ha scritto:
>> On 4/10/23 10:37, jak wrote:
>> ...
>>>> Instead, explain to me why, after all the improvements introduced by the
>>> standards, it is no longer possible to declare a specialized function
>>> pointer array without first declaring the typedef that defines the
>>> function pointer and why.
>> "specialized function pointer array"? Are you posting that to the
>> correct newsgroup?
>> Even if this were comp.lang.c++, you've just swerved off into an
>> entirely different conversational direction - I would recommend starting
>> a new thread to discuss that issue.
>
> Please tell me you're joking...
James and I do not speak for each other, but I see no reason to think he
was joking, and I agree with what he wrote. I'm not assuming that you
were making a point about C++, but the word "specialized" does suggest
that it's likely; if so, I suggest posting in comp.lang.c++.
If you perceive a joke, perhaps you can explain it to us.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-10 09:54 -0700 |
| Message-ID | <87pm8bhe3h.fsf@nosuchdomain.example.com> |
| In reply to | #169898 |
jak <nospam@please.ty> writes:
>> Are you K.T's knight perhaps? Please stop quoting bits of manuals that
>> everyone has read hundreds of times, be less obtuse and learn to read
>> what is not written. Some field work wouldn't hurt. Do not hoe but claim
>> to design hoes.
>> Instead, explain to me why, after all the improvements introduced by the
> standards, it is no longer possible to declare a specialized function
> pointer array without first declaring the typedef that defines the
> function pointer and why.
I'm not aware that that's true. If it is, I invite you to start a new
thread to discuss it. I don't know what you mean by "specialized" in
this context, and I'm not aware of any case where declaring an array of
function pointers requires a typedef.
This thread has already drifted, as many threads do, so it might not
matter a great deal whether you start a new thread or not, but it is a
substantial change of topic.
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 11:21 -0400 |
| Message-ID | <u119hk$27go7$2@dont-email.me> |
| In reply to | #169897 |
On 4/10/23 10:29, jak wrote: > James Kuyper ha scritto: >> On 4/10/23 03:31, jak wrote: >>> Keith Thompson ha scritto: >>>> jak <nospam@please.ty> writes: >>>> [...] >>>>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely >>>>> on autocast and use an explicit one instead. >>>> >>>> I've never seen the term "autocast" before. >>>> >>>> A cast is an explicit conversion. A conversion done without a cast is >>>> an implicit conversion. "Autocast" would be a contradiction. >>>> >>> >>> Maybe this is because we don't come from the same county and therefore, >>> probably, haven't read the same books? I don't formalize myself nor am I >>> shocked when I read 'implicit conversion' despite the cast it should be >>> considered a stretch and not a conversion. Perhaps you too should have a >>> more open mind. ... >> The word "stretch" appears nowhere in the C standard. As a very >> well-read native speaker of English with a very good understanding of C, >> and a fairly good understanding of most programming jargon, I'm not sure >> what you mean by "stretch". None of the 10 meanings listed at >> wiktionary.org for "stretch" seems applicable. >> Would you care to describe what you mean by that term, and how it >> differs from a conversion? I haven't a clue. ... > Are you K.T's knight perhaps? Please stop quoting bits of manuals that > everyone has read hundreds of times, be less obtuse and learn to read > what is not written. Some field work wouldn't hurt. Do not hoe but claim > to design hoes. Are you referring to Keith Thompson? I am not his knight, whatever you might mean by that; we're just two people with similar attitudes about formal rigor, and as a result are often (but not always) in agreement about what the standard means. The standard is not a manual. I seriously doubt that you have read it hundreds of times. I remain unenlightened as to what "stretch" might mean in this context. I can't even imagine where I might look for a definition.
[toc] | [prev] | [next] | [standalone]
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 17:58 +0200 |
| Message-ID | <u11bmg$27rcs$1@dont-email.me> |
| In reply to | #169902 |
James Kuyper ha scritto: > On 4/10/23 10:29, jak wrote: >> James Kuyper ha scritto: >>> On 4/10/23 03:31, jak wrote: >>>> Keith Thompson ha scritto: >>>>> jak <nospam@please.ty> writes: >>>>> [...] >>>>>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely >>>>>> on autocast and use an explicit one instead. >>>>> >>>>> I've never seen the term "autocast" before. >>>>> >>>>> A cast is an explicit conversion. A conversion done without a cast is >>>>> an implicit conversion. "Autocast" would be a contradiction. >>>>> >>>> >>>> Maybe this is because we don't come from the same county and therefore, >>>> probably, haven't read the same books? I don't formalize myself nor am I >>>> shocked when I read 'implicit conversion' despite the cast it should be >>>> considered a stretch and not a conversion. Perhaps you too should have a >>>> more open mind. > ... >>> The word "stretch" appears nowhere in the C standard. As a very >>> well-read native speaker of English with a very good understanding of C, >>> and a fairly good understanding of most programming jargon, I'm not sure >>> what you mean by "stretch". None of the 10 meanings listed at >>> wiktionary.org for "stretch" seems applicable. >>> Would you care to describe what you mean by that term, and how it >>> differs from a conversion? I haven't a clue. > ... >> Are you K.T's knight perhaps? Please stop quoting bits of manuals that >> everyone has read hundreds of times, be less obtuse and learn to read >> what is not written. Some field work wouldn't hurt. Do not hoe but claim >> to design hoes. > > Are you referring to Keith Thompson? I am not his knight, whatever you > might mean by that; we're just two people with similar attitudes about > formal rigor, and as a result are often (but not always) in agreement > about what the standard means. > The standard is not a manual. I seriously doubt that you have read it > hundreds of times. > I remain unenlightened as to what "stretch" might mean in this context. > I can't even imagine where I might look for a definition. > > Keep your doubts close to you as well. I'm still ahead of you because I know that I don't know.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-11 05:31 -0700 |
| Message-ID | <86pm8a38jb.fsf@linuxsc.com> |
| In reply to | #169895 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > "Several operators convert operand values from one type to another > automatically. This subclause specifies the result required from > such an implicit conversion, as well as those that result from a > cast operation (an explicit conversion)." (6.3p1) > > The terms "implicit conversion" and "explicit conversion" are both > italicized in the actual standard, which is an ISO convention > indicating that the sentence in which they occur is the official > definition of what those terms mean. > > Implicit conversions occur in the following contexts: > > The integer promotions (6.3.1.1p2). > The usual arithmetic conversions (6.3.1.8p1). > > An lvalue of array type is implicitly converted into a pointer to > the first element of that array in many contexts (6.3.2p3). This is > done as a convenience, but has led many people to confuse arrays > with pointers. > > A function designator is implicitly converted into a pointer to the > designated function in many contexts (6.3.2p4). > > The default argument promotions (6.5.2.2p6). > > Simple assignment (6.5.16.1p2). > > As-if by assignment: > Arguments of function declared with a prototype. (6.5.2.2p7, 6.9.1p10) > Return expression. (6.8.6.4p3) Good list. There is one other case of same rule as assignment, which is scalar initializer values, either in declarations or in compound literals.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-10 09:50 -0700 |
| Message-ID | <87ttxnheb6.fsf@nosuchdomain.example.com> |
| In reply to | #169892 |
jak <nospam@please.ty> writes:
> Keith Thompson ha scritto:
>> jak <nospam@please.ty> writes:
>> [...]
>>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
>>> on autocast and use an explicit one instead.
>> I've never seen the term "autocast" before.
>> A cast is an explicit conversion. A conversion done without a cast
>> is
>> an implicit conversion. "Autocast" would be a contradiction.
>
> Maybe this is because we don't come from the same county and therefore,
> probably, haven't read the same books? I don't formalize myself nor am I
> shocked when I read 'implicit conversion' despite the cast it should be
> considered a stretch and not a conversion. Perhaps you too should have a
> more open mind.
I don't know what you mean by "stretch". Can you explain?
Perhaps it has some technical meaning in books you've read, but I
haven't encountered it.
Having a "more open mind" doesn't help me to understand unfamiliar
terms that haven't been defined. "autocast", unlike "stretch",
is obvious enough in context, but in my opinion it's unnecessarily
obscure. When discussing C, I strongly prefer to use terms defined
by the C standard, with the meanings assigned by that standard.
I think that's the best way to establish a common vocabulary and
promote effective communication. I don't see that "autocast"
expresses anything that isn't more effectively expressed by
"implicit conversion".
As for the technical issue, I've found that implicit conversions are
often better (less error-prone, leading to more easily maintainable
code) than explicit casts. C probably has more implicit conversions
than I'm entirely comfortable with, but most of them do the right
thing most of the time. If you use a cast, you have the additional
burden of specifying the correct type, and keeping it correct as
the code is maintained.
--
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-09 12:44 -0700 |
| Message-ID | <86mt3g4z8s.fsf@linuxsc.com> |
| In reply to | #169883 |
jak <nospam@please.ty> writes:
> 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.
The re-written code doesn't have any implementation dependency:
it is guaranteed to work in all versions of C back to ANSI C and
even K&R C (except of course K&R C doesn't have void or void *,
(or size_t?) but the conversion of 0 to any pointer type will
work even back in K&R C).
Furthermore writing an explicit cast is almost always a bad idea,
especially in open code. Writing the expression without a cast
gives the compiler a chance to say that the code is wrong, if
indeed wrong it is. No diagnostics plus no use of any symbols
such as NULL that are implementation-defined means the code will
compile successfully everywhere.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-04-09 20:19 +0100 |
| Message-ID | <877cuk3luf.fsf@bsb.me.uk> |
| In reply to | #169882 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> 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).
I'm not sure what you mean. "Can result in an error" sounds a bit
vague. I know from
> ... the main point about
> avoiding the potential compilation error ...
that you mean a compilation error, but that's not a standard term.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-09 12:55 -0700 |
| Message-ID | <86ile44yqb.fsf@linuxsc.com> |
| In reply to | #169884 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> 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).
>
> I'm not sure what you mean. "Can result in an error" sounds a bit
> vague. I know from
>
>> ... the main point about
>> avoiding the potential compilation error ...
>
> that you mean a compilation error, but that's not a standard term.
If NULL is #define'd to be 0, then a diagnostic is required. The
problem can be seen by attempting to compile this version:
void *
realloc0( void *p, size_t size ){
return size == 0 ? free( p ), 0 : realloc( p, size );
}
The presence of a required diagnostic means the compilation can
fail, without needing any other cause. Of course that doesn't
mean a compilation must fail, but it can fail, and will fail
if for example -Werror was used. Does that clarify what I was
trying to get at?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-04-09 21:44 +0100 |
| Message-ID | <87sfd823c1.fsf@bsb.me.uk> |
| In reply to | #169889 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> 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).
>>
>> I'm not sure what you mean. "Can result in an error" sounds a bit
>> vague. I know from
>>
>>> ... the main point about
>>> avoiding the potential compilation error ...
>>
>> that you mean a compilation error, but that's not a standard term.
>
> If NULL is #define'd to be 0, then a diagnostic is required. The
> problem can be seen by attempting to compile this version:
>
> void *
> realloc0( void *p, size_t size ){
> return size == 0 ? free( p ), 0 : realloc( p, size );
> }
>
> The presence of a required diagnostic means the compilation can
> fail, without needing any other cause. Of course that doesn't
> mean a compilation must fail, but it can fail, and will fail
> if for example -Werror was used. Does that clarify what I was
> trying to get at?
Yes, thanks. I thought you mean that, but I was not sure. I prefer to
be more explicit and say that such and such violates a constraint, but I
can see some advantage in using more colloquial terms.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-09 19:53 -0700 |
| Message-ID | <86edos4fdk.fsf@linuxsc.com> |
| In reply to | #169890 |
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:
>>>
>>>> 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).
>>>
>>> I'm not sure what you mean. "Can result in an error" sounds a bit
>>> vague. I know from
>>>
>>>> ... the main point about
>>>> avoiding the potential compilation error ...
>>>
>>> that you mean a compilation error, but that's not a standard term.
>>
>> If NULL is #define'd to be 0, then a diagnostic is required. The
>> problem can be seen by attempting to compile this version:
>>
>> void *
>> realloc0( void *p, size_t size ){
>> return size == 0 ? free( p ), 0 : realloc( p, size );
>> }
>>
>> The presence of a required diagnostic means the compilation can
>> fail, without needing any other cause. Of course that doesn't
>> mean a compilation must fail, but it can fail, and will fail
>> if for example -Werror was used. Does that clarify what I was
>> trying to get at?
>
> Yes, thanks. I thought you mean that, but I was not sure. I
> prefer to be more explicit and say that such and such violates a
> constraint, but I can see some advantage in using more colloquial
> terms.
It is often the case that I feel a tension between using formal
phrasing as it is used in the C standard, and informal phrasing
more like common English usage. Personally I think either can be
appropriate, depending on the particular issue being discussed and
on the expected audience. I must admit, however, that frequently
I get push back from one side or the other, carrying at least an
implicit suggestion that I made a bad choice. For the most part I
simply accept these comments as part of the price for trying to
make a reasonable decision in the face of incomplete information
(while still allowing for the possibility that my decisions in the
future may be altered). When reading comments made by other
people, I always try to understand what perspective they are
taking, and adjust my verbal processing accordingly; it is only
when I can't find a way of understanding their comments that I
want to bring it up. What is that aphorism? "Assume that what
they are saying makes sense, and try to find a way of looking at
it so that it's sensible, to understand what they meant." Or
something like that.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-04-05 20:33 +0100 |
| Message-ID | <87zg7m5djw.fsf@bsb.me.uk> |
| In reply to | #169827 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > 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. >> in C89, realloc(ptr, 0) must behave like free(ptr) > 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." Sorry, I must be reading the thread in the wrong order as I replied to something less before seeing this. This thread has become very noisy and really did not need my repeating information! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-16 07:18 -0700 |
| Message-ID | <86zg7729mn.fsf@linuxsc.com> |
| In reply to | #169818 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > cross@spitfire.i.gajendra.net (Dan Cross) writes: [context: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly https://queue.acm.org/detail.cfm?id=3588242 ] >> 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. [...] >> 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. The point of the code is to illustrate a pattern. There are obvious ways to improve the code for serious development, but those changes would complicate the presentation without offering any help to illustrating the pattern. > It can leak memory (in two different ways) but it does not have > formally undefined behaviour. Isn't it the case that whether there are memory leaks depends on what one takes the interface specification to be? In C90, for example, doesn't the rule about always free()ing eliminate the possibility of memory leaks? Is there something I've missed here? (Note that I am assuming the 'sizeof (int) == 1' problem is not a factor for this question.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-05 12:53 -0700 |
| Message-ID | <86cz4i5cn1.fsf@linuxsc.com> |
| 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: [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. [...] > 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. As noted downthread, that statement isn't right in the particular case of C89/C90. > [...] The authors tried to make it out like their code was > portable and well-defined. [...] I have to disagree here. The example code is discussed under the aegis of what the authors term a "zero-null" allocator implementation, where (among other things) 'realloc(p,0)' always does a 'free(p)', and will always return NULL. They aren't making any claims for any other implementations.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-06 12:30 +0000 |
| Message-ID | <u0me21$n86$1@reader2.panix.com> |
| In reply to | #169843 |
In article <86cz4i5cn1.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>
>> In article <87zg7n89zw.fsf@bsb.me.uk>,
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>[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. [...]
>
>> 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.
>
>As noted downthread, that statement isn't right in the particular
>case of C89/C90.
Yes, and this is the third time I'm acknowledging that I was
mistaken about that. :-)
>> [...] The authors tried to make it out like their code was
>> portable and well-defined. [...]
>
>I have to disagree here. The example code is discussed under
>the aegis of what the authors term a "zero-null" allocator
>implementation, where (among other things) 'realloc(p,0)' always
>does a 'free(p)', and will always return NULL. They aren't
>making any claims for any other implementations.
Rereading I can see how you might take it that way, but this is
slicing the thinnest of hairs.
Consider this sentence:
"Imagine, then, my dismay when I learned that C23
declares realloc(ptr,0) to be undefined behavior,
thereby pulling the rug out from under a widespread
and exemplary pattern deliberately condoned by C89
through C11."
Well, no, not exactly. C89 through C11 said that the example
program _may_ work or _may not_, depending on the
implementation, but a perfectly reasonable reader could take the
above statement to mean that it just would.
It goes on:
"So much for stare decisis. Compile idiomatic realloc
code as C23 and the compiler might maul the source
in most astonishing ways and your machine could
ignite at runtime."
Hmm. Idiomatic in whose eyes? Suggesting that the example code
is "idiomatic" further suggests that it is not merely
implementation-dependent, but well-formed in all cases.
Consider the reader here: practitioners. This article is not
the standard, where every word counts.
It is precisely this sort of ambiguity that the committee was
addressing. JeanHyde wrote about this on Twitter:
https://twitter.com/__phantomderp/status/1643698363114610698
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-08 18:46 -0700 |
| Message-ID | <86v8i54yk5.fsf@linuxsc.com> |
| In reply to | #169851 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86cz4i5cn1.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> cross@spitfire.i.gajendra.net (Dan Cross) writes: >> >>> In article <87zg7n89zw.fsf@bsb.me.uk>, >>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >> >> [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. [...] >>> >>> 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. >> >> As noted downthread, that statement isn't right in the particular >> case of C89/C90. > > Yes, and this is the third time I'm acknowledging that I was > mistaken about that. :-) My comment was meant to acknowledge that you had already recognized this, not to flog you for it. Sorry for the confusion. >>> [...] The authors tried to make it out like their code was >>> portable and well-defined. [...] >> >> I have to disagree here. The example code is discussed under >> the aegis of what the authors term a "zero-null" allocator >> implementation, where (among other things) 'realloc(p,0)' always >> does a 'free(p)', and will always return NULL. They aren't >> making any claims for any other implementations. > > Rereading I can see how you might take it that way, but this is > slicing the thinnest of hairs. > > Consider this sentence: > > "Imagine, then, my dismay when I learned that C23 > declares realloc(ptr,0) to be undefined behavior, > thereby pulling the rug out from under a widespread > and exemplary pattern deliberately condoned by C89 > through C11." > > Well, no, not exactly. [...] I think you misunderstood my comment. I didn't mean to say anything about what the authors say about the evolution of realloc(). I meant only that the code they gave works just fine (not counting the problem when 'sizeof (int) == 1' that Ben B pointed out) -- importantly, under the assumptions that the authors explicitly stated -- and that they didn't say anything about whether the code is portable or well-defined if considered outside of those assumptions. The authors may have some opinions about whether the code /should/ work in general, but they don't make any claims about whether it /does/ work in general, and that point is the only one I mean to address.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-09 19:35 +0000 |
| Message-ID | <u0v426$df3$2@reader2.panix.com> |
| In reply to | #169865 |
In article <86v8i54yk5.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >I think you misunderstood my comment. I didn't mean to say >anything about what the authors say about the evolution of >realloc(). I meant only that the code they gave works just fine >(not counting the problem when 'sizeof (int) == 1' that Ben B >pointed out) -- importantly, under the assumptions that the >authors explicitly stated -- and that they didn't say anything >about whether the code is portable or well-defined if considered >outside of those assumptions. The authors may have some opinions >about whether the code /should/ work in general, but they don't >make any claims about whether it /does/ work in general, and that >point is the only one I mean to address. No, I understood that, but I disagree: I believe that they were trying to make a more general statement, beyond simply the circumstances they outlined. Of course, without asking them, it's difficult to be certain. - Dan C.
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web