Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #169806 > unrolled thread

"Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan

Back to article view | Back to comp.lang.c

Contents

  "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Lynn McGuire <lynnmcguire5@gmail.com> - 2023-04-03 18:20 -0500
    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Jim Kelly <invalid@invalid.net> - 2023-04-04 04:00 +0100
      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Lynn McGuire <lynnmcguire5@gmail.com> - 2023-04-04 14:49 -0500
    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Rene Kita <mail@rkta.de> - 2023-04-04 09:56 +0000
      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan gazelle@shell.xmission.com (Kenny McCormack) - 2023-04-04 12:20 +0000
        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan scott@slp53.sl.home (Scott Lurndal) - 2023-04-04 13:50 +0000
        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Rene Kita <mail@rkta.de> - 2023-04-05 08:49 +0000
          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan gazelle@shell.xmission.com (Kenny McCormack) - 2023-04-05 09:23 +0000
            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-05 13:07 +0000
              (realloc) Angels and pins (Was: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan) gazelle@shell.xmission.com (Kenny McCormack) - 2023-04-05 14:12 +0000
                Re: (realloc) Angels and pins (Was: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan) cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-05 17:09 +0000
              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 20:16 +0100
                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-05 21:03 +0000
                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-11 04:05 -0700
            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-05 17:05 +0200
    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-04 11:30 +0000
      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Lynn McGuire <lynnmcguire5@gmail.com> - 2023-04-04 14:51 -0500
        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 01:10 +0100
          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-05 00:42 +0000
            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Opus <ifonly@youknew.org> - 2023-04-05 02:55 +0200
            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 03:01 +0100
              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-05 13:29 +0000
                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-05 17:15 +0200
                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan scott@slp53.sl.home (Scott Lurndal) - 2023-04-05 15:27 +0000
                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-05 10:40 -0700
                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-05 18:55 +0000
                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-06 00:37 +0200
                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-05 17:40 -0700
                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-12 05:46 -0700
                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-06 12:34 +0000
                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan John Forkosh <forkosh@panix.com> - 2023-04-06 05:42 +0000
                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-07 12:16 +0200
                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Kaz Kylheku <864-117-4973@kylheku.com> - 2023-04-07 11:38 +0000
                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-09 07:23 -0700
                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-09 17:04 +0200
                          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-09 19:34 +0000
                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 09:45 +0200
                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 14:52 +0000
                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 17:29 +0200
                                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 11:48 -0400
                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 18:10 +0200
                                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 12:19 -0400
                                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-04-10 09:55 -0700
                                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 10:41 -0700
                                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 11:22 -0700
                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Bart <bc@freeuk.com> - 2023-04-10 21:22 +0100
                                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 14:22 -0700
                                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-10 22:36 +0100
                                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Bart <bc@freeuk.com> - 2023-04-11 00:11 +0100
                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 11:34 -0400
                                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 15:37 +0000
                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 11:57 -0400
                                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 17:26 +0000
                                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 14:27 -0400
                                          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 18:45 +0000
                                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-11 04:50 -0700
                                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Spiros Bousbouras <spibou@gmail.com> - 2023-04-10 15:58 +0000
                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 12:08 -0400
                                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 17:27 +0000
                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-11 04:47 -0700
                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 10:26 -0400
                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 14:51 +0000
                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 11:20 -0400
                                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 15:35 +0000
                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 12:04 -0400
                                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 17:34 +0000
                                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 11:24 -0400
                                          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-04-11 16:17 +0000
                                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Bart <bc@freeuk.com> - 2023-04-11 18:13 +0100
                                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-04-11 17:58 +0000
                          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-09 12:41 -0700
                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 09:31 +0200
                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 09:46 -0400
                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 16:29 +0200
                                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 16:37 +0200
                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 11:26 -0400
                                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 17:43 +0200
                                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 12:19 -0400
                                          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 18:35 +0200
                                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Öö Tiib <ootiib@hot.ee> - 2023-04-10 10:02 -0700
                                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 20:14 +0200
                                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 11:34 -0700
                                                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ike Naar <ike@sdf.org> - 2023-04-10 21:47 +0000
                                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-10 23:04 +0100
                                                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Öö Tiib <ootiib@hot.ee> - 2023-04-11 01:08 -0700
                                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 11:26 -0400
                                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Öö Tiib <ootiib@hot.ee> - 2023-04-11 02:43 -0700
                                                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-11 15:14 +0200
                                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 11:35 -0400
                                                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 12:09 -0400
                                                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-11 19:46 -0700
                                                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-04-11 22:44 -0700
                                                          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-12 09:46 +0200
                                                          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-12 02:35 -0700
                                                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-04-13 22:26 -0700
                                                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-09 06:12 -0700
                                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 13:10 -0400
                                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 19:11 +0200
                                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan scott@slp53.sl.home (Scott Lurndal) - 2023-04-10 17:22 +0000
                                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 19:33 +0200
                                                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 19:41 +0200
                                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan scott@slp53.sl.home (Scott Lurndal) - 2023-04-10 18:13 +0000
                                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 11:30 -0700
                                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 10:53 -0700
                                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 11:25 -0400
                                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 11:25 -0400
                                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 11:13 -0700
                                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 20:27 +0200
                                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 11:54 -0700
                                                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 21:01 +0200
                                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 19:06 +0000
                                                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 21:20 +0200
                                                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-10 19:46 +0000
                                                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 13:17 -0700
                                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 13:16 -0700
                                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 14:54 -0400
                                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 20:44 +0200
                                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-11 05:01 -0700
                                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-11 11:27 +0200
                                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-11 11:41 -0400
                                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-11 12:50 -0700
                                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan David Brown <david.brown@hesbynett.no> - 2023-04-12 09:51 +0200
                                                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-12 09:12 -0700
                                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 09:58 -0700
                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 09:54 -0700
                                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-04-10 11:21 -0400
                                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan jak <nospam@please.ty> - 2023-04-10 17:58 +0200
                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-11 05:31 -0700
                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-10 09:50 -0700
                          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-09 12:44 -0700
                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-09 20:19 +0100
                          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-09 12:55 -0700
                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-09 21:44 +0100
                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-09 19:53 -0700
                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 20:33 +0100
              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-16 07:18 -0700
            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-05 12:53 -0700
              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-06 12:30 +0000
                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-08 18:46 -0700
                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-09 19:35 +0000
                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 09:07 -0700
                      Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-07-20 22:35 +0000
                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan vallor <vallor@cultnix.org> - 2023-07-22 12:54 +0000
                          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-22 22:04 +0100
                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan vallor <vallor@cultnix.org> - 2023-07-24 10:44 +0000
                          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-22 16:28 -0700
                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan vallor <vallor@cultnix.org> - 2023-07-24 08:38 +0000
                          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-07-24 18:55 +0000
                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan om@iki.fi (Otto J. Makela) - 2023-07-26 11:30 +0300
                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-26 19:28 +0000
                        Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-07 13:08 -0700
                          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-08-15 12:01 +0000
                            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 15:49 -0700
                              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-08-28 23:42 +0000
                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Spiros Bousbouras <spibou@gmail.com> - 2023-08-29 00:51 +0000
                                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-08-29 01:20 +0000
                                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-05 18:24 -0700
            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Phil Carmody <pc+usenet@asdf.org> - 2023-04-17 09:25 +0300
              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-18 11:56 +0000
              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-05-02 07:12 -0700
                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Phil Carmody <pc+usenet@asdf.org> - 2023-05-07 09:37 +0300
                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 09:09 -0700
          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Lowell Gilbert <lgusenet@be-well.ilk.org> - 2023-04-04 21:19 -0400
            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 03:36 +0100
              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Opus <ifonly@youknew.org> - 2023-04-05 05:10 +0200
                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Richard Damon <Richard@Damon-Family.org> - 2023-04-05 07:54 -0400
                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Opus <ifonly@youknew.org> - 2023-04-05 21:31 +0200
                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-16 06:12 -0700
              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-05 09:20 -0700
          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-05 10:07 -0700
            Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-05 20:23 +0100
              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-05 21:20 -0700
                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-06 17:03 +0100
                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan cross@spitfire.i.gajendra.net (Dan Cross) - 2023-04-06 20:34 +0000
                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-07 00:25 +0100
                    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-19 08:56 -0700
                  Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-06 19:40 -0700
              Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-04-08 02:37 -0700
                Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-04-08 21:04 +0100
          Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-05-02 06:22 -0700
    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Bonita Montero <Bonita.Montero@gmail.com> - 2023-08-09 16:00 +0200
    Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Michael S <already5chosen@yahoo.com> - 2023-08-29 04:45 -0700

Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10  Next page →

#169915

James Kuyper ha scritto:
> On 4/10/23 11:29, jak wrote:
> ...
>> char val;
>> int *pi;
>>
>> pi = (int *)&val;
>>
>> because if you assigned a value to *pi you would be using unallocated
>> memory
> 
> The problem with that code has nothing to do with the problem Tim was
> talking about, nor does it have anything to do with unallocated memory.
> It has undefined behavior if &val points to a memory location that is
> not correctly aligned to hold an 'int' (6.3.2.3p7). More importantly,
> even if it is correctly aligned, the value stored in pi cannot be used
> to access an 'int', because it doesn't point at an int object.
> 
>> ... and if you really want to do that you need a left cast:
>>
>> ((char *)pi) = &val;
> 
> The left hand side of an assignment is required to be a modifiable
> lvalue (6.5.16p2). The result of a pointer conversion is not an lvalue.
> 

hmmm... in my point of view declaring a variable corresponds to
allocating memory while using malloc means allocating memory
dynamically. For me it is not easy to express concepts in your language
and in addition you continue to take me back on the quibbles. Maybe we
can talk again when I improve my English and you're less picky.

[toc] | [prev] | [next] | [standalone]

#169917

On 4/10/23 12:10, jak wrote:
> James Kuyper ha scritto:
>> On 4/10/23 11:29, jak wrote:
>> ...
>>> char val;
>>> int *pi;
>>>
>>> pi = (int *)&val;
>>>
>>> because if you assigned a value to *pi you would be using unallocated
>>> memory
>>
>> The problem with that code has nothing to do with the problem Tim was
>> talking about, nor does it have anything to do with unallocated memory.
>> It has undefined behavior if &val points to a memory location that is
>> not correctly aligned to hold an 'int' (6.3.2.3p7). More importantly,
>> even if it is correctly aligned, the value stored in pi cannot be used
>> to access an 'int', because it doesn't point at an int object.
>>
>>> ... and if you really want to do that you need a left cast:
>>>
>>> ((char *)pi) = &val;
>>
>> The left hand side of an assignment is required to be a modifiable
>> lvalue (6.5.16p2). The result of a pointer conversion is not an lvalue.
>>
>
> hmmm... in my point of view declaring a variable corresponds to
> allocating memory while using malloc means allocating memory
> dynamically. For me it is not easy to express concepts in your language
> and in addition you continue to take me back on the quibbles. Maybe we
> can talk again when I improve my English and you're less picky.

Declaring 'val' allocates memory to store a char. Declaring pi allocates
memory to store a pointer to an int. (int*)val is an expression that
could have undefined behavior, for reasons that have nothing to do with
unallocated memory. If it doesn't have undefined behavior, the result of
that conversion can safely be stored in the memory allocated for pi. It
cannot, however, be used to access an int object, because it doesn't
point at any such object.

[toc] | [prev] | [next] | [standalone]

#169922

On Monday, 10 April 2023 at 17:10:19 UTC+1, jak wrote:
> James Kuyper ha scritto:
> > On 4/10/23 11:29, jak wrote: 
> > ... 
> >> char val; 
> >> int *pi; 
> >> 
> >> pi = (int *)&val; 
> >> 
> >> because if you assigned a value to *pi you would be using unallocated 
> >> memory 
> > 
> > The problem with that code has nothing to do with the problem Tim was 
> > talking about, nor does it have anything to do with unallocated memory. 
> > It has undefined behavior if &val points to a memory location that is 
> > not correctly aligned to hold an 'int' (6.3.2.3p7). More importantly, 
> > even if it is correctly aligned, the value stored in pi cannot be used 
> > to access an 'int', because it doesn't point at an int object. 
> > 
> >> ... and if you really want to do that you need a left cast: 
> >> 
> >> ((char *)pi) = &val; 
> > 
> > The left hand side of an assignment is required to be a modifiable 
> > lvalue (6.5.16p2). The result of a pointer conversion is not an lvalue. 
> >
> hmmm... in my point of view declaring a variable corresponds to 
> allocating memory while using malloc means allocating memory 
> dynamically. For me it is not easy to express concepts in your language 
> and in addition you continue to take me back on the quibbles. Maybe we 
> can talk again when I improve my English and you're less picky.
>
In a sense that is right. But generally the term "allocating" isn't used for
variables created on the stack, unless maybe for large arrays.
The reason is that the stack works by magic. Within the confines of the 
C language, there is no way to express that the stack might fail, though
of course it must do so eventually if allowed to get arbitrarily deep.
 

[toc] | [prev] | [next] | [standalone]

#169933

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 10 April 2023 at 17:10:19 UTC+1, jak wrote:
>> James Kuyper ha scritto:
>> > On 4/10/23 11:29, jak wrote: 
>> > ... 
>> >> char val; 
>> >> int *pi; 
>> >> 
>> >> pi = (int *)&val; 
>> >> 
>> >> because if you assigned a value to *pi you would be using unallocated 
>> >> memory 
>> > 
>> > The problem with that code has nothing to do with the problem Tim was 
>> > talking about, nor does it have anything to do with unallocated memory. 
>> > It has undefined behavior if &val points to a memory location that is 
>> > not correctly aligned to hold an 'int' (6.3.2.3p7). More importantly, 
>> > even if it is correctly aligned, the value stored in pi cannot be used 
>> > to access an 'int', because it doesn't point at an int object. 
>> > 
>> >> ... and if you really want to do that you need a left cast: 
>> >> 
>> >> ((char *)pi) = &val; 
>> > 
>> > The left hand side of an assignment is required to be a modifiable 
>> > lvalue (6.5.16p2). The result of a pointer conversion is not an lvalue. 
>> >
>> hmmm... in my point of view declaring a variable corresponds to 
>> allocating memory while using malloc means allocating memory 
>> dynamically. For me it is not easy to express concepts in your language 
>> and in addition you continue to take me back on the quibbles. Maybe we 
>> can talk again when I improve my English and you're less picky.
>>
> In a sense that is right. But generally the term "allocating" isn't used for
> variables created on the stack, unless maybe for large arrays.
> The reason is that the stack works by magic. Within the confines of the 
> C language, there is no way to express that the stack might fail, though
> of course it must do so eventually if allowed to get arbitrarily deep.

In fact the word "allocate" and various forms of it *are* commonly used
by the standard to refer to "variables created on the stack" (more
technically, objects with automatic storage duration).

One example (which happens to be one of the earliest references in the
text of the standard):

    An *array type* describes a contiguously allocated nonempty set of
    objects with a particular member object type, called the *element
    type*.

This refers to array objects in general, not just heap-allocated array
objects.

The fact that one of the four storage durations is called "allocated",
while the word "allocate" is used to refer to reserving memory in other
contexts, is potentially confusing, but I haven't found it to be much of
a problem.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#169938

jak <nospam@please.ty> writes:
> Dan Cross ha scritto:
>> In article <u10erc$23rhg$1@dont-email.me>, jak  <nospam@please.ty> wrote:
>>> Dan Cross ha scritto:
>>>> In article <u0uk66$1or41$1@dont-email.me>, jak  <nospam@please.ty> wrote:
>>>>> Tim Rentsch ha scritto:
>>>>>> [snip]
>>>>>> I agree with the general tone of this suggestion.  Unfortunately
>>>>>> however the particular code suggested might not compile (because
>>>>>> the macro NULL might be #define'd to be 0, which can result in an
>>>>>> error).  Writing the function this way:
>>>>>>
>>>>>>        void *
>>>>>>        realloc0( void *p, size_t size ){
>>>>>>            return  size == 0  ? free( p ), p = 0  : realloc( p, size );
>>>>>>        }
>>>>>>
>>>>>> is an easy way to avoid that implementation dependency.
>>>>>
>>>>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
>>>>> on autocast and use an explicit one instead.
>>>>
>>>> What "dependency" would that avoid, other than a dependency on
>>>> the C standard?
>>>
>>> Why are you asking me this?
>> Because you are the one who suggested there is some kind of
>> "dependency" in Tim's code?
>> 
>>> Perhaps you consider being portability if
>>> you move the source code to another machine with the same operating
>>> system, same compiler, same compiler version.
>> This has nothing to do with that.  Tim's code was correct and
>> portable.
>> 	- Dan C.
>> 
> Correct for sure but you and I don't have the same concept of portable.
> There are compilers that don't accept things like this:
>
> char val;
> int *pi;
>
> pi = (int *)&val;
>
> because if you assigned a value to *pi you would be using unallocated
> memory and if you really want to do that you need a left cast:
>
> ((char *)pi) = &val;

Was that line of code intended to be in some hypothetical C-like
language, using a feature that you wish C provided?  If that was the
point you were trying to make, it wasn't clear.

That line of code;

    ((char *)pi) = &val;

is not valid C.  (It's also not valid C++.)  When I attempt to compile
it, I get:

    error: lvalue required as left operand of assignment

As for the original code:

    char val;
    int *pi;
    
    pi = (int *)&val;

That doesn't violate any constraint or syntax rule, but it's likely to
have undefined behavior depending on the characteristics of the
implementation.  A compiler *could* reject that code, but I'd be
surprised to see one that actually did so.  A warning might be
appropriate, but most C compilers take a pointer cast as an assertion by
the programmer that "I know what I'm doing".  Do you know of a compiler
that doesn't accept it?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#169953

On 10/04/2023 19:22, Keith Thompson wrote:
 > jak <nospam@please.ty> writes:
 >> There are compilers that don't accept things like this:
 >>
 >> char val;
 >> int *pi;
 >>
 >> pi = (int *)&val;
 >>
 >> because if you assigned a value to *pi you would be using unallocated
 >> memory and if you really want to do that you need a left cast:
 >>
 >> ((char *)pi) = &val;
 >
 > Was that line of code intended to be in some hypothetical C-like
 > language, using a feature that you wish C provided?  If that was the
 > point you were trying to make, it wasn't clear.
 >
 > That line of code;
 >
 >      ((char *)pi) = &val;
 >
 > is not valid C.  (It's also not valid C++.)  When I attempt to compile
 > it, I get:
 >
 >      error: lvalue required as left operand of assignment
I can't see much wrong with it. It works fine with tcc and (my) bcc 
compilers. It assigns an address to pointer. The cast is needed because 
otherwise there's a type mismatch (assigning char* address to a int* 
pointer).

I'm surprised that gcc reports it as an error rather than a warning as 
it does with nearly everything else, for example:

     int *pi;
     char *pc;
     pi = pc;

gives a warning.

[toc] | [prev] | [next] | [standalone]

#169954

Bart <bc@freeuk.com> writes:
> On 10/04/2023 19:22, Keith Thompson wrote:
>> jak <nospam@please.ty> writes:
>>> There are compilers that don't accept things like this:
>>>
>>> char val;
>>> int *pi;
>>>
>>> pi = (int *)&val;
>>>
>>> because if you assigned a value to *pi you would be using unallocated
>>> memory and if you really want to do that you need a left cast:
>>>
>>> ((char *)pi) = &val;
>>
>> Was that line of code intended to be in some hypothetical C-like
>> language, using a feature that you wish C provided?  If that was the
>> point you were trying to make, it wasn't clear.
>>
>> That line of code;
>>
>>      ((char *)pi) = &val;
>>
>> is not valid C.  (It's also not valid C++.)  When I attempt to compile
>> it, I get:
>>
>>      error: lvalue required as left operand of assignment
> I can't see much wrong with it. It works fine with tcc and (my) bcc
> compilers. It assigns an address to pointer. The cast is needed
> because otherwise there's a type mismatch (assigning char* address to
> a int* pointer).
>
> I'm surprised that gcc reports it as an error rather than a warning as
> it does with nearly everything else, for example:
>
>     int *pi;
>     char *pc;
>     pi = pc;
>
> gives a warning.

I'm not sure why you're surprised.

A cast operation takes an expression that specifies a *value* and yields
a *value* of the specified type.  It does not yield a reference to an
object (in other words, it's not an lvalue).

Similarly, this:

    int n;
    n + 2 = 4;

does not set n to 2; it's a constraint violation, because n + 2 is not
an lvalue.

gcc does, in its default mode, allow a lot of implicit pointer
conversions that are not permitted by the language, perhaps because they
were usually permitted by pre-ANSI C implementations and the gcc
maintainers never saw a good time to break old code.  I don't think
most historical C compilers ever treated cast expressions as lvalues,
so that consideration doesn't apply in this case.

You're right that tcc (I have version 0.9.27) accepts the assignment
without complaint.  I find that surprising.

Certainly C *could* have been defined so that a cast expression can be
an lvalue (presumably only if the operand is an lvalue).  It just wasn't
defined that way.  A cast yields a converted value, not a converted
object.

(To be clear, the standard's syntactic category "cast-expression"
includes expressions that have no cast operators.  I'm talking about an
expression with a cast operator at the top level.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#169955

Bart <bc@freeuk.com> writes:

> On 10/04/2023 19:22, Keith Thompson wrote:

>> That line of code;
>>
>>      ((char *)pi) = &val;
>>
>> is not valid C.  (It's also not valid C++.)  When I attempt to compile
>> it, I get:
>>
>>      error: lvalue required as left operand of assignment
>
> I can't see much wrong with it.

It violates a constraint.  A cast expression does not yield an l-value.
Obviously, C could have been designed so that assigning to a cast
expression meant something (what, exactly I don't know), but it was not.
In C, you convert the value being assigned.

> It works fine with tcc

That's a shame.  A diagnostic is required since tcc claims to be conforming.

> and (my) bcc compilers.  It assigns an address to pointer. The cast is
> needed because otherwise there's a type mismatch (assigning char*
> address to a int* pointer).

A cast on the value makes that obvious.  What does a cast on the lvalue
do as there is nothing to convert?  How does bcc treat

  double d;
  (int)d = 42;

?  Does it just treat the cast as an instruction to be quiet while
generating code to move sizeof 42 bytes to d's location?

tcc, by the way, correctly generates a diagnostic (in fact an error):
"error: lvalue expected" for that line.  I don't know why it doesn't
for the pointer case.

> I'm surprised that gcc reports it as an error rather than a warning as it
> does with nearly everything else,

It's suggests the author of the code is deeply baffled by the language
so I would agree that it's serious flaw meriting an error message.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#169959

On 10/04/2023 22:36, Ben Bacarisse wrote:
 > Bart <bc@freeuk.com> writes:
 >
 >> On 10/04/2023 19:22, Keith Thompson wrote:
 >
 >>> That line of code;
 >>>
 >>>       ((char *)pi) = &val;
 >>>
 >>> is not valid C.  (It's also not valid C++.)  When I attempt to compile
 >>> it, I get:
 >>>
 >>>       error: lvalue required as left operand of assignment
 >>
 >> I can't see much wrong with it.
 >
 > It violates a constraint.  A cast expression does not yield an l-value.
 > Obviously, C could have been designed so that assigning to a cast
 > expression meant something (what, exactly I don't know), but it was not.
 > In C, you convert the value being assigned.

Whatever the type of the LHS of an assignment, it would override that 
with the cast type.

 >  How does bcc treat
 >
 >    double d;
 >    (int)d = 42;


It doesn't report it but it doesn't work that well either. I think it 
would just be simpler to not allow it.

My lvalue-checking logic needs to allow the use of & in front of an 
lvalue expression, but it also needs to be stricter when it is the LHS 
of an assignment or anything that modifies memory. I've now made that 
change.


 > ?  Does it just treat the cast as an instruction to be quiet while
 > generating code to move sizeof 42 bytes to d's location?

For the (int)d example, type-punning would be more more appropriate to 
get that behaviour. There are no type-punning casts in C, but it can be 
emulated with:

     *(int*)&d = 42;

 >
 > tcc, by the way, correctly generates a diagnostic (in fact an error):
 > "error: lvalue expected" for that line.  I don't know why it doesn't
 > for the pointer case.

The original example perhaps works in tcc, because the cast in that case 
is a no-op, not requiring anything to be converted except changing the type.

[toc] | [prev] | [next] | [standalone]

#169905

On 4/10/23 10:52, Dan Cross wrote:
> In article <u10erc$23rhg$1@dont-email.me>, jak  <nospam@please.ty> wrote:
>> Dan Cross ha scritto:
>>> In article <u0uk66$1or41$1@dont-email.me>, jak  <nospam@please.ty> wrote:
>>>> Tim Rentsch ha scritto:
>>>>> [snip]
>>>>> I agree with the general tone of this suggestion.  Unfortunately
>>>>> however the particular code suggested might not compile (because
>>>>> the macro NULL might be #define'd to be 0, which can result in an
>>>>> error).  Writing the function this way:
>>>>>
>>>>>       void *
>>>>>       realloc0( void *p, size_t size ){
>>>>>           return  size == 0  ? free( p ), p = 0  : realloc( p, size );
>>>>>       }
>>>>>
>>>>> is an easy way to avoid that implementation dependency.
>>>>
>>>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
>>>> on autocast and use an explicit one instead.
>>>
>>> What "dependency" would that avoid, other than a dependency on
>>> the C standard?
>>
>> Why are you asking me this?
> 
> Because you are the one who suggested there is some kind of
> "dependency" in Tim's code?

The comment about "implementation dependency" was written by Tim, jak
was merely referring to that comment.

>> Perhaps you consider being portability if
>> you move the source code to another machine with the same operating
>> system, same compiler, same compiler version.
> 
> This has nothing to do with that.  Tim's code was correct and
> portable.

Tim's comment about an implementation dependency was written about code
written by Kaz Kylheku. That code does indeed have an implementation
dependency. Depending upon which choice an implementation makes for the
null pointer constant that NULL expands into, Kaz's code might or might
not contain a constraint violation.

[toc] | [prev] | [next] | [standalone]

#169907

In article <u11aau$27go8$1@dont-email.me>,
James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
>On 4/10/23 10:52, Dan Cross wrote:
>> In article <u10erc$23rhg$1@dont-email.me>, jak  <nospam@please.ty> wrote:
>>> Dan Cross ha scritto:
>>>> In article <u0uk66$1or41$1@dont-email.me>, jak  <nospam@please.ty> wrote:
>>>>> Tim Rentsch ha scritto:
>>>>>> [snip]
>>>>>> I agree with the general tone of this suggestion.  Unfortunately
>>>>>> however the particular code suggested might not compile (because
>>>>>> the macro NULL might be #define'd to be 0, which can result in an
>>>>>> error).  Writing the function this way:
>>>>>>
>>>>>>       void *
>>>>>>       realloc0( void *p, size_t size ){
>>>>>>           return  size == 0  ? free( p ), p = 0  : realloc( p, size );
>>>>>>       }
>>>>>>
>>>>>> is an easy way to avoid that implementation dependency.
>>>>>
>>>>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
>>>>> on autocast and use an explicit one instead.
>>>>
>>>> What "dependency" would that avoid, other than a dependency on
>>>> the C standard?
>>>
>>> Why are you asking me this?
>> 
>> Because you are the one who suggested there is some kind of
>> "dependency" in Tim's code?
>
>The comment about "implementation dependency" was written by Tim, jak
>was merely referring to that comment.

It seemed that jak was suggesting that in Tim's forumulation,
one should cast the 0 in p = 0, as in `p = (void *)0`.

>>> Perhaps you consider being portability if
>>> you move the source code to another machine with the same operating
>>> system, same compiler, same compiler version.
>> 
>> This has nothing to do with that.  Tim's code was correct and
>> portable.
>
>Tim's comment about an implementation dependency was written about code
>written by Kaz Kylheku. That code does indeed have an implementation
>dependency. Depending upon which choice an implementation makes for the
>null pointer constant that NULL expands into, Kaz's code might or might
>not contain a constraint violation.

That was not what I was referring to; see above and please note
the exact words I responded to (specifically the post that
referred to "autocast").

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#169910

On 4/10/23 11:37, Dan Cross wrote:
> In article <u11aau$27go8$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 4/10/23 10:52, Dan Cross wrote:
>>> In article <u10erc$23rhg$1@dont-email.me>, jak <nospam@please.ty> wrote:
>>>> Dan Cross ha scritto:
>>>>> In article <u0uk66$1or41$1@dont-email.me>, jak <nospam@please.ty>
>>>>> wrote:
>>>>>> Tim Rentsch ha scritto:
>>>>>>> [snip]
>>>>>>> I agree with the general tone of this suggestion. Unfortunately
>>>>>>> however the particular code suggested might not compile (because
>>>>>>> the macro NULL might be #define'd to be 0, which can result in an
>>>>>>> error). Writing the function this way:
>>>>>>>
>>>>>>> void *
>>>>>>> realloc0( void *p, size_t size ){
>>>>>>> return size == 0 ? free( p ), p = 0 : realloc( p, size );
>>>>>>> }
>>>>>>>
>>>>>>> is an easy way to avoid that implementation dependency.
>>>>>>
>>>>>> If you absolutely wanted to avoid dependency, perhaps you
>>>>>> shouldn't rely
>>>>>> on autocast and use an explicit one instead.
>>>>>
>>>>> What "dependency" would that avoid, other than a dependency on
>>>>> the C standard?
>>>>
>>>> Why are you asking me this?
>>>
>>> Because you are the one who suggested there is some kind of
>>> "dependency" in Tim's code?
>>
>> The comment about "implementation dependency" was written by Tim, jak
>> was merely referring to that comment.
>
> It seemed that jak was suggesting that in Tim's forumulation,
> one should cast the 0 in p = 0, as in `p = (void *)0`.

I don't think so. I believe that he was suggesting that it would be
preferable to rewrite Kaz's formulation as "free(ptr), (void*)NULL", or
simply "free(ptr), (void*)0", which would avoid the implementation
dependency. I took this as a suggestion of style, rather than implying
that it was necessary. The fact that "p=0" implicitly converts 0 to 'p's
type, and is the value of the assignment expression, is a little too
subtle for Jak, and I can see his point.

>>>> Perhaps you consider being portability if
>>>> you move the source code to another machine with the same operating
>>>> system, same compiler, same compiler version.
>>>
>>> This has nothing to do with that. Tim's code was correct and
>>> portable.
>>
>> Tim's comment about an implementation dependency was written about code
>> written by Kaz Kylheku. That code does indeed have an implementation
>> dependency. Depending upon which choice an implementation makes for the
>> null pointer constant that NULL expands into, Kaz's code might or might
>> not contain a constraint violation.
>
> That was not what I was referring to; see above and please note
> the exact words I responded to (specifically the post that
> referred to "autocast").

Jak's comment using the phrase "autocast" was not referring to any
implementation dependency in Tim's code, only to the same implementation
dependency in Kaz's code that Tim himself was talking about.

[toc] | [prev] | [next] | [standalone]

#169928

In article <u11bll$27m86$1@dont-email.me>,
James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
>On 4/10/23 11:37, Dan Cross wrote:
>>[snip]
>> It seemed that jak was suggesting that in Tim's forumulation,
>> one should cast the 0 in p = 0, as in `p = (void *)0`.
>
>I don't think so. I believe that he was suggesting that it would be
>preferable to rewrite Kaz's formulation as "free(ptr), (void*)NULL", or
>simply "free(ptr), (void*)0", which would avoid the implementation
>dependency. I took this as a suggestion of style, rather than implying
>that it was necessary. The fact that "p=0" implicitly converts 0 to 'p's
>type, and is the value of the assignment expression, is a little too
>subtle for Jak, and I can see his point.

You (and honestly, me) are both speculating.  This is why I
asked him what he meant; he responded by asking me why I was
asking him.  Subsequent posts from me suggest a less than
stellar command of the language, so I suspect he's simply
confused.

>>>> This has nothing to do with that. Tim's code was correct and
>>>> portable.
>>>
>>> Tim's comment about an implementation dependency was written about code
>>> written by Kaz Kylheku. That code does indeed have an implementation
>>> dependency. Depending upon which choice an implementation makes for the
>>> null pointer constant that NULL expands into, Kaz's code might or might
>>> not contain a constraint violation.
>>
>> That was not what I was referring to; see above and please note
>> the exact words I responded to (specifically the post that
>> referred to "autocast").
>
>Jak's comment using the phrase "autocast" was not referring to any
>implementation dependency in Tim's code, only to the same implementation
>dependency in Kaz's code that Tim himself was talking about.

Why don't we let him speak for himself?

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#169939

On 4/10/23 13:26, Dan Cross wrote:
> In article <u11bll$27m86$1@dont-email.me>,
> James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
...
> You (and honestly, me) are both speculating.  This is why I
> asked him what he meant; he responded by asking me why I was
> asking him.  Subsequent posts from me suggest a less than
> stellar command of the language, so I suspect he's simply
> confused.
...
> Why don't we let him speak for himself?

Because he hasn't chosen to do so, and because frankly, he doesn't do
that good a job of it. He's got language difficulties, and is using
Google translate to work around them. I've occasionally used Google
translate to respond to foreign language inquiries that arrive in this
newsgroup, but I always do so with a great deal of fear and trepidation
about how it might have mangled my message.

[toc] | [prev] | [next] | [standalone]

#169944

In article <u11kei$2907o$1@dont-email.me>,
James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
>On 4/10/23 13:26, Dan Cross wrote:
>> In article <u11bll$27m86$1@dont-email.me>,
>> James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
>...
>> You (and honestly, me) are both speculating.  This is why I
>> asked him what he meant; he responded by asking me why I was
>> asking him.  Subsequent posts from me suggest a less than
>> stellar command of the language, so I suspect he's simply
>> confused.
>...
>> Why don't we let him speak for himself?
>
>Because he hasn't chosen to do so, and because frankly, he doesn't do
>that good a job of it. He's got language difficulties, and is using
>Google translate to work around them. I've occasionally used Google
>translate to respond to foreign language inquiries that arrive in this
>newsgroup, but I always do so with a great deal of fear and trepidation
>about how it might have mangled my message.

Then given that you admit that neither of us actually knows what
he originally meant, perhaps we should refrain from assuming and
leveling accusations of "confusion" based on those assumptions.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#169970

cross@spitfire.i.gajendra.net (Dan Cross) writes:

[...]

> Why don't we let him speak for himself?

+1

It would be nice if people would follow this precept
more often.

[toc] | [prev] | [next] | [standalone]

#169912

On Mon, 10 Apr 2023 11:34:54 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 4/10/23 10:52, Dan Cross wrote:
> > In article <u10erc$23rhg$1@dont-email.me>, jak  <nospam@please.ty> wrote:
> >> Dan Cross ha scritto:
> >>> In article <u0uk66$1or41$1@dont-email.me>, jak  <nospam@please.ty> wrote:
> >>>> Tim Rentsch ha scritto:
> >>>>> [snip]
> >>>>> I agree with the general tone of this suggestion.  Unfortunately
> >>>>> however the particular code suggested might not compile (because
> >>>>> the macro NULL might be #define'd to be 0, which can result in an
> >>>>> error).  Writing the function this way:
> >>>>>
> >>>>>       void *
> >>>>>       realloc0( void *p, size_t size ){
> >>>>>           return  size == 0  ? free( p ), p = 0  : realloc( p, size );
> >>>>>       }
> >>>>>
> >>>>> is an easy way to avoid that implementation dependency.
> >>>>
> >>>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
> >>>> on autocast and use an explicit one instead.
> >>>
> >>> What "dependency" would that avoid, other than a dependency on
> >>> the C standard?
> >>
> >> Why are you asking me this?
> > 
> > Because you are the one who suggested there is some kind of
> > "dependency" in Tim's code?
> 
> The comment about "implementation dependency" was written by Tim, jak
> was merely referring to that comment.

Yes , but which piece of code was jak referring to ? For easy reference lets
call  Code A

  return (size == 0) ? free(ptr), NULL : realloc(ptr, size);

which posted by Kaz in  <20230407042121.909@kylheku.com>  and  Code B

    void *
    realloc0( void *p, size_t size ){
        return  size == 0  ? free( p ), p = 0  : realloc( p, size );
    }

which was posted by Tim in  <86r0st3zj0.fsf@linuxsc.com> .So when jak said
"If you absolutely wanted to avoid dependency" which of the 2 code excerpts
was he referring to ? I took it to mean that he was referring to Code B and I
think Dan took it to mean the same. Code B does not have any "implementation
dependency" , it just relies on the C standard. In contrast , Code A may have
a constraint violation depending on how the implementation defines NULL , as
Tim pointed out.

> >> Perhaps you consider being portability if
> >> you move the source code to another machine with the same operating
> >> system, same compiler, same compiler version.
> > 
> > This has nothing to do with that.  Tim's code was correct and
> > portable.
> 
> Tim's comment about an implementation dependency was written about code
> written by Kaz Kylheku. That code does indeed have an implementation
> dependency. Depending upon which choice an implementation makes for the
> null pointer constant that NULL expands into, Kaz's code might or might
> not contain a constraint violation.

[toc] | [prev] | [next] | [standalone]

#169914

On 4/10/23 11:58, Spiros Bousbouras wrote:
> On Mon, 10 Apr 2023 11:34:54 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
...
>> The comment about "implementation dependency" was written by Tim, jak
>> was merely referring to that comment.
> 
> Yes , but which piece of code was jak referring to ? For easy reference lets
> call  Code A
> 
>   return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
> 
> which posted by Kaz in  <20230407042121.909@kylheku.com>  and  Code B
> 
>     void *
>     realloc0( void *p, size_t size ){
>         return  size == 0  ? free( p ), p = 0  : realloc( p, size );
>     }
> 
> which was posted by Tim in  <86r0st3zj0.fsf@linuxsc.com> .So when jak said
> "If you absolutely wanted to avoid dependency" which of the 2 code excerpts
> was he referring to ? I took it to mean that he was referring to Code B and I
> think Dan took it to mean the same. Code B does not have any "implementation
> dependency" , it just relies on the C standard. In contrast , Code A may have
> a constraint violation depending on how the implementation defines NULL , as
> Tim pointed out.

I took jak as referring to both code A and code B. He was saying that
code A has an implementation dependency, while code B did not, but that
he would prefer a different way of modifying code A to avoid that
dependency. I understood him to be expressing a stylistic preference,
not something required in order for the code to be correct.

[toc] | [prev] | [next] | [standalone]

#169929

In article <u11c9m$27m86$3@dont-email.me>,
James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
>On 4/10/23 11:58, Spiros Bousbouras wrote:
>> On Mon, 10 Apr 2023 11:34:54 -0400
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>...
>>> The comment about "implementation dependency" was written by Tim, jak
>>> was merely referring to that comment.
>> 
>> Yes , but which piece of code was jak referring to ? For easy reference lets
>> call  Code A
>> 
>>   return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>> 
>> which posted by Kaz in  <20230407042121.909@kylheku.com>  and  Code B
>> 
>>     void *
>>     realloc0( void *p, size_t size ){
>>         return  size == 0  ? free( p ), p = 0  : realloc( p, size );
>>     }
>> 
>> which was posted by Tim in  <86r0st3zj0.fsf@linuxsc.com> .So when jak said
>> "If you absolutely wanted to avoid dependency" which of the 2 code excerpts
>> was he referring to ? I took it to mean that he was referring to Code B and I
>> think Dan took it to mean the same. Code B does not have any "implementation
>> dependency" , it just relies on the C standard. In contrast , Code A may have
>> a constraint violation depending on how the implementation defines NULL , as
>> Tim pointed out.
>
>I took jak as referring to both code A and code B. He was saying that
>code A has an implementation dependency, while code B did not, but that
>he would prefer a different way of modifying code A to avoid that
>dependency. I understood him to be expressing a stylistic preference,
>not something required in order for the code to be correct.

Instead of assuming, you should simply ask him.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#169969

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <u10erc$23rhg$1@dont-email.me>, jak  <nospam@please.ty> wrote:
>
>> Dan Cross ha scritto:
>>
>>> In article <u0uk66$1or41$1@dont-email.me>, jak  <nospam@please.ty> wrote:
>>>
>>>> Tim Rentsch ha scritto:
>>>>
>>>>> [snip]
>>>>> I agree with the general tone of this suggestion.  Unfortunately
>>>>> however the particular code suggested might not compile (because
>>>>> the macro NULL might be #define'd to be 0, which can result in an
>>>>> error).  Writing the function this way:
>>>>>
>>>>>       void *
>>>>>       realloc0( void *p, size_t size ){
>>>>>           return  size == 0  ? free( p ), p = 0  : realloc( p, size );
>>>>>       }
>>>>>
>>>>> is an easy way to avoid that implementation dependency.
>>>>
>>>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
>>>> on autocast and use an explicit one instead.
>>>
>>> What "dependency" would that avoid, other than a dependency on
>>> the C standard?
>>
>> Why are you asking me this?
>
> Because you are the one who suggested there is some kind of
> "dependency" in Tim's code?

I didn't take his comment that way.  My impression is that he
meant there _might_ be a dependency, or perhaps there is some
uncertainty about whether there is a dependency, or possibly that
there may be a dependency at some time in the future.  Of course
I am not sure what he meant, but that is how I took it.

[toc] | [prev] | [next] | [standalone]

Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10  Next page →

Back to top | Article view | comp.lang.c

csiph-web