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 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 18:10 +0200 |
| Message-ID | <u11ccu$27v2q$1@dont-email.me> |
| In reply to | #169909 |
James Kuyper ha scritto: > 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. > hmmm... in my point of view declaring a variable corresponds to allocating memory while using malloc means allocating memory dynamically. For me it is not easy to express concepts in your language and in addition you continue to take me back on the quibbles. Maybe we can talk again when I improve my English and you're less picky.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 12:19 -0400 |
| Message-ID | <u11cvb$281i6$2@dont-email.me> |
| In reply to | #169915 |
On 4/10/23 12:10, jak wrote: > James Kuyper ha scritto: >> 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. >> > > hmmm... in my point of view declaring a variable corresponds to > allocating memory while using malloc means allocating memory > dynamically. For me it is not easy to express concepts in your language > and in addition you continue to take me back on the quibbles. Maybe we > can talk again when I improve my English and you're less picky. Declaring 'val' allocates memory to store a char. Declaring pi allocates memory to store a pointer to an int. (int*)val is an expression that could have undefined behavior, for reasons that have nothing to do with unallocated memory. If it doesn't have undefined behavior, the result of that conversion can safely be stored in the memory allocated for pi. It cannot, however, be used to access an int object, because it doesn't point at any such object.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-04-10 09:55 -0700 |
| Message-ID | <e5916e17-dbdc-4c81-a307-a16be989b3cen@googlegroups.com> |
| In reply to | #169915 |
On Monday, 10 April 2023 at 17:10:19 UTC+1, jak wrote: > James Kuyper ha scritto: > > 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. > > > hmmm... in my point of view declaring a variable corresponds to > allocating memory while using malloc means allocating memory > dynamically. For me it is not easy to express concepts in your language > and in addition you continue to take me back on the quibbles. Maybe we > can talk again when I improve my English and you're less picky. > In a sense that is right. But generally the term "allocating" isn't used for variables created on the stack, unless maybe for large arrays. The reason is that the stack works by magic. Within the confines of the C language, there is no way to express that the stack might fail, though of course it must do so eventually if allowed to get arbitrarily deep.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-10 10:41 -0700 |
| Message-ID | <87h6tnhbx7.fsf@nosuchdomain.example.com> |
| In reply to | #169922 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 10 April 2023 at 17:10:19 UTC+1, jak wrote:
>> James Kuyper ha scritto:
>> > 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.
>> >
>> hmmm... in my point of view declaring a variable corresponds to
>> allocating memory while using malloc means allocating memory
>> dynamically. For me it is not easy to express concepts in your language
>> and in addition you continue to take me back on the quibbles. Maybe we
>> can talk again when I improve my English and you're less picky.
>>
> In a sense that is right. But generally the term "allocating" isn't used for
> variables created on the stack, unless maybe for large arrays.
> The reason is that the stack works by magic. Within the confines of the
> C language, there is no way to express that the stack might fail, though
> of course it must do so eventually if allowed to get arbitrarily deep.
In fact the word "allocate" and various forms of it *are* commonly used
by the standard to refer to "variables created on the stack" (more
technically, objects with automatic storage duration).
One example (which happens to be one of the earliest references in the
text of the standard):
An *array type* describes a contiguously allocated nonempty set of
objects with a particular member object type, called the *element
type*.
This refers to array objects in general, not just heap-allocated array
objects.
The fact that one of the four storage durations is called "allocated",
while the word "allocate" is used to refer to reserving memory in other
contexts, is potentially confusing, but I haven't found it to be much of
a problem.
--
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 11:22 -0700 |
| Message-ID | <871qkrha1f.fsf@nosuchdomain.example.com> |
| In reply to | #169904 |
jak <nospam@please.ty> writes:
> 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;
Was that line of code intended to be in some hypothetical C-like
language, using a feature that you wish C provided? If that was the
point you were trying to make, it wasn't clear.
That line of code;
((char *)pi) = &val;
is not valid C. (It's also not valid C++.) When I attempt to compile
it, I get:
error: lvalue required as left operand of assignment
As for the original code:
char val;
int *pi;
pi = (int *)&val;
That doesn't violate any constraint or syntax rule, but it's likely to
have undefined behavior depending on the characteristics of the
implementation. A compiler *could* reject that code, but I'd be
surprised to see one that actually did so. A warning might be
appropriate, but most C compilers take a pointer cast as an assertion by
the programmer that "I know what I'm doing". Do you know of a compiler
that doesn't accept it?
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-04-10 21:22 +0100 |
| Message-ID | <u11r63$2a7ie$1@dont-email.me> |
| In reply to | #169938 |
On 10/04/2023 19:22, Keith Thompson wrote:
> jak <nospam@please.ty> writes:
>> 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;
>
> Was that line of code intended to be in some hypothetical C-like
> language, using a feature that you wish C provided? If that was the
> point you were trying to make, it wasn't clear.
>
> That line of code;
>
> ((char *)pi) = &val;
>
> is not valid C. (It's also not valid C++.) When I attempt to compile
> it, I get:
>
> error: lvalue required as left operand of assignment
I can't see much wrong with it. It works fine with tcc and (my) bcc
compilers. It assigns an address to pointer. The cast is needed because
otherwise there's a type mismatch (assigning char* address to a int*
pointer).
I'm surprised that gcc reports it as an error rather than a warning as
it does with nearly everything else, for example:
int *pi;
char *pc;
pi = pc;
gives a warning.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-10 14:22 -0700 |
| Message-ID | <878rezfn53.fsf@nosuchdomain.example.com> |
| In reply to | #169953 |
Bart <bc@freeuk.com> writes:
> On 10/04/2023 19:22, Keith Thompson wrote:
>> jak <nospam@please.ty> writes:
>>> 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;
>>
>> Was that line of code intended to be in some hypothetical C-like
>> language, using a feature that you wish C provided? If that was the
>> point you were trying to make, it wasn't clear.
>>
>> That line of code;
>>
>> ((char *)pi) = &val;
>>
>> is not valid C. (It's also not valid C++.) When I attempt to compile
>> it, I get:
>>
>> error: lvalue required as left operand of assignment
> I can't see much wrong with it. It works fine with tcc and (my) bcc
> compilers. It assigns an address to pointer. The cast is needed
> because otherwise there's a type mismatch (assigning char* address to
> a int* pointer).
>
> I'm surprised that gcc reports it as an error rather than a warning as
> it does with nearly everything else, for example:
>
> int *pi;
> char *pc;
> pi = pc;
>
> gives a warning.
I'm not sure why you're surprised.
A cast operation takes an expression that specifies a *value* and yields
a *value* of the specified type. It does not yield a reference to an
object (in other words, it's not an lvalue).
Similarly, this:
int n;
n + 2 = 4;
does not set n to 2; it's a constraint violation, because n + 2 is not
an lvalue.
gcc does, in its default mode, allow a lot of implicit pointer
conversions that are not permitted by the language, perhaps because they
were usually permitted by pre-ANSI C implementations and the gcc
maintainers never saw a good time to break old code. I don't think
most historical C compilers ever treated cast expressions as lvalues,
so that consideration doesn't apply in this case.
You're right that tcc (I have version 0.9.27) accepts the assignment
without complaint. I find that surprising.
Certainly C *could* have been defined so that a cast expression can be
an lvalue (presumably only if the operand is an lvalue). It just wasn't
defined that way. A cast yields a converted value, not a converted
object.
(To be clear, the standard's syntactic category "cast-expression"
includes expressions that have no cast operators. I'm talking about an
expression with a cast operator at the top level.)
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-04-10 22:36 +0100 |
| Message-ID | <87edorzafq.fsf@bsb.me.uk> |
| In reply to | #169953 |
Bart <bc@freeuk.com> writes: > On 10/04/2023 19:22, Keith Thompson wrote: >> That line of code; >> >> ((char *)pi) = &val; >> >> is not valid C. (It's also not valid C++.) When I attempt to compile >> it, I get: >> >> error: lvalue required as left operand of assignment > > I can't see much wrong with it. It violates a constraint. A cast expression does not yield an l-value. Obviously, C could have been designed so that assigning to a cast expression meant something (what, exactly I don't know), but it was not. In C, you convert the value being assigned. > It works fine with tcc That's a shame. A diagnostic is required since tcc claims to be conforming. > and (my) bcc compilers. It assigns an address to pointer. The cast is > needed because otherwise there's a type mismatch (assigning char* > address to a int* pointer). A cast on the value makes that obvious. What does a cast on the lvalue do as there is nothing to convert? How does bcc treat double d; (int)d = 42; ? Does it just treat the cast as an instruction to be quiet while generating code to move sizeof 42 bytes to d's location? tcc, by the way, correctly generates a diagnostic (in fact an error): "error: lvalue expected" for that line. I don't know why it doesn't for the pointer case. > I'm surprised that gcc reports it as an error rather than a warning as it > does with nearly everything else, It's suggests the author of the code is deeply baffled by the language so I would agree that it's serious flaw meriting an error message. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-04-11 00:11 +0100 |
| Message-ID | <u1252l$2bnjb$1@dont-email.me> |
| In reply to | #169955 |
On 10/04/2023 22:36, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 10/04/2023 19:22, Keith Thompson wrote:
>
>>> That line of code;
>>>
>>> ((char *)pi) = &val;
>>>
>>> is not valid C. (It's also not valid C++.) When I attempt to compile
>>> it, I get:
>>>
>>> error: lvalue required as left operand of assignment
>>
>> I can't see much wrong with it.
>
> It violates a constraint. A cast expression does not yield an l-value.
> Obviously, C could have been designed so that assigning to a cast
> expression meant something (what, exactly I don't know), but it was not.
> In C, you convert the value being assigned.
Whatever the type of the LHS of an assignment, it would override that
with the cast type.
> How does bcc treat
>
> double d;
> (int)d = 42;
It doesn't report it but it doesn't work that well either. I think it
would just be simpler to not allow it.
My lvalue-checking logic needs to allow the use of & in front of an
lvalue expression, but it also needs to be stricter when it is the LHS
of an assignment or anything that modifies memory. I've now made that
change.
> ? Does it just treat the cast as an instruction to be quiet while
> generating code to move sizeof 42 bytes to d's location?
For the (int)d example, type-punning would be more more appropriate to
get that behaviour. There are no type-punning casts in C, but it can be
emulated with:
*(int*)&d = 42;
>
> tcc, by the way, correctly generates a diagnostic (in fact an error):
> "error: lvalue expected" for that line. I don't know why it doesn't
> for the pointer case.
The original example perhaps works in tcc, because the cast in that case
is a no-op, not requiring anything to be converted except changing the type.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 11:34 -0400 |
| Message-ID | <u11aau$27go8$1@dont-email.me> |
| In reply to | #169900 |
On 4/10/23 10:52, Dan Cross wrote:
> 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?
The comment about "implementation dependency" was written by Tim, jak
was merely referring to that comment.
>> 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.
Tim's comment about an implementation dependency was written about code
written by Kaz Kylheku. That code does indeed have an implementation
dependency. Depending upon which choice an implementation makes for the
null pointer constant that NULL expands into, Kaz's code might or might
not contain a constraint violation.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-10 15:37 +0000 |
| Message-ID | <u11afa$1jl$2@reader2.panix.com> |
| In reply to | #169905 |
In article <u11aau$27go8$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 4/10/23 10:52, Dan Cross wrote:
>> 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?
>
>The comment about "implementation dependency" was written by Tim, jak
>was merely referring to that comment.
It seemed that jak was suggesting that in Tim's forumulation,
one should cast the 0 in p = 0, as in `p = (void *)0`.
>>> 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.
>
>Tim's comment about an implementation dependency was written about code
>written by Kaz Kylheku. That code does indeed have an implementation
>dependency. Depending upon which choice an implementation makes for the
>null pointer constant that NULL expands into, Kaz's code might or might
>not contain a constraint violation.
That was not what I was referring to; see above and please note
the exact words I responded to (specifically the post that
referred to "autocast").
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 11:57 -0400 |
| Message-ID | <u11bll$27m86$1@dont-email.me> |
| In reply to | #169907 |
On 4/10/23 11:37, Dan Cross wrote:
> In article <u11aau$27go8$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 4/10/23 10:52, Dan Cross wrote:
>>> 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?
>>
>> The comment about "implementation dependency" was written by Tim, jak
>> was merely referring to that comment.
>
> It seemed that jak was suggesting that in Tim's forumulation,
> one should cast the 0 in p = 0, as in `p = (void *)0`.
I don't think so. I believe that he was suggesting that it would be
preferable to rewrite Kaz's formulation as "free(ptr), (void*)NULL", or
simply "free(ptr), (void*)0", which would avoid the implementation
dependency. I took this as a suggestion of style, rather than implying
that it was necessary. The fact that "p=0" implicitly converts 0 to 'p's
type, and is the value of the assignment expression, is a little too
subtle for Jak, and I can see his point.
>>>> 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.
>>
>> Tim's comment about an implementation dependency was written about code
>> written by Kaz Kylheku. That code does indeed have an implementation
>> dependency. Depending upon which choice an implementation makes for the
>> null pointer constant that NULL expands into, Kaz's code might or might
>> not contain a constraint violation.
>
> That was not what I was referring to; see above and please note
> the exact words I responded to (specifically the post that
> referred to "autocast").
Jak's comment using the phrase "autocast" was not referring to any
implementation dependency in Tim's code, only to the same implementation
dependency in Kaz's code that Tim himself was talking about.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-10 17:26 +0000 |
| Message-ID | <u11grn$q26$1@reader2.panix.com> |
| In reply to | #169910 |
In article <u11bll$27m86$1@dont-email.me>, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 4/10/23 11:37, Dan Cross wrote: >>[snip] >> It seemed that jak was suggesting that in Tim's forumulation, >> one should cast the 0 in p = 0, as in `p = (void *)0`. > >I don't think so. I believe that he was suggesting that it would be >preferable to rewrite Kaz's formulation as "free(ptr), (void*)NULL", or >simply "free(ptr), (void*)0", which would avoid the implementation >dependency. I took this as a suggestion of style, rather than implying >that it was necessary. The fact that "p=0" implicitly converts 0 to 'p's >type, and is the value of the assignment expression, is a little too >subtle for Jak, and I can see his point. You (and honestly, me) are both speculating. This is why I asked him what he meant; he responded by asking me why I was asking him. Subsequent posts from me suggest a less than stellar command of the language, so I suspect he's simply confused. >>>> This has nothing to do with that. Tim's code was correct and >>>> portable. >>> >>> Tim's comment about an implementation dependency was written about code >>> written by Kaz Kylheku. That code does indeed have an implementation >>> dependency. Depending upon which choice an implementation makes for the >>> null pointer constant that NULL expands into, Kaz's code might or might >>> not contain a constraint violation. >> >> That was not what I was referring to; see above and please note >> the exact words I responded to (specifically the post that >> referred to "autocast"). > >Jak's comment using the phrase "autocast" was not referring to any >implementation dependency in Tim's code, only to the same implementation >dependency in Kaz's code that Tim himself was talking about. Why don't we let him speak for himself? - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 14:27 -0400 |
| Message-ID | <u11kei$2907o$1@dont-email.me> |
| In reply to | #169928 |
On 4/10/23 13:26, Dan Cross wrote: > In article <u11bll$27m86$1@dont-email.me>, > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: ... > You (and honestly, me) are both speculating. This is why I > asked him what he meant; he responded by asking me why I was > asking him. Subsequent posts from me suggest a less than > stellar command of the language, so I suspect he's simply > confused. ... > Why don't we let him speak for himself? Because he hasn't chosen to do so, and because frankly, he doesn't do that good a job of it. He's got language difficulties, and is using Google translate to work around them. I've occasionally used Google translate to respond to foreign language inquiries that arrive in this newsgroup, but I always do so with a great deal of fear and trepidation about how it might have mangled my message.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-10 18:45 +0000 |
| Message-ID | <u11lfl$opd$1@reader2.panix.com> |
| In reply to | #169939 |
In article <u11kei$2907o$1@dont-email.me>, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 4/10/23 13:26, Dan Cross wrote: >> In article <u11bll$27m86$1@dont-email.me>, >> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >... >> You (and honestly, me) are both speculating. This is why I >> asked him what he meant; he responded by asking me why I was >> asking him. Subsequent posts from me suggest a less than >> stellar command of the language, so I suspect he's simply >> confused. >... >> Why don't we let him speak for himself? > >Because he hasn't chosen to do so, and because frankly, he doesn't do >that good a job of it. He's got language difficulties, and is using >Google translate to work around them. I've occasionally used Google >translate to respond to foreign language inquiries that arrive in this >newsgroup, but I always do so with a great deal of fear and trepidation >about how it might have mangled my message. Then given that you admit that neither of us actually knows what he originally meant, perhaps we should refrain from assuming and leveling accusations of "confusion" based on those assumptions. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-11 04:50 -0700 |
| Message-ID | <86y1my3afk.fsf@linuxsc.com> |
| In reply to | #169928 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: [...] > Why don't we let him speak for himself? +1 It would be nice if people would follow this precept more often.
[toc] | [prev] | [next] | [standalone]
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2023-04-10 15:58 +0000 |
| Message-ID | <Y8qq6QwnAovu5XLqP@bongo-ra.co> |
| In reply to | #169905 |
On Mon, 10 Apr 2023 11:34:54 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 4/10/23 10:52, Dan Cross wrote:
> > 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?
>
> The comment about "implementation dependency" was written by Tim, jak
> was merely referring to that comment.
Yes , but which piece of code was jak referring to ? For easy reference lets
call Code A
return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
which posted by Kaz in <20230407042121.909@kylheku.com> and Code B
void *
realloc0( void *p, size_t size ){
return size == 0 ? free( p ), p = 0 : realloc( p, size );
}
which was posted by Tim in <86r0st3zj0.fsf@linuxsc.com> .So when jak said
"If you absolutely wanted to avoid dependency" which of the 2 code excerpts
was he referring to ? I took it to mean that he was referring to Code B and I
think Dan took it to mean the same. Code B does not have any "implementation
dependency" , it just relies on the C standard. In contrast , Code A may have
a constraint violation depending on how the implementation defines NULL , as
Tim pointed out.
> >> 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.
>
> Tim's comment about an implementation dependency was written about code
> written by Kaz Kylheku. That code does indeed have an implementation
> dependency. Depending upon which choice an implementation makes for the
> null pointer constant that NULL expands into, Kaz's code might or might
> not contain a constraint violation.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 12:08 -0400 |
| Message-ID | <u11c9m$27m86$3@dont-email.me> |
| In reply to | #169912 |
On 4/10/23 11:58, Spiros Bousbouras wrote:
> On Mon, 10 Apr 2023 11:34:54 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
...
>> The comment about "implementation dependency" was written by Tim, jak
>> was merely referring to that comment.
>
> Yes , but which piece of code was jak referring to ? For easy reference lets
> call Code A
>
> return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>
> which posted by Kaz in <20230407042121.909@kylheku.com> and Code B
>
> void *
> realloc0( void *p, size_t size ){
> return size == 0 ? free( p ), p = 0 : realloc( p, size );
> }
>
> which was posted by Tim in <86r0st3zj0.fsf@linuxsc.com> .So when jak said
> "If you absolutely wanted to avoid dependency" which of the 2 code excerpts
> was he referring to ? I took it to mean that he was referring to Code B and I
> think Dan took it to mean the same. Code B does not have any "implementation
> dependency" , it just relies on the C standard. In contrast , Code A may have
> a constraint violation depending on how the implementation defines NULL , as
> Tim pointed out.
I took jak as referring to both code A and code B. He was saying that
code A has an implementation dependency, while code B did not, but that
he would prefer a different way of modifying code A to avoid that
dependency. I understood him to be expressing a stylistic preference,
not something required in order for the code to be correct.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-10 17:27 +0000 |
| Message-ID | <u11gui$q26$2@reader2.panix.com> |
| In reply to | #169914 |
In article <u11c9m$27m86$3@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 4/10/23 11:58, Spiros Bousbouras wrote:
>> On Mon, 10 Apr 2023 11:34:54 -0400
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>...
>>> The comment about "implementation dependency" was written by Tim, jak
>>> was merely referring to that comment.
>>
>> Yes , but which piece of code was jak referring to ? For easy reference lets
>> call Code A
>>
>> return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>>
>> which posted by Kaz in <20230407042121.909@kylheku.com> and Code B
>>
>> void *
>> realloc0( void *p, size_t size ){
>> return size == 0 ? free( p ), p = 0 : realloc( p, size );
>> }
>>
>> which was posted by Tim in <86r0st3zj0.fsf@linuxsc.com> .So when jak said
>> "If you absolutely wanted to avoid dependency" which of the 2 code excerpts
>> was he referring to ? I took it to mean that he was referring to Code B and I
>> think Dan took it to mean the same. Code B does not have any "implementation
>> dependency" , it just relies on the C standard. In contrast , Code A may have
>> a constraint violation depending on how the implementation defines NULL , as
>> Tim pointed out.
>
>I took jak as referring to both code A and code B. He was saying that
>code A has an implementation dependency, while code B did not, but that
>he would prefer a different way of modifying code A to avoid that
>dependency. I understood him to be expressing a stylistic preference,
>not something required in order for the code to be correct.
Instead of assuming, you should simply ask him.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-11 04:47 -0700 |
| Message-ID | <865ya24p4i.fsf@linuxsc.com> |
| In reply to | #169900 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> 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?
I didn't take his comment that way. My impression is that he
meant there _might_ be a dependency, or perhaps there is some
uncertainty about whether there is a dependency, or possibly that
there may be a dependency at some time in the future. Of course
I am not sure what he meant, but that is how I took it.
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web