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 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 10:26 -0400 |
| Message-ID | <u116a4$270uv$1@dont-email.me> |
| In reply to | #169885 |
On 4/9/23 15:34, Dan Cross wrote:
> 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?
The C standard merely requires that NULL expand to a null pointer
constant. It depends upon the implementation which null pointer constant
it expands to. A null pointer constant necessarily has either an integer
type or the type void*. The comma expression will have that same type.
An integer type results in a constraint violation, void* does not.
That's the implementation dependency that Tim was talking about.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-10 14:51 +0000 |
| Message-ID | <u117os$9r2$1@reader2.panix.com> |
| In reply to | #169896 |
In article <u116a4$270uv$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 4/9/23 15:34, Dan Cross wrote:
>> 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?
>
>The C standard merely requires that NULL expand to a null pointer
>constant. It depends upon the implementation which null pointer constant
>it expands to. A null pointer constant necessarily has either an integer
>type or the type void*. The comma expression will have that same type.
>An integer type results in a constraint violation, void* does not.
>That's the implementation dependency that Tim was talking about.
The C standard has been quite explicit that integer 0 is
a valid null pointer constant since C89. Tim's code was
correct and had no dependency.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 11:20 -0400 |
| Message-ID | <u119gi$27go7$1@dont-email.me> |
| In reply to | #169899 |
On 4/10/23 10:51, Dan Cross wrote:
> In article <u116a4$270uv$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 4/9/23 15:34, Dan Cross wrote:
>>> 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?
>>
>> The C standard merely requires that NULL expand to a null pointer
>> constant. It depends upon the implementation which null pointer constant
>> it expands to. A null pointer constant necessarily has either an integer
>> type or the type void*. The comma expression will have that same type.
>> An integer type results in a constraint violation, void* does not.
>> That's the implementation dependency that Tim was talking about.
>
> The C standard has been quite explicit that integer 0 is
> a valid null pointer constant since C89. Tim's code was
> correct and had no dependency.
Correct. 0 is a valid null pointer constant. It has a type of int.
Therefore, the expression "free(p), 0' would have a value of 0 and a
type of int. The expression 'size == 0 ? NULL : realloc(p, size)" would
not be problematic because, in that context, a null pointer constant
gets implicitly converted to a null pointer with the same type as the
return value of realloc (6.5.15p7). However, function calls are not
allowed in integer constant expressions (6.6p6), so "free(p), 0" does
NOT qualify as an integer constant expression, and therefore also does
not qualify as a null pointer constant (6.3.2.3p3). A conditional
expression where the second operand has an arithmetic type, but does not
qualify as a null pointer constant, and a third operand that has pointer
type, doesn't match any of the permitted combinations listed in the
constraints on conditional expressions (6.5.15p3):
"One of the following shall hold for the second and third operands:
ISO/IEC 9899:202x (E)
— both operands have arithmetic type;
— both operands have the same structure or union type;
— both operands have void type;
— both operands are pointers to qualified or unqualified versions of
compatible types;
— one operand is a pointer and the other is a null pointer constant; or
— one operand is a pointer to an object type and the other is a pointer
to a qualified or unqualified
version of void ."
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-10 15:35 +0000 |
| Message-ID | <u11aba$1jl$1@reader2.panix.com> |
| In reply to | #169901 |
In article <u119gi$27go7$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 4/10/23 10:51, Dan Cross wrote:
>> In article <u116a4$270uv$1@dont-email.me>,
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> On 4/9/23 15:34, Dan Cross wrote:
>>>> 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?
>>>
>>> The C standard merely requires that NULL expand to a null pointer
>>> constant. It depends upon the implementation which null pointer constant
>>> it expands to. A null pointer constant necessarily has either an integer
>>> type or the type void*. The comma expression will have that same type.
>>> An integer type results in a constraint violation, void* does not.
>>> That's the implementation dependency that Tim was talking about.
>>
>> The C standard has been quite explicit that integer 0 is
>> a valid null pointer constant since C89. Tim's code was
>> correct and had no dependency.
>
>Correct. 0 is a valid null pointer constant. It has a type of int.
>Therefore, the expression "free(p), 0' would have a value of 0 and a
>type of int. The expression 'size == 0 ? NULL : realloc(p, size)" would
>not be problematic because, in that context, a null pointer constant
>gets implicitly converted to a null pointer with the same type as the
>return value of realloc (6.5.15p7). However, function calls are not
>allowed in integer constant expressions (6.6p6), so "free(p), 0" does
>NOT qualify as an integer constant expression, and therefore also does
>not qualify as a null pointer constant (6.3.2.3p3). A conditional
>expression where the second operand has an arithmetic type, but does not
>qualify as a null pointer constant, and a third operand that has pointer
>type, doesn't match any of the permitted combinations listed in the
>constraints on conditional expressions (6.5.15p3):
>
>"One of the following shall hold for the second and third operands:
>ISO/IEC 9899:202x (E)
>— both operands have arithmetic type;
>— both operands have the same structure or union type;
>— both operands have void type;
>— both operands are pointers to qualified or unqualified versions of
>compatible types;
>— one operand is a pointer and the other is a null pointer constant; or
>— one operand is a pointer to an object type and the other is a pointer
>to a qualified or unqualified
>version of void ."
I do not know why you are addressing this to me. I agreed with
the overall analysis and don't think I posted anything to the
contrary.
Perhaps you meant to respond to someone else?
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 12:04 -0400 |
| Message-ID | <u11c1o$27m86$2@dont-email.me> |
| In reply to | #169906 |
On 4/10/23 11:35, Dan Cross wrote:
> In article <u119gi$27go7$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 4/10/23 10:51, Dan Cross wrote:
>>> In article <u116a4$270uv$1@dont-email.me>,
>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>> On 4/9/23 15:34, Dan Cross wrote:
>>>>> 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?
>>>>
>>>> The C standard merely requires that NULL expand to a null pointer
>>>> constant. It depends upon the implementation which null pointer
>>>> constant
>>>> it expands to. A null pointer constant necessarily has either an
>>>> integer
>>>> type or the type void*. The comma expression will have that same type.
>>>> An integer type results in a constraint violation, void* does not.
>>>> That's the implementation dependency that Tim was talking about.
>>>
>>> The C standard has been quite explicit that integer 0 is
>>> a valid null pointer constant since C89. Tim's code was
>>> correct and had no dependency.
>>
>> Correct. 0 is a valid null pointer constant. It has a type of int.
>> Therefore, the expression "free(p), 0' would have a value of 0 and a
>> type of int. The expression 'size == 0 ? NULL : realloc(p, size)" would
>> not be problematic because, in that context, a null pointer constant
>> gets implicitly converted to a null pointer with the same type as the
>> return value of realloc (6.5.15p7). However, function calls are not
>> allowed in integer constant expressions (6.6p6), so "free(p), 0" does
>> NOT qualify as an integer constant expression, and therefore also does
>> not qualify as a null pointer constant (6.3.2.3p3). A conditional
>> expression where the second operand has an arithmetic type, but does not
>> qualify as a null pointer constant, and a third operand that has pointer
>> type, doesn't match any of the permitted combinations listed in the
>> constraints on conditional expressions (6.5.15p3):
>>
>> "One of the following shall hold for the second and third operands:
>> ISO/IEC 9899:202x (E)
>> — both operands have arithmetic type;
>> — both operands have the same structure or union type;
>> — both operands have void type;
>> — both operands are pointers to qualified or unqualified versions of
>> compatible types;
>> — one operand is a pointer and the other is a null pointer constant; or
>> — one operand is a pointer to an object type and the other is a pointer
>> to a qualified or unqualified
>> version of void ."
>
> I do not know why you are addressing this to me. I agreed with
> the overall analysis and don't think I posted anything to the
> contrary.
>
> Perhaps you meant to respond to someone else?
This analysis is ultimately a response to the question "What
"dependency" would that avoid, other than a dependency on the C
standard?". As far as I can tell, you are the one who posted that
question, in the message with the header
Date: Sun, 9 Apr 2023 19:34:09 -0000 (UTC)
The simplest explanation of your confusion I can come up with is that
you misunderstood jak as suggesting that that dependency was in Tim's
code, rather than Kaz's.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-10 17:34 +0000 |
| Message-ID | <u11hbv$q26$3@reader2.panix.com> |
| In reply to | #169913 |
In article <u11c1o$27m86$2@dont-email.me>, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 4/10/23 11:35, Dan Cross wrote: >>[snip] >> I do not know why you are addressing this to me. I agreed with >> the overall analysis and don't think I posted anything to the >> contrary. >> >> Perhaps you meant to respond to someone else? > >This analysis is ultimately a response to the question "What >"dependency" would that avoid, other than a dependency on the C >standard?". As far as I can tell, you are the one who posted that >question, in the message with the header > >Date: Sun, 9 Apr 2023 19:34:09 -0000 (UTC) > >The simplest explanation of your confusion I can come up with is that >you misunderstood jak as suggesting that that dependency was in Tim's >code, rather than Kaz's. First, please stop emailing me about this. Keep it in USENET. Second, you are making an assumption about user jak's intent. Respectfully, I think your assumption is wrong, which leads to your (ahem) "confusion." Perhaps try to clarify with jak what they mean before continuing the conversation; I tried and was rebuffed, but perhaps you will have better luck. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-11 11:24 -0400 |
| Message-ID | <u13u3a$2llhr$1@dont-email.me> |
| In reply to | #169931 |
On 4/10/23 13:34, Dan Cross wrote: > In article <u11c1o$27m86$2@dont-email.me>, > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: ... >> This analysis is ultimately a response to the question "What >> "dependency" would that avoid, other than a dependency on the C >> standard?". As far as I can tell, you are the one who posted that >> question, in the message with the header >> >> Date: Sun, 9 Apr 2023 19:34:09 -0000 (UTC) >> >> The simplest explanation of your confusion I can come up with is that >> you misunderstood jak as suggesting that that dependency was in Tim's >> code, rather than Kaz's. > > First, please stop emailing me about this. Keep it in USENET. I've already said this to you by e-mail, and I've explained it before to the group, but I'll repeat it for the benefit of anyone who doesn't remember my previous apologies: I spent more than a decade using a newsreader that had a "Reply" button that would send a message to the newsgroup, and provided only a significantly less convenient method for sending a response to the author (I no longer remember what that method was). A few years ago, they changed their interface to provide a "Follow Up" button which does what the old "Reply" button did, and a "Reply" button that now sends a response only to the author. I've been trying ever since then to break my habit of hitting the "Reply" button, but with very poor success, as you have seen. This old dog does not learn new tricks as easily as I used to. I promise to try to remember to hit the "Follow Up" button instead, but since that's what I'm already trying to do, I would not recommend expecting any different results. > Second, you are making an assumption about user jak's intent. > Respectfully, I think your assumption is wrong, which leads to > your (ahem) "confusion." Perhaps try to clarify with jak what > they mean before continuing the conversation; I tried and was > rebuffed, but perhaps you will have better luck. He's had plenty of opportunities to tell us who is interpreting his words correctly. He's not bothered to do so. Until he does, we'll just have to agree to disagree.
[toc] | [prev] | [next] | [standalone]
| From | kalevi@kolttonen.fi (Kalevi Kolttonen) |
|---|---|
| Date | 2023-04-11 16:17 +0000 |
| Message-ID | <u1416h$2m01j$1@dont-email.me> |
| In reply to | #169974 |
James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > I spent more than a decade using a newsreader that had a "Reply" button > that would send a message to the newsgroup, and provided only a > significantly less convenient method for sending a response to the > author (I no longer remember what that method was). A few years ago, > they changed their interface to provide a "Follow Up" button which does > what the old "Reply" button did, and a "Reply" button that now sends a > response only to the author. I've been trying ever since then to break > my habit of hitting the "Reply" button, but with very poor success, as > you have seen. This old dog does not learn new tricks as easily as I > used to. I promise to try to remember to hit the "Follow Up" button > instead, but since that's what I'm already trying to do, I would not > recommend expecting any different results. My deepest apologies for this off-topic post, but I must say that I feel your pain. I had this TV "digibox" about 10 years ago. Its GUI design was pretty crazy right from the beginning. The menu that applied to recorded TV programs had "delete" (single item) and "delete all" right next to each other. So it would be pretty easy to delete all your recordings by accident. Somehow I avoided doing so. After many years, one day I updated the digibox to the latest software version. After the update, the "delete" and "delete all" were still next to each other, but their location was different. After watching an episode of Star Trek TNG, my intention was to delete it in order to save disk space. Using mental autopilot I pointed the cursor to the same location where "delete" had been for many years. I was then asked to confirm the deletion. While still on total autopilot, I quickly replied "yes". BANG! The next thing I knew was that all my recordings were gone and there were at least one hundred of them! The GUI designers had placed "delete all" to the very same location that used to have "delete" (single item). It is hard to believe this kind of GUI design can be real. I do not remember the digibox manufacturer any more. It could have been Topfield, but I am not sure. br, KK
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-04-11 18:13 +0100 |
| Message-ID | <u144ge$2m8gk$1@dont-email.me> |
| In reply to | #169981 |
On 11/04/2023 17:17, Kalevi Kolttonen wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> I spent more than a decade using a newsreader that had a "Reply" button >> that would send a message to the newsgroup, and provided only a >> significantly less convenient method for sending a response to the >> author (I no longer remember what that method was). A few years ago, >> they changed their interface to provide a "Follow Up" button which does >> what the old "Reply" button did, and a "Reply" button that now sends a >> response only to the author. I've been trying ever since then to break >> my habit of hitting the "Reply" button, but with very poor success, as >> you have seen. This old dog does not learn new tricks as easily as I >> used to. I promise to try to remember to hit the "Follow Up" button >> instead, but since that's what I'm already trying to do, I would not >> recommend expecting any different results. > > My deepest apologies for this off-topic post, but I must say > that I feel your pain. > > I had this TV "digibox" about 10 years ago. Its GUI design was pretty > crazy right from the beginning. The menu that applied to recorded > TV programs had "delete" (single item) and "delete all" right next > to each other. So it would be pretty easy to delete all your recordings > by accident. Somehow I avoided doing so. > > After many years, one day I updated the digibox to the latest > software version. After the update, the "delete" and "delete all" > were still next to each other, but their location was different. > > After watching an episode of Star Trek TNG, my intention was to > delete it in order to save disk space. Using mental autopilot > I pointed the cursor to the same location where "delete" > had been for many years. I was then asked to confirm the > deletion. While still on total autopilot, I quickly replied > "yes". > > BANG! The next thing I knew was that all my recordings were > gone and there were at least one hundred of them! The GUI > designers had placed "delete all" to the very same location > that used to have "delete" (single item). > > It is hard to believe this kind of GUI design can be real. Is there no confirmation needed for 'Delete All'? That would be incredibly bad design and should been reported on the original too. I have a PVR that is older than ten years, and that will confirm first, I think even for single items. Although even that could go wrong: it should report how many items will be affected, in case you'd clicked the wrong button.
[toc] | [prev] | [next] | [standalone]
| From | kalevi@kolttonen.fi (Kalevi Kolttonen) |
|---|---|
| Date | 2023-04-11 17:58 +0000 |
| Message-ID | <u1473c$2mhe7$1@dont-email.me> |
| In reply to | #169982 |
Bart <bc@freeuk.com> wrote: > On 11/04/2023 17:17, Kalevi Kolttonen wrote: >> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>> I spent more than a decade using a newsreader that had a "Reply" button >>> that would send a message to the newsgroup, and provided only a >>> significantly less convenient method for sending a response to the >>> author (I no longer remember what that method was). A few years ago, >>> they changed their interface to provide a "Follow Up" button which does >>> what the old "Reply" button did, and a "Reply" button that now sends a >>> response only to the author. I've been trying ever since then to break >>> my habit of hitting the "Reply" button, but with very poor success, as >>> you have seen. This old dog does not learn new tricks as easily as I >>> used to. I promise to try to remember to hit the "Follow Up" button >>> instead, but since that's what I'm already trying to do, I would not >>> recommend expecting any different results. >> >> My deepest apologies for this off-topic post, but I must say >> that I feel your pain. >> >> I had this TV "digibox" about 10 years ago. Its GUI design was pretty >> crazy right from the beginning. The menu that applied to recorded >> TV programs had "delete" (single item) and "delete all" right next >> to each other. So it would be pretty easy to delete all your recordings >> by accident. Somehow I avoided doing so. >> >> After many years, one day I updated the digibox to the latest >> software version. After the update, the "delete" and "delete all" >> were still next to each other, but their location was different. >> >> After watching an episode of Star Trek TNG, my intention was to >> delete it in order to save disk space. Using mental autopilot >> I pointed the cursor to the same location where "delete" >> had been for many years. I was then asked to confirm the >> deletion. While still on total autopilot, I quickly replied >> "yes". >> >> BANG! The next thing I knew was that all my recordings were >> gone and there were at least one hundred of them! The GUI >> designers had placed "delete all" to the very same location >> that used to have "delete" (single item). >> >> It is hard to believe this kind of GUI design can be real. > > Is there no confirmation needed for 'Delete All'? That would be > incredibly bad design and should been reported on the original too. If you read carefully what I wrote, I did say: "I was then asked to confirm the deletion. While still on total autopilot, I quickly replied "yes". So, yes, the confirmation was indeed needed. But after many years of using this digibox, I was like a Pavlov's Dog, fully conditioned to know the location of "Delete" (single item). When that basic assumption failed, all hell broke loose and I just clicked "Yes" simply not realizing that the button was now "Delete All". I cannot remember if it said "Want to delete all items" or "Want to delete this item". All in all, my user mistake was also involved, but I still very much blame those who: 1) First put "Delete" and "Delete All" right next to each other 2) Then put "Delete All" to where "Delete" was previously I really have no education concerning how to design GUIs, but I am pretty sure this is *not* the way to do it. br, KK
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-09 12:41 -0700 |
| Message-ID | <871qkshmhv.fsf@nosuchdomain.example.com> |
| In reply to | #169883 |
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.
--
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 | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 09:31 +0200 |
| Message-ID | <u10dvr$23np8$1@dont-email.me> |
| In reply to | #169887 |
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.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 09:46 -0400 |
| Message-ID | <u11404$26gpq$1@dont-email.me> |
| In reply to | #169892 |
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 C standard is a semi-formal document, and defines the meanings of many terms used in that document, meanings that are almost always at least subtly (and often not so subtly) different from the normal meaning of the English words that they are built from. The meanings defined by the standard are the ones that apply when interpreting what the standard means. It is correspondingly important to know what those meanings are. 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. "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)
[toc] | [prev] | [next] | [standalone]
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 16:29 +0200 |
| Message-ID | <u116gd$273m1$1@dont-email.me> |
| In reply to | #169895 |
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 C standard is a semi-formal document, and defines the meanings of > many terms used in that document, meanings that are almost always at > least subtly (and often not so subtly) different from the normal meaning > of the English words that they are built from. The meanings defined by > the standard are the ones that apply when interpreting what the standard > means. It is correspondingly important to know what those meanings are. > > 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. > > "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) > > 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.
[toc] | [prev] | [next] | [standalone]
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 16:37 +0200 |
| Message-ID | <u116uf$275ph$1@dont-email.me> |
| In reply to | #169897 |
>> > 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.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 11:26 -0400 |
| Message-ID | <u119q9$27go7$3@dont-email.me> |
| In reply to | #169898 |
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.
[toc] | [prev] | [next] | [standalone]
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 17:43 +0200 |
| Message-ID | <u11aqa$27na5$1@dont-email.me> |
| In reply to | #169903 |
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...
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 12:19 -0400 |
| Message-ID | <u11cuh$281i6$1@dont-email.me> |
| In reply to | #169908 |
On 4/10/23 11:43, jak wrote: > 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... No, I'm dead serious. This is the wrong newsgroup to discuss specialized functions, because C doesn't have them. There would be both more interest, and more expertise, for a discussion of that issue in comp.lang.c++ than here. I'm also dead serious about the change in Subject. When you introduce a radical change of topic, it is indeed good netiquette to make a corresponding change to the "Subject:" header.
[toc] | [prev] | [next] | [standalone]
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 18:35 +0200 |
| Message-ID | <u11dt3$28648$1@dont-email.me> |
| In reply to | #169916 |
James Kuyper ha scritto: > On 4/10/23 11:43, jak wrote: >> 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... > > No, I'm dead serious. This is the wrong newsgroup to discuss specialized > functions, because C doesn't have them. There would be both more > interest, and more expertise, for a discussion of that issue in > comp.lang.c++ than here. > I'm also dead serious about the change in Subject. When you introduce a > radical change of topic, it is indeed good netiquette to make a > corresponding change to the "Subject:" header. > What I can't explain to you is that you are fixated on terminology while I'm trying to explain myself largely using the google translator. By specialized function (this is the google translation) I mean a function that has return values and parameters different from the inte type so not like: int foo(int) You could, however, propose to the newsgroup manager that non-native English speakers should not use it... or become less meticulous.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2023-04-10 10:02 -0700 |
| Message-ID | <681e3cb9-65b6-472b-b710-4e492154f238n@googlegroups.com> |
| In reply to | #169918 |
On Monday, 10 April 2023 at 19:36:00 UTC+3, jak wrote: > James Kuyper ha scritto: > > On 4/10/23 11:43, jak wrote: > >> 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... > > > > No, I'm dead serious. This is the wrong newsgroup to discuss specialized > > functions, because C doesn't have them. There would be both more > > interest, and more expertise, for a discussion of that issue in > > comp.lang.c++ than here. > > I'm also dead serious about the change in Subject. When you introduce a > > radical change of topic, it is indeed good netiquette to make a > > corresponding change to the "Subject:" header. > > > > What I can't explain to you is that you are fixated on terminology while > I'm trying to explain myself largely using the google translator. By > specialized function (this is the google translation) I mean a function > that has return values and parameters different from the inte type so > not like: > > int foo(int) > That indeed is change of subject, what you post is not array, and it is still unclear what you want. We can define variable of type of array of function pointers without any typedefs like that: double (*array_of_function_pointers[52]) (float f, char c); That AFAIK works both in C and in C++. > You could, however, propose to the newsgroup manager that non-native > English speakers should not use it... or become less meticulous. What newsreader it is that does not let you to start a new thread or to change the subject line when you want to change subject? Never seen such thing.
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web