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 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 19:41 +0200 |
| Message-ID | <u11hp4$28nup$1@dont-email.me> |
| In reply to | #169930 |
jak ha scritto: > 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? > ...meaning that if the standard says that 0 if pointer will match a null pointer, the compiler on that system will take care of using the null pointer when it sees 0 as a pointer. Otherwise what is the standard for? The problem will be when the standard is changed again.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-04-10 18:13 +0000 |
| Message-ID | <QkYYL.1523103$8_id.1341805@fx09.iad> |
| In reply to | #169932 |
jak <nospam@please.ty> writes: >jak ha scritto: >>> 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? >> > >...meaning that if the standard says that 0 if pointer will match a null >pointer, the compiler on that system will take care of using the null >pointer when it sees 0 as a pointer. Otherwise what is the standard for? >The problem will be when the standard is changed again. In the real world, the address zero is a perfectly legal memory address; the C standard text simply requires that a null pointer constant cast to a pointer type should compare unequal to a pointer to any object or function and that any two null pointers, regardless of type, compare equal. Any other integer converted to a pointer type is implementation defined. While userland code generally doesn't map the first page of the virtual address space, kernel code does and may need to access via a pointer with null pointer constant value and is often written in C. Changing the definition of a null pointer constant would certainly break a lot of real-world code.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-10 11:30 -0700 |
| Message-ID | <87wn2jfv3x.fsf@nosuchdomain.example.com> |
| In reply to | #169932 |
jak <nospam@please.ty> writes:
> jak ha scritto:
>> 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?
>
> ...meaning that if the standard says that 0 if pointer will match a null
> pointer, the compiler on that system will take care of using the null
> pointer when it sees 0 as a pointer. Otherwise what is the standard for?
> The problem will be when the standard is changed again.
Again, the code being discussed was affected by the implementation's
definition of the NULL macro, not the run-time representation of
a null pointer value.
The constant 0 explicitly or implicitly converted to a pointer type
yields a null pointer value. Yes, the language standard guarantees
that. Your concern that a future edition of the standard might not
make that guarantee is, I believe, unfounded. Such a change would
quietly break large amounts of existing code, and the maintainers
of the standard carefully avoid making such changes.
(To be clear, the guarantee applies to "an integer constant expression
with the value 0", not to any arbitrary integer expression with the
value 0. `(void*)(2-2)` yields a null pointer value. Given `int n = 0;`
`(void*)n` is not guaranteed to yield a null pointer value.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-10 10:53 -0700 |
| Message-ID | <87cz4bhbdt.fsf@nosuchdomain.example.com> |
| In reply to | #169927 |
scott@slp53.sl.home (Scott Lurndal) writes:
> 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++).
The runtime representation of a null pointer value is not, I believe,
relevant to the current discussion. What's being discussed is the token
sequence that the NULL macro expands to.
It's legal for NULL to expand to, for example, `((void*)0)` or `0`, as
defined by the implementation. The latter is of type int, which of
course is not a pointer type. We were discussing a piece of code that,
if I recall correctly (I'm too lazy to go back and check) uses a null
pointer constant in a conditional (ternary) expression in such a way
that the expression is invalid (violates a constraint) if NULL expands
to 0.
Using either (void*)0 or (void*)NULL in the code would avoid that
problem.
(Incidentally, C23 will add a "nullptr" keyword, similar to what C++
has.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-11 11:25 -0400 |
| Message-ID | <u13u5k$2llhr$3@dont-email.me> |
| In reply to | #169927 |
On 4/10/23 13:22, Scott Lurndal wrote: ... > 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++). An integer constant expression with a value of 0 always qualifies as a null pointer constant. Null pointer constants always implicitly convert to null pointers of the appropriate type when used in pointer contexts. This has always been the case, regardless of how null pointers are represented internally.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-11 11:25 -0400 |
| Message-ID | <u13u4h$2llhr$2@dont-email.me> |
| In reply to | #169926 |
On 4/10/23 13:11, jak wrote: .. > 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. The standard is a contract between implementations and users. It was negotiated by the ISO committee, which includes implementors and users. You have no obligation to use that contract, and neither does an implementor. However, an implementation claiming to conform to a standard can be relied upon to handle code in a manner consistent with what the standard says, and can be held accountable if it fails to do so. Without the standard, you have nothing to rely on but the implementation's documentation. That may be sufficient for code that only needs to work properly on one particular implementation, but if you have any larger ambitions for your software, the standard is what you must rely upon to achieve them. > ... 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. A key point to consider is that the relevant guarantee is NOT for a value of 0, but for null pointer constants (NPCs). NULL expands to an NPC. The integer constant 0 also qualifies as one. The expression "free(p), 0" does not qualify as a null pointer constant, even though it's an expression of integer type and a value of 0. It is extremely unlikely that the committee will ever change those rules. You might, with equal plausibility, worry about he possibility that the short-circuit behavior of && and || operators might disappear. If you're worrying about changes on that level, C becomes essentially unusable - you should change to a different language that gives you less worries.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-10 11:13 -0700 |
| Message-ID | <878rezhahb.fsf@nosuchdomain.example.com> |
| In reply to | #169918 |
jak <nospam@please.ty> writes:
> 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.
What you need to understand is that we are honestly trying to understand
what you write, but you're not making it easy. I understand that it can
be difficult to write in a language that you don't know well; I
certainly couldn't do so in any language other than my native English.
If I tried to post in a technical form using Google Translate, the
results would be ... amusing. Your apparent efforts have been more
successful than mine would have been. You probably know English a lot
better than I know any language other than English.
There is no "newsgroup manager". Usenet is a cooperative distributed
system. There is no central authority.
Nobody is suggesting that non-native English speakers should not post
here.
I don't know where you got the phrase "specialized function". I'm
curious what phrase Google Translate generated that from (you haven't
mentioned what your native language is).
I'm telling you, as a native English speaker and as someone who has
extensively studied the C language and the various editions of its
standard, that the phrase "specialized function" doesn't make sense in
the way you're using it. There is nothing "specialized" about a
function whose parameter and return types are something other than int.
Older versions of C implicitly used type int in some contexts, but
that's no longer the case (integer constants within a certain range are
still of type int, but that's not relevant to function declarations).
You seem to have expected readers to know what you meant by "specialized
functions". That was an unrealistic expectation. At least one person
made the reasonable but incorrect assumption that you were talking about
C++, since "specialization" is a C++ concept.
You claimed above that:
it is no longer possible to declare a specialized function pointer
array without first declaring the typedef that defines the function
pointer and why.
You have been asked several times to explain that. You have refused to
do so. (You've also refused to explain what you mean by "stretch".)
I will ask you again: What do you mean by that? Can you give an example
in the form of a snippet of C code?
As far as I know, there is no context in C in which declaring an array
of function pointers requires the use of a typedef (though a typedef may
well make the declaration easier for human readers to understand). If
I'm mistaken, you should be able to show us such a declation that uses a
typedef that cannot be changed into equivalent valid C without a
typedef.
Please do so.
And please try to be less arrogant. It's surprising that someone who is
writing in English by using Google Translate would blame his readers
when they don't understand something rather than considering that the
translation might be faulty. We're trying to communicate. Please join
us in that effort.
--
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 20:27 +0200 |
| Message-ID | <u11kfb$2943f$1@dont-email.me> |
| In reply to | #169936 |
Keith Thompson ha scritto: > jak <nospam@please.ty> writes: >> 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. > > What you need to understand is that we are honestly trying to understand > what you write, but you're not making it easy. I understand that it can > be difficult to write in a language that you don't know well; I > certainly couldn't do so in any language other than my native English. > If I tried to post in a technical form using Google Translate, the > results would be ... amusing. Your apparent efforts have been more > successful than mine would have been. You probably know English a lot > better than I know any language other than English. > > There is no "newsgroup manager". Usenet is a cooperative distributed > system. There is no central authority. > > Nobody is suggesting that non-native English speakers should not post > here. > > I don't know where you got the phrase "specialized function". I'm > curious what phrase Google Translate generated that from (you haven't > mentioned what your native language is). > > I'm telling you, as a native English speaker and as someone who has > extensively studied the C language and the various editions of its > standard, that the phrase "specialized function" doesn't make sense in > the way you're using it. There is nothing "specialized" about a > function whose parameter and return types are something other than int. > Older versions of C implicitly used type int in some contexts, but > that's no longer the case (integer constants within a certain range are > still of type int, but that's not relevant to function declarations). > > You seem to have expected readers to know what you meant by "specialized > functions". That was an unrealistic expectation. At least one person > made the reasonable but incorrect assumption that you were talking about > C++, since "specialization" is a C++ concept. > > You claimed above that: > > it is no longer possible to declare a specialized function pointer > array without first declaring the typedef that defines the function > pointer and why. > > You have been asked several times to explain that. You have refused to > do so. (You've also refused to explain what you mean by "stretch".) > > I will ask you again: What do you mean by that? Can you give an example > in the form of a snippet of C code? > > As far as I know, there is no context in C in which declaring an array > of function pointers requires the use of a typedef (though a typedef may > well make the declaration easier for human readers to understand). If > I'm mistaken, you should be able to show us such a declation that uses a > typedef that cannot be changed into equivalent valid C without a > typedef. > > Please do so. > > And please try to be less arrogant. It's surprising that someone who is > writing in English by using Google Translate would blame his readers > when they don't understand something rather than considering that the > translation might be faulty. We're trying to communicate. Please join > us in that effort. > I was looking for the opposite of "implicit default function declaration" :^(
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-10 11:54 -0700 |
| Message-ID | <87o7nvfu0f.fsf@nosuchdomain.example.com> |
| In reply to | #169940 |
jak <nospam@please.ty> writes:
> Keith Thompson ha scritto:
[...]
>> I don't know where you got the phrase "specialized function". I'm
>> curious what phrase Google Translate generated that from (you haven't
>> mentioned what your native language is).
[...]
> I was looking for the opposite of "implicit default function
> declaration" :^(
OK, fine.
C dropped the "implicit int" rule in the 1999 standard. In C90, this:
foo(int arg);
would declare foo as a function returning int. In C99 and later it's a
syntax error. If I understand you correctly, there is no need for the
phrase "specialized function", since all functions are "specialized".
One more time: You made a specific claim about some construct requiring
a typedef. You seem to be carefully avoiding explaining what you mean.
Please either show us a construct that demonstrates the issue you're
talking about, or stop wasting our time. (And please also explain what
you meant by "stretch" elsewhere in this thread.)
You've said it's something you asked about here a few years ago, and you
were told that a typedef is required. If you don't remember the
details and you aren't able to find them, that's ok; just say so.
But you've given the impression, perhaps unintentionally, that you're
being deliberately evasive. You asked for an explanation, but you
haven't given us the information necessary to provide one.
--
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 21:01 +0200 |
| Message-ID | <u11mde$29eis$1@dont-email.me> |
| In reply to | #169945 |
Keith Thompson ha scritto: > jak <nospam@please.ty> writes: >> Keith Thompson ha scritto: > [...] >>> I don't know where you got the phrase "specialized function". I'm >>> curious what phrase Google Translate generated that from (you haven't >>> mentioned what your native language is). > [...] >> I was looking for the opposite of "implicit default function >> declaration" :^( > > OK, fine. > > C dropped the "implicit int" rule in the 1999 standard. In C90, this: > > foo(int arg); > > would declare foo as a function returning int. In C99 and later it's a > syntax error. If I understand you correctly, there is no need for the > phrase "specialized function", since all functions are "specialized". > > One more time: You made a specific claim about some construct requiring > a typedef. You seem to be carefully avoiding explaining what you mean. > > Please either show us a construct that demonstrates the issue you're > talking about, or stop wasting our time. (And please also explain what > you meant by "stretch" elsewhere in this thread.) > > You've said it's something you asked about here a few years ago, and you > were told that a typedef is required. If you don't remember the > details and you aren't able to find them, that's ok; just say so. > But you've given the impression, perhaps unintentionally, that you're > being deliberately evasive. You asked for an explanation, but you > haven't given us the information necessary to provide one. > You talk to me as if I forced you to answer me. Just ignore me.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-10 19:06 +0000 |
| Message-ID | <u11mmu$3us$1@reader2.panix.com> |
| In reply to | #169947 |
In article <u11mde$29eis$1@dont-email.me>, jak <nospam@please.ty> wrote: >Keith Thompson ha scritto: >>[snip] > >You talk to me as if I forced you to answer me. Just ignore me. Actually, he's been both incredibly patient and polite, and made a sincere effort to communicate with you respectfully. Perhaps the translation software you are using is not particularly good, but one cannot escape the impression that you are being deliberately rude. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 21:20 +0200 |
| Message-ID | <u11nhi$29ksm$1@dont-email.me> |
| In reply to | #169948 |
Dan Cross ha scritto: > In article <u11mde$29eis$1@dont-email.me>, jak <nospam@please.ty> wrote: >> Keith Thompson ha scritto: >>> [snip] >> >> You talk to me as if I forced you to answer me. Just ignore me. > > Actually, he's been both incredibly patient and polite, and made > a sincere effort to communicate with you respectfully. Perhaps > the translation software you are using is not particularly good, > but one cannot escape the impression that you are being > deliberately rude. > > - Dan C. > Again... You talk to one and another answers. You confuse me with the values: In my opinion, those who say "you don't understand" are arrogant, not those who say "I didn't explain myself well". In my opinion "waste our time" is offensive to me and to all of you. I also thought that many of you are in some whatsapp or telegram group chat to get along and make fun of people here.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2023-04-10 19:46 +0000 |
| Message-ID | <u11p30$ab4$1@reader2.panix.com> |
| In reply to | #169949 |
In article <u11nhi$29ksm$1@dont-email.me>, jak <nospam@please.ty> wrote: >Dan Cross ha scritto: >> In article <u11mde$29eis$1@dont-email.me>, jak <nospam@please.ty> wrote: >>> Keith Thompson ha scritto: >>>> [snip] >>> >>> You talk to me as if I forced you to answer me. Just ignore me. >> >> Actually, he's been both incredibly patient and polite, and made >> a sincere effort to communicate with you respectfully. Perhaps >> the translation software you are using is not particularly good, >> but one cannot escape the impression that you are being >> deliberately rude. > >Again... >You talk to one and another answers. You confuse me with the values: >In my opinion, those who say "you don't understand" are arrogant, not >those who say "I didn't explain myself well". >In my opinion "waste our time" is offensive to me and to all of you. >I also thought that many of you are in some whatsapp or telegram group >chat to get along and make fun of people here. *shrug* I don't understand why any of that is coming up in your response to me. I guess all I can say is, "Please don't feed the troll." - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-10 13:17 -0700 |
| Message-ID | <87cz4bfq5a.fsf@nosuchdomain.example.com> |
| In reply to | #169949 |
jak <nospam@please.ty> writes:
[...]
> I also thought that many of you are in some whatsapp or telegram group
> chat to get along and make fun of people here.
For the record, no, we don't do that. I very rarely communicate with
any of the other regulars of this newsgroup other than in the newsgroup
itself. There is no conspiracy to make fun of you or anyone else.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-04-10 13:16 -0700 |
| Message-ID | <87h6tnfq7v.fsf@nosuchdomain.example.com> |
| In reply to | #169947 |
jak <nospam@please.ty> writes:
> Keith Thompson ha scritto:
>> jak <nospam@please.ty> writes:
>>> Keith Thompson ha scritto:
>> [...]
>>>> I don't know where you got the phrase "specialized function". I'm
>>>> curious what phrase Google Translate generated that from (you haven't
>>>> mentioned what your native language is).
>> [...]
>>> I was looking for the opposite of "implicit default function
>>> declaration" :^(
>> OK, fine.
>> C dropped the "implicit int" rule in the 1999 standard. In C90,
>> this:
>> foo(int arg);
>> would declare foo as a function returning int. In C99 and later
>> it's a
>> syntax error. If I understand you correctly, there is no need for the
>> phrase "specialized function", since all functions are "specialized".
>> One more time: You made a specific claim about some construct
>> requiring
>> a typedef. You seem to be carefully avoiding explaining what you mean.
>> Please either show us a construct that demonstrates the issue you're
>> talking about, or stop wasting our time. (And please also explain what
>> you meant by "stretch" elsewhere in this thread.)
>> You've said it's something you asked about here a few years ago, and
>> you
>> were told that a typedef is required. If you don't remember the
>> details and you aren't able to find them, that's ok; just say so.
>> But you've given the impression, perhaps unintentionally, that you're
>> being deliberately evasive. You asked for an explanation, but you
>> haven't given us the information necessary to provide one.
>
> You talk to me as if I forced you to answer me. Just ignore me.
No, you did not force me to answer you.
You asked a specific question upthread:
Instead, explain to me why, after all the improvements introduced by the
standards, it is no longer possible to declare a specialized function
pointer array without first declaring the typedef that defines the
function pointer and why.
I chose to attempt to answer that question because I found it
interesting. To do so, I need information that you have not provided,
even after multiple requests that you do so.
I don't know why you refuse to elaborate, and I will not waste any more
of *my* time asking you to do so. I believe that you are mistaken on
the technical point, and that it *is* possible in modern C to do
whatever it was you were referring to without using typedef. If you
actually want an answer, you know what you need to do.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-10 14:54 -0400 |
| Message-ID | <u11m17$2907o$2@dont-email.me> |
| In reply to | #169940 |
On 4/10/23 14:27, jak wrote: > Keith Thompson ha scritto: ... >> I don't know where you got the phrase "specialized function". I'm >> curious what phrase Google Translate generated that from (you haven't >> mentioned what your native language is). >> >> I'm telling you, as a native English speaker and as someone who has >> extensively studied the C language and the various editions of its >> standard, that the phrase "specialized function" doesn't make sense in >> the way you're using it. There is nothing "specialized" about a >> function whose parameter and return types are something other than int. >> Older versions of C implicitly used type int in some contexts, but >> that's no longer the case (integer constants within a certain range are >> still of type int, but that's not relevant to function declarations). >> >> You seem to have expected readers to know what you meant by "specialized >> functions". That was an unrealistic expectation. At least one person >> made the reasonable but incorrect assumption that you were talking about >> C++, since "specialization" is a C++ concept. >> >> You claimed above that: >> >> it is no longer possible to declare a specialized function pointer >> array without first declaring the typedef that defines the function >> pointer and why. >> >> You have been asked several times to explain that. You have refused to >> do so. (You've also refused to explain what you mean by "stretch".) ... > I was looking for the opposite of "implicit default function > declaration" :^( Implicit function declarations disappeared in C99. There no longer is anything to be the opposite of. Code showing how a typedef is necessary in order to declare an array of function pointers would help clarify what you're talking about.
[toc] | [prev] | [next] | [standalone]
| From | jak <nospam@please.ty> |
|---|---|
| Date | 2023-04-10 20:44 +0200 |
| Message-ID | <u11lem$2996k$1@dont-email.me> |
| In reply to | #169936 |
Keith Thompson ha scritto: > jak <nospam@please.ty> writes: >> 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. > > What you need to understand is that we are honestly trying to understand > what you write, but you're not making it easy. I understand that it can > be difficult to write in a language that you don't know well; I > certainly couldn't do so in any language other than my native English. > If I tried to post in a technical form using Google Translate, the > results would be ... amusing. Your apparent efforts have been more > successful than mine would have been. You probably know English a lot > better than I know any language other than English. > > There is no "newsgroup manager". Usenet is a cooperative distributed > system. There is no central authority. > > Nobody is suggesting that non-native English speakers should not post > here. > > I don't know where you got the phrase "specialized function". I'm > curious what phrase Google Translate generated that from (you haven't > mentioned what your native language is). > > I'm telling you, as a native English speaker and as someone who has > extensively studied the C language and the various editions of its > standard, that the phrase "specialized function" doesn't make sense in > the way you're using it. There is nothing "specialized" about a > function whose parameter and return types are something other than int. > Older versions of C implicitly used type int in some contexts, but > that's no longer the case (integer constants within a certain range are > still of type int, but that's not relevant to function declarations). > > You seem to have expected readers to know what you meant by "specialized > functions". That was an unrealistic expectation. At least one person > made the reasonable but incorrect assumption that you were talking about > C++, since "specialization" is a C++ concept. > > You claimed above that: > > it is no longer possible to declare a specialized function pointer > array without first declaring the typedef that defines the function > pointer and why. > > You have been asked several times to explain that. You have refused to > do so. (You've also refused to explain what you mean by "stretch".) > > I will ask you again: What do you mean by that? Can you give an example > in the form of a snippet of C code? > > As far as I know, there is no context in C in which declaring an array > of function pointers requires the use of a typedef (though a typedef may > well make the declaration easier for human readers to understand). If > I'm mistaken, you should be able to show us such a declation that uses a > typedef that cannot be changed into equivalent valid C without a > typedef. > > Please do so. > > And please try to be less arrogant. It's surprising that someone who is > writing in English by using Google Translate would blame his readers > when they don't understand something rather than considering that the > translation might be faulty. We're trying to communicate. Please join > us in that effort. > It's not my intention to be arrogant but here it's like sticking a stick in a wasp's nest. I've never been able to exchange more than one comment with the same person who immediately makes a new person aware and, honestly, I find the way many people respond particularly aggressive and often it seems like I'm talking to lawyers rather than programmers. I Already stopped posting here many years ago for the same reason even though I've always followed. I tried again but nothing has changed and I'll go back to just reading. However, I would like you to notice that there are few new arrivals and perhaps the cause is this climate.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-04-11 05:01 -0700 |
| Message-ID | <86ttxm39xe.fsf@linuxsc.com> |
| In reply to | #169943 |
jak <nospam@please.ty> writes: [...] > It's not my intention to be arrogant but here it's like sticking a > stick in a wasp's nest. I've never been able to exchange more than > one comment with the same person who immediately makes a new person > aware and, honestly, I find the way many people respond particularly > aggressive and often it seems like I'm talking to lawyers rather > than programmers. I Already stopped posting here many years ago for > the same reason even though I've always followed. I tried again but > nothing has changed and I'll go back to just reading. However, I > would like you to notice that there are few new arrivals and perhaps > the cause is this climate. For what it's worth I think the people who write these responses are actually trying to be helpful. I think sometimes they don't understand that what they think will be helpful doesn't really help the person being responded to (such as yourself). Incidentally, I am curious. Do you mind saying what your native language is?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-04-11 11:27 +0200 |
| Message-ID | <u1395d$2ivmc$1@dont-email.me> |
| In reply to | #169918 |
On 10/04/2023 18: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. >> 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. In order to have any hope of communicating properly, it is important to use correct terminology. If we all use vague words based on what they sometimes mean in English, we'll never get anywhere - all our time will be spent asking each other what we mean. This is a C language group. The source of all terms is the C standards. These are easily found online, for all the different versions of C (technically only the draft versions are freely available, but these are fine for almost all use-cases). The standards documents are not easy reading even for native English speakers, but you must at least appreciate that the terms we all use here come from those documents. We realise that you are not a native English speaker - that applies to many of the regular posters here, who come from all around the world. I believe some find that Google translate can help a bit, but it cannot handle technical programming terms and expressions. It may be unfair, but if you want to be a serious programmer, learning more English is unavoidable. (That does /not/ mean we expect perfect English!) Along with that, giving code examples showing what you mean can be very helpful. I believe that what you are talking about is the distinction between "function prototype declarations" and "non-prototype function declarations" (also sometimes known as "K&R function declarations"). In ancient C, described in excellent but the long outdated first edition of the book "The C Programming Language", functions were assumed to take a single "int" parameter and return an "int", unless declared otherwise. This type of function declaration was replaced in C90 by "prototypes" specifying the return type and parameter type. Although function prototype declarations are better in virtually every way, the old style remained supported for backwards compatibility. Only now, in C23, has support for them been removed entirely. The only real use I have seen for non-prototype function declarations is a "general" function pointer in arrays containing mixed function pointer types. Such use is no longer allowed in C23. Is that what you are concerned about? Normally a better choice of general function pointer is "void foo(void)", rather than "int foo()". (In C23, the later would now mean "int foo(void)".)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-04-11 11:41 -0400 |
| Message-ID | <u13v3f$2llhr$6@dont-email.me> |
| In reply to | #169961 |
On 4/11/23 05:27, David Brown wrote:
...> declarations" (also sometimes known as "K&R function
declarations"). In
> ancient C, described in excellent but the long outdated first edition of
> the book "The C Programming Language", functions were assumed to take a
> single "int" parameter and return an "int", unless declared otherwise.
"If the expression that precedes the parenthesized argument list in
a function call consists solely of an identifier, and if no
declaration is visible for this identifier, the identifier is
implicitly declared exactly as if, in the innermost block containing
the function call, the declaration
extern int identifier();
appeared."
(C90 6.3.2.2)
Note that the function is implicitly declared using the K&R syntax, not
as a function prototype. That syntax declares it as taking an
unspecified number of arguments of unspecified types, not as taking a
single "int" argument.
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web