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 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 20:14 +0200 |
| Message-ID | <u11jlk$290gn$1@dont-email.me> |
| In reply to | #169924 |
Öö Tiib ha scritto: > 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. > I apologize. The type of data was, perhaps, more complex, also it was not a declaration but a cast for which I asked for advice on this newsgroup a few years ago and more than one person replied that the only way was through a typedef. But that wasn't the point. The point was to be able to say that thanks to the continuous changes to follow the standards some things that worked have stopped.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-10 11:34 -0700 |
| Message-ID | <87sfd7fuwn.fsf@nosuchdomain.example.com> |
| In reply to | #169937 |
jak <nospam@please.ty> writes:
[...]
> I apologize. The type of data was, perhaps, more complex, also it was
> not a declaration but a cast for which I asked for advice on this
> newsgroup a few years ago and more than one person replied that the only
> way was through a typedef. But that wasn't the point. The point was to
> be able to say that thanks to the continuous changes to follow the
> standards some things that worked have stopped.
I do not believe that there have been any changes to the standard that
cause some construct to require a typedef where a typedef was not
previously required. I suspect that anyone who said that "the only
way was through a typedef" was mistaken. (It's likely that a typedef
would make the code easier to read.)
It's entirely possible that I'm mistaken, and if so I would very much
like to know about it.
Please show us the code in question.
--
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 | Ike Naar <ike@sdf.org> |
|---|---|
| Date | 2023-04-10 21:47 +0000 |
| Message-ID | <slrnu39103.dr6.ike@iceland.freeshell.org> |
| In reply to | #169942 |
On 2023-04-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > jak <nospam@please.ty> writes: >> I apologize. The type of data was, perhaps, more complex, also it was >> not a declaration but a cast for which I asked for advice on this >> newsgroup a few years ago and more than one person replied that the only >> way was through a typedef. > > I do not believe that there have been any changes to the standard that > cause some construct to require a typedef where a typedef was not > previously required. I suspect that anyone who said that "the only > way was through a typedef" was mistaken. (It's likely that a typedef > would make the code easier to read.) > > It's entirely possible that I'm mistaken, and if so I would very much > like to know about it. An example: a function that returns a pointer to a function of the same type. It's mentioned in comp.lang.c FAQ 1.22, <https://c-faq.com/decl/recurfuncp.html>.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-04-10 23:04 +0100 |
| Message-ID | <878rezz962.fsf@bsb.me.uk> |
| In reply to | #169956 |
Ike Naar <ike@sdf.org> writes: > On 2023-04-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> jak <nospam@please.ty> writes: >>> I apologize. The type of data was, perhaps, more complex, also it was >>> not a declaration but a cast for which I asked for advice on this >>> newsgroup a few years ago and more than one person replied that the only >>> way was through a typedef. >> >> I do not believe that there have been any changes to the standard that >> cause some construct to require a typedef where a typedef was not >> previously required. I suspect that anyone who said that "the only >> way was through a typedef" was mistaken. (It's likely that a typedef >> would make the code easier to read.) >> >> It's entirely possible that I'm mistaken, and if so I would very much >> like to know about it. > > An example: a function that returns a pointer to a function of the same type. > It's mentioned in comp.lang.c FAQ 1.22, > <https://c-faq.com/decl/recurfuncp.html>. I don't think that's an example of something that can only be done with a typedef. For one thing, it can't be done at all (/even/ using a typedef), but when one /is/ used, surely it's just to make the almost-doing it code easier to read? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2023-04-11 01:08 -0700 |
| Message-ID | <a90dd97b-41f5-45f4-a19a-0d2bb1968fbcn@googlegroups.com> |
| In reply to | #169958 |
On Tuesday, 11 April 2023 at 01:04:22 UTC+3, Ben Bacarisse wrote: > Ike Naar <i...@sdf.org> writes: > > > On 2023-04-10, Keith Thompson <Keith.S.T...@gmail.com> wrote: > >> jak <nos...@please.ty> writes: > >>> I apologize. The type of data was, perhaps, more complex, also it was > >>> not a declaration but a cast for which I asked for advice on this > >>> newsgroup a few years ago and more than one person replied that the only > >>> way was through a typedef. > >> > >> I do not believe that there have been any changes to the standard that > >> cause some construct to require a typedef where a typedef was not > >> previously required. I suspect that anyone who said that "the only > >> way was through a typedef" was mistaken. (It's likely that a typedef > >> would make the code easier to read.) > >> > >> It's entirely possible that I'm mistaken, and if so I would very much > >> like to know about it. > > > > An example: a function that returns a pointer to a function of the same type. > > It's mentioned in comp.lang.c FAQ 1.22, > > <https://c-faq.com/decl/recurfuncp.html>. > > I don't think that's an example of something that can only be done with > a typedef. For one thing, it can't be done at all (/even/ using a > typedef), but when one /is/ used, surely it's just to make the > almost-doing it code easier to read? > Yes. For other thing jak says it was not the point but example about issues because of evolution of languages and changes in standards. That can't be such example as a function returning pointer to function of same type can not be declared by any standard of C (nor C++). Also as dereferencing function pointers is now implicit (but explicit dereferencing is also not illegal) the standards have actually relaxed it a bit. I suspect that jak is not vague because of translation to English but because he remembers disliking some breaking change between standards years ago but has now forgot what it was.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-11 11:26 -0400 |
| Message-ID | <u13u6d$2llhr$4@dont-email.me> |
| In reply to | #169956 |
On 4/10/23 17:47, Ike Naar wrote: > On 2023-04-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: ... >> I do not believe that there have been any changes to the standard that >> cause some construct to require a typedef where a typedef was not >> previously required. I suspect that anyone who said that "the only >> way was through a typedef" was mistaken. (It's likely that a typedef >> would make the code easier to read.) >> >> It's entirely possible that I'm mistaken, and if so I would very much >> like to know about it. > > An example: a function that returns a pointer to a function of the > same type. > It's mentioned in comp.lang.c FAQ 1.22, > <https://c-faq.com/decl/recurfuncp.html>. That's not an example of a construct requiring the use of a typedef. A typedef is convenient, but not required. As it says on that page: "without [the typedef], the state variable would have to be declared as funcptr (*state)() and the call would contain a bewildering cast of the form (funcptr (*)())(*state)()."
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2023-04-11 02:43 -0700 |
| Message-ID | <f222e30c-8842-4cf6-818d-a32e77a61fe2n@googlegroups.com> |
| In reply to | #169937 |
On Monday, 10 April 2023 at 21:14:24 UTC+3, jak wrote: > Öö Tiib ha scritto: > > 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. > > > > I apologize. The type of data was, perhaps, more complex, also it was > not a declaration but a cast for which I asked for advice on this > newsgroup a few years ago and more than one person replied that the only > way was through a typedef. But that wasn't the point. The point was to > be able to say that thanks to the continuous changes to follow the > standards some things that worked have stopped. Yes there are some breaking changes between standards of C. The amount of such changes is far lower than between versions of most other popular programming languages. The tradition of backwards compatibility is ver high in C. Each breaking change felt to have more than one good reason to break the code that it broke (to me). Similar sentiments are probably the reason why people are asking you to be more precise about the example that you talk about. If you have forgotten it then it wasn't perhaps that important?
[toc] | [prev] | [next] | [standalone]
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-11 15:14 +0200 |
| Message-ID | <u13mep$2l286$1@dont-email.me> |
| In reply to | #169962 |
Öö Tiib ha scritto: > On Monday, 10 April 2023 at 21:14:24 UTC+3, jak wrote: >> Öö Tiib ha scritto: >>> 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. >>> >> >> I apologize. The type of data was, perhaps, more complex, also it was >> not a declaration but a cast for which I asked for advice on this >> newsgroup a few years ago and more than one person replied that the only >> way was through a typedef. But that wasn't the point. The point was to >> be able to say that thanks to the continuous changes to follow the >> standards some things that worked have stopped. > > Yes there are some breaking changes between standards of C. > The amount of such changes is far lower than between versions of > most other popular programming languages. The tradition > of backwards compatibility is ver high in C. Each breaking change > felt to have more than one good reason to break the code that it > broke (to me). Similar sentiments are probably the reason why people > are asking you to be more precise about the example that you talk > about. If you have forgotten it then it wasn't perhaps that important? > > > Don't be too hard on me and above all give me the time necessary to find that thread. Thinking about it, I remembered a few things that will help me find it. For example, at that time Bart asked me if he could use a piece of my code in one of his essays or books, and no, now it's no longer necessary to have an answer because following their advice and using the typedef I solved my problem. Anyway I'm looking for the thread but it's been almost 20 years, maybe more. For now I only remember that it concerned arrays with function pointers and it did not concern their declaration but a cast to their type... but looking for a thread from 20 years ago... this is really a waste of time.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-11 11:35 -0400 |
| Message-ID | <u13una$2llhr$5@dont-email.me> |
| In reply to | #169973 |
On 4/11/23 09:14, jak wrote: ... > that thread. Thinking about it, I remembered a few things that will help > me find it. For example, at that time Bart asked me if he could use a > piece of my code in one of his essays or books, and no, now it's no > longer necessary to have an answer because following their advice and > using the typedef I solved my problem. Anyway I'm looking for the thread > but it's been almost 20 years, maybe more. For now I only remember that > it concerned arrays with function pointers and it did not concern their > declaration but a cast to their type... but looking for a thread from 20 > years ago... this is really a waste of time. The fundamental problem is that, in C, a typedef is nothing more than an synonym for a type. In any context where you use a typedef, you could also use the explicit type itself. Therefore, it's not possible that you were forced to use a typedef. A typedef often makes code easier to read and write, but is never necessary. The kind of code you're talking about is one of the contexts where that is true.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-11 12:09 -0400 |
| Message-ID | <u140og$2llhr$7@dont-email.me> |
| In reply to | #169978 |
On 4/11/23 11:35, James Kuyper wrote:
...
> The fundamental problem is that, in C, a typedef is nothing more than an
> synonym for a type. In any context where you use a typedef, you could
> also use the explicit type itself. Therefore, it's not possible that you
> were forced to use a typedef. A typedef often makes code easier to read
> and write, but is never necessary. The kind of code you're talking about
> is one of the contexts where that is true.
Note that this is NOT true in C++: the type that a typedef describes can
have a different language linkage than the function that it is used to
declare. This allows a function's name to have different language
linkage than the function's type:
extern "C" typedef void FUNC();
FUNC f2; // the name f2 has C ++ language linkage and the
// function’s type has C language linkage
(C++ standard, 9.11p5)
This is the only case I'm aware of, in either language, where a typedef
is necessary, and not merely convenient.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-11 19:46 -0700 |
| Message-ID | <86ile13jiq.fsf@linuxsc.com> |
| In reply to | #169978 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 4/11/23 09:14, jak wrote:
> ...
>
>> that thread. Thinking about it, I remembered a few things that
>> will help me find it. For example, at that time Bart asked me if
>> he could use a piece of my code in one of his essays or books, and
>> no, now it's no longer necessary to have an answer because
>> following their advice and using the typedef I solved my problem.
>> Anyway I'm looking for the thread but it's been almost 20 years,
>> maybe more. For now I only remember that it concerned arrays with
>> function pointers and it did not concern their declaration but a
>> cast to their type... but looking for a thread from 20 years
>> ago... this is really a waste of time.
>
> The fundamental problem is that, in C, a typedef is nothing more
> than an synonym for a type. In any context where you use a typedef,
> you could also use the explicit type itself. [...]
Strictly speaking this assertion isn't quite right. Here is an
example:
typedef long Elongator( int );
extern const Elongator *elongator;
There is no way to declare the pointer object 'elongator' without
the use of a typedef.
It may be worth noting that using a type qualifier directly on a
function type is explicitly undefined behavior (but not a constraint
violation). However, an implementation might want to take advantage
of that in defining a language extension.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-11 22:44 -0700 |
| Message-ID | <ea984bd9-b83e-4105-9dee-7b517c2c6fd2n@googlegroups.com> |
| In reply to | #169989 |
On Tuesday, April 11, 2023 at 10:46:24 PM UTC-4, Tim Rentsch wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
...
> > The fundamental problem is that, in C, a typedef is nothing more
> > than an synonym for a type. In any context where you use a typedef,
> > you could also use the explicit type itself. [...]
>
> Strictly speaking this assertion isn't quite right. Here is an
> example:
>
> typedef long Elongator( int );
>
> extern const Elongator *elongator;
I'm confused by that declaration - what is the 'const' supposed to mean in that context? Normally, I would read that declaration as saying that elongator is an identifier with external linkage, and that (*elongator)(5) returns a "const long", which makes no sense to me.
> There is no way to declare the pointer object 'elongator' without
> the use of a typedef.
> It may be worth noting that using a type qualifier directly on a
> function type is explicitly undefined behavior (but not a constraint
> violation).
gcc shares my confusion about that declaration, referring to precisely that rule:
elongator.h:2:25: warning: ISO C forbids qualified function types [-Wpedantic]
2 | extern const Elongator *elongator;
| ^~~~~~~~~
That error message disappears if I move the 'const', so that it qualifies elongator, which makes a lot more sense to me:
extern Elongator * const elongator;
and it accepts, as compatible, the following declaration of the same identifier:
extern long(*const elongator)(int);
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-04-12 09:46 +0200 |
| Message-ID | <u15nk7$2uuci$1@dont-email.me> |
| In reply to | #169992 |
On 12/04/2023 07:44, james...@alumni.caltech.edu wrote: > On Tuesday, April 11, 2023 at 10:46:24 PM UTC-4, Tim Rentsch wrote: >> James Kuyper <james...@alumni.caltech.edu> writes: > ... >>> The fundamental problem is that, in C, a typedef is nothing more >>> than an synonym for a type. In any context where you use a typedef, >>> you could also use the explicit type itself. [...] >> >> Strictly speaking this assertion isn't quite right. Here is an >> example: >> >> typedef long Elongator( int ); >> >> extern const Elongator *elongator; > > I'm confused by that declaration - what is the 'const' supposed to mean in that context? Normally, I would read that declaration as saying that elongator is an identifier with external linkage, and that (*elongator)(5) returns a "const long", which makes no sense to me. > The "const" applies to the function type, not the return type of the function type. That, of course, makes even less sense (how could a function /not/ be const in C?) - and as noted it the result is undefined behaviour. But this is described in the semantics section (6.7.3p10), not the constraints section. >> There is no way to declare the pointer object 'elongator' without >> the use of a typedef. >> It may be worth noting that using a type qualifier directly on a >> function type is explicitly undefined behavior (but not a constraint >> violation). > > gcc shares my confusion about that declaration, referring to precisely that rule: > elongator.h:2:25: warning: ISO C forbids qualified function types [-Wpedantic] > 2 | extern const Elongator *elongator; > | ^~~~~~~~~ > That error message disappears if I move the 'const', so that it qualifies elongator, which makes a lot more sense to me: > extern Elongator * const elongator; > > and it accepts, as compatible, the following declaration of the same identifier: > > extern long(*const elongator)(int);
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-12 02:35 -0700 |
| Message-ID | <86edop30jx.fsf@linuxsc.com> |
| In reply to | #169992 |
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
> On Tuesday, April 11, 2023 at 10:46:24?PM UTC-4, Tim Rentsch wrote:
>
>> James Kuyper <james...@alumni.caltech.edu> writes:
>
> ...
>
>>> The fundamental problem is that, in C, a typedef is nothing more
>>> than an synonym for a type. In any context where you use a typedef,
>>> you could also use the explicit type itself. [...]
>>
>> Strictly speaking this assertion isn't quite right. Here is an
>> example:
>>
>> typedef long Elongator( int );
>>
>> extern const Elongator *elongator;
>
> I'm confused by that declaration - what is the 'const' supposed to
> mean in that context?
'Elongator' is a function type (that maps an int to a long).
'const Elongator' is a 'const' function type; in other words the
qualifier 'const' applies to the function type as a whole, not
just to the return type of the function.
> Normally, I would read that declaration as
> saying that elongator is an identifier with external linkage, and
> that (*elongator)(5) returns a "const long", which makes no sense to
> me.
If 'elongator' had been declared as follows:
const long (*elongator)( int );
that would give the result you describe. But in effect the
declaration of 'elongator' is the following (not legal C, but
meant to show what is taking place):
extern const (long (int)) *elongator;
so the 'const' modifies the function type itself as a whole, and
not just the return type of the function. The syntax used there
is not allowed in C, which is why a typedef is needed.
>> There is no way to declare the pointer object 'elongator' without
>> the use of a typedef.
>> It may be worth noting that using a type qualifier directly on a
>> function type is explicitly undefined behavior (but not a constraint
>> violation).
>
> gcc shares my confusion about that declaration, referring to
> precisely that rule:
> elongator.h:2:25: warning: ISO C forbids qualified
> function types [-Wpedantic]
> 2 | extern const Elongator *elongator;
> | ^~~~~~~~~
Actually I think gcc is not confused, but has (for some unknown
reason) chosen to give a confusing error message. In point of
fact ISO C does not forbid qualified function types, but simply
says they are undefined behavior.
> That error message disappears if I move the 'const', so that it
> qualifies elongator, which makes a lot more sense to me:
> extern Elongator * const elongator;
>
> and it accepts, as compatible, the following declaration of the
> same identifier:
>
> extern long(*const elongator)(int);
Yes, moving 'const' to the other side of the '*' changes the
meaning of the declaration, just like the two declarations
const int *pci;
int *const cpi;
have different meanings for the types of the respective items
being declared.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-13 22:26 -0700 |
| Message-ID | <51a1d6e2-ae7c-4ed2-ae2a-89e53c333840n@googlegroups.com> |
| In reply to | #169995 |
On Wednesday, April 12, 2023 at 5:36:03 AM UTC-4, Tim Rentsch wrote: > "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes: > > On Tuesday, April 11, 2023 at 10:46:24?PM UTC-4, Tim Rentsch wrote: > > > >> James Kuyper <james...@alumni.caltech.edu> writes: > > > > ... > > > >>> The fundamental problem is that, in C, a typedef is nothing more > >>> than an synonym for a type. In any context where you use a typedef, > >>> you could also use the explicit type itself. [...] > >> > >> Strictly speaking this assertion isn't quite right. Here is an > >> example: > >> > >> typedef long Elongator( int ); > >> > >> extern const Elongator *elongator; > > > > I'm confused by that declaration - what is the 'const' supposed to > > mean in that context? > 'Elongator' is a function type (that maps an int to a long). > > 'const Elongator' is a 'const' function type; in other words the > qualifier 'const' applies to the function type as a whole, not > just to the return type of the function. Which is even more meaningless. > > Normally, I would read that declaration as > > saying that elongator is an identifier with external linkage, and > > that (*elongator)(5) returns a "const long", which makes no sense to > > me. > If 'elongator' had been declared as follows: > > const long (*elongator)( int ); > > that would give the result you describe. But in effect the > declaration of 'elongator' is the following (not legal C, but > meant to show what is taking place): > > extern const (long (int)) *elongator; > > so the 'const' modifies the function type itself as a whole, and > not just the return type of the function. The syntax used there > is not allowed in C, which is why a typedef is needed. Sorry - I'd misunderstood what you were trying to get at, mainly because it's so patently absurd. True, the standard imposes no requirements when the behavior is undefined, so in particular it allows an implementation to interpret that declaration in that way. But so would any other construct with undefined behavior, such as division by 0. There's really no point in discussing code with undefined behavior beyond identifying that it does have undefined behavior. . > >> There is no way to declare the pointer object 'elongator' without > >> the use of a typedef. > >> It may be worth noting that using a type qualifier directly on a > >> function type is explicitly undefined behavior (but not a constraint > >> violation). > > > > gcc shares my confusion about that declaration, referring to > > precisely that rule: > > elongator.h:2:25: warning: ISO C forbids qualified > > function types [-Wpedantic] > > 2 | extern const Elongator *elongator; > > | ^~~~~~~~~ > Actually I think gcc is not confused, but has (for some unknown > reason) chosen to give a confusing error message. In point of > fact ISO C does not forbid qualified function types, but simply > says they are undefined behavior. You are correct - the C standard never forbids any code; it only specifies what can and cannot be expected of a conforming implementation if it processes such code. I agree, it would be better if the message had instead identified the declaration as having undefined behavior. However, that's not really relevant to my point - gcc correctly identified this code has having a serious problem, that it described the problem incorrectly is far less important. > > That error message disappears if I move the 'const', so that it > > qualifies elongator, which makes a lot more sense to me: > > extern Elongator * const elongator; > > > > and it accepts, as compatible, the following declaration of the > > same identifier: > > > > extern long(*const elongator)(int); > Yes, moving 'const' to the other side of the '*' changes the > meaning of the declaration, just like the two declarations > > const int *pci; > int *const cpi; > > have different meanings for the types of the respective items > being declared. Agreed - it's just that I thought that you had made a mistake, since the code you actually wrote had undefined behavior, so I assumed that you must have meant something else. That you would actually present such code as if it constituted a meaningful rebuttal to my claim was so ridiculous I hadn't considered it.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-08-09 06:12 -0700 |
| Message-ID | <86edkc9x71.fsf@linuxsc.com> |
| In reply to | #170006 |
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes: > On Wednesday, April 12, 2023 at 5:36:03?AM UTC-4, Tim Rentsch wrote: > >> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> writes: >> >>> On Tuesday, April 11, 2023 at 10:46:24?PM UTC-4, Tim Rentsch wrote: >>> >>>> James Kuyper <james...@alumni.caltech.edu> writes: >>> >>> ... >>> >>>>> The fundamental problem is that, in C, a typedef is nothing more >>>>> than an synonym for a type. In any context where you use a typedef, >>>>> you could also use the explicit type itself. [...] >>>> >>>> Strictly speaking this assertion isn't quite right. Here is an >>>> example: >>>> >>>> typedef long Elongator( int ); >>>> >>>> extern const Elongator *elongator; >>> >>> I'm confused by that declaration - what is the 'const' supposed to >>> mean in that context? >> >> 'Elongator' is a function type (that maps an int to a long). >> >> 'const Elongator' is a 'const' function type; in other words the >> qualifier 'const' applies to the function type as a whole, not >> just to the return type of the function. > > Which is even more meaningless. > >>> Normally, I would read that declaration as >>> saying that elongator is an identifier with external linkage, and >>> that (*elongator)(5) returns a "const long", which makes no sense to >>> me. >> >> If 'elongator' had been declared as follows: >> >> const long (*elongator)( int ); >> >> that would give the result you describe. But in effect the >> declaration of 'elongator' is the following (not legal C, but >> meant to show what is taking place): >> >> extern const (long (int)) *elongator; >> >> so the 'const' modifies the function type itself as a whole, and >> not just the return type of the function. The syntax used there >> is not allowed in C, which is why a typedef is needed. > > Sorry - I'd misunderstood what you were trying to get at, mainly because > it's so patently absurd. True, the standard imposes no requirements > when the behavior is undefined, so in particular it allows an > implementation to interpret that declaration in that way. But so would > any other construct with undefined behavior, such as division by 0. > There's really no point in discussing code with undefined behavior > beyond identifying that it does have undefined behavior. > . > >>>> There is no way to declare the pointer object 'elongator' without >>>> the use of a typedef. >>>> It may be worth noting that using a type qualifier directly on a >>>> function type is explicitly undefined behavior (but not a constraint >>>> violation). >>> >>> gcc shares my confusion about that declaration, referring to >>> precisely that rule: >>> elongator.h:2:25: warning: ISO C forbids qualified >>> function types [-Wpedantic] >>> 2 | extern const Elongator *elongator; >>> | ^~~~~~~~~ >> >> Actually I think gcc is not confused, but has (for some unknown >> reason) chosen to give a confusing error message. In point of >> fact ISO C does not forbid qualified function types, but simply >> says they are undefined behavior. > > You are correct - the C standard never forbids any code; it only > specifies what can and cannot be expected of a conforming > implementation if it processes such code. I agree, it would be > better if the message had instead identified the declaration as > having undefined behavior. However, that's not really relevant to > my point - gcc correctly identified this code has having a serious > problem, that it described the problem incorrectly is far less > important. > >>> That error message disappears if I move the 'const', so that it >>> qualifies elongator, which makes a lot more sense to me: >>> extern Elongator * const elongator; >>> >>> and it accepts, as compatible, the following declaration of the >>> same identifier: >>> >>> extern long(*const elongator)(int); >> >> Yes, moving 'const' to the other side of the '*' changes the >> meaning of the declaration, just like the two declarations >> >> const int *pci; >> int *const cpi; >> >> have different meanings for the types of the respective items >> being declared. > > Agreed - it's just that I thought that you had made a mistake, > since the code you actually wrote had undefined behavior, so I > assumed that you must have meant something else. That you would > actually present such code as if it constituted a meaningful > rebuttal to my claim was so ridiculous I hadn't considered it. I wasn't offering a rebuttal, simply correcting an incorrect statement. And my comments were meaningful, even if the meaning is not one you are interested in. Furthermore there is another, related case that does not have undefined behavior, and which I had hoped you would be perceptive enough to discover for yourself. But as usual you were more concerned with feeling like you were winning the argument than in discovering what is true.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 13:10 -0400 |
| Message-ID | <u11fu6$28f9a$1@dont-email.me> |
| In reply to | #169918 |
On 4/10/23 12:35, 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.
...
> 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.
Google translate does not do a good enough job of translating your
language into English, to allow discussion of such complicated issues.
If there's any forum using a language that you understand well enough, I
recommend using it.
I would never have considered the possibility that someone would use to
term "specialized function" to refer to such a thing. I still don't
understand the problem that you're complaining about. You can declare an
array of pointers to unspecialized functions as follows:
int unspec(int);
int (*unspec_array1[15])(int)={unspec};
An array of pointers to any particular specialized function type can be
declared equally easily:
char spec(double);
char (*spec_array1[15])(double)={spec};
I think you've left out some important details about what it is you want
to do, that prevents it from being done without a typedef.
Perhaps you're thinking of a heterogeneous array, one that contains
pointers to functions with two or more different types? The array itself
can have only one type, and using such an array often requires
conversion of a function pointer type to that type. A typedef makes that
much simpler, but is not necessary.
[toc] | [prev] | [next] | [standalone]
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 19:11 +0200 |
| Message-ID | <u11g0i$28g0k$1@dont-email.me> |
| In reply to | #169918 |
jak ha scritto: > 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. Also I would like to add that the concept of 'standard' that you follow with religious attention, IMO, is wrong because up to now it has not evolved but it has changed and this is insane. 'Standard' is a luxury for programming theorists. Thousands of companies use decades-old compilers so they don't have to change millions of lines of currently working code. The 'standard' should be followed by compiler makers and not compiler users. In the discussion of this thread we discuss a ternary operator which returns 0 in one rung and a pointer in the other. The standard says that 0 can be raised to a null pointer and it is true but tomorrow someone will change the 'standard' and this will no longer be true. Portability should also be considered over time and making sure both branches of the ternary operator return a pointer by adding a cast even if it's now unnecessary is not a bad thing because it could make the function *also* portable over time. Those who have coded for decades have seen these things and know they will happen again.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-04-10 17:22 +0000 |
| Message-ID | <rBXYL.1140524$t5W7.570138@fx13.iad> |
| In reply to | #169926 |
jak <nospam@please.ty> writes: >jak ha scritto: >> 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. > >Also I would like to add that the concept of 'standard' that you follow >with religious attention, IMO, is wrong because up to now it has not >evolved but it has changed and this is insane. 'Standard' is a luxury >for programming theorists. Thousands of companies use decades-old >compilers so they don't have to change millions of lines of currently >working code. The 'standard' should be followed by compiler makers and >not compiler users. In the discussion of this thread we discuss a >ternary operator which returns 0 in one rung and a pointer in the other. >The standard says that 0 can be raised to a null pointer and it is true Well, I've worked with systems where a null pointer was represented by the 32-bit value 0xc0eeeeee. So you can't make assumptions, just use NULL (or nullptr in C++).
[toc] | [prev] | [next] | [standalone]
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 19:33 +0200 |
| Message-ID | <u11h8h$28kf8$1@dont-email.me> |
| In reply to | #169927 |
Scott Lurndal ha scritto: > jak <nospam@please.ty> writes: >> jak ha scritto: >>> 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. >> >> Also I would like to add that the concept of 'standard' that you follow >> with religious attention, IMO, is wrong because up to now it has not >> evolved but it has changed and this is insane. 'Standard' is a luxury >> for programming theorists. Thousands of companies use decades-old >> compilers so they don't have to change millions of lines of currently >> working code. The 'standard' should be followed by compiler makers and >> not compiler users. In the discussion of this thread we discuss a >> ternary operator which returns 0 in one rung and a pointer in the other. >> The standard says that 0 can be raised to a null pointer and it is true > > Well, I've worked with systems where a null pointer was represented by > the 32-bit value 0xc0eeeeee. So you can't make assumptions, just use > NULL (or nullptr in C++). > hmm...so we agree, right?
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web