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

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

A glitch regarding the usual malloc() idiom

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

Contents

  A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-19 15:30 -0700
    Re: A glitch regarding the usual malloc() idiom Udyant Wig <udyant.wig@gmail.com> - 2016-07-20 09:51 +0530
      Re: A glitch regarding the usual malloc() idiom "Charles Richmond" <numerist@aquaporin4.com> - 2016-07-20 00:07 -0500
        Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 01:11 -0700
          Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 10:09 +0100
            Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 02:27 -0700
              Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 10:44 +0100
                Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 03:01 -0700
                  Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 11:17 +0100
                    Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 04:19 -0700
                      Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 12:29 +0100
                        Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 04:51 -0700
                          Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 13:01 +0100
                            Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 05:43 -0700
                              Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 15:48 +0100
                                Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-20 08:20 -0700
                                  Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 16:31 +0100
                                    Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-20 08:49 -0700
                                    Re: A glitch regarding the usual malloc() idiom "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-20 13:00 -0400
                                      Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 18:23 +0100
                      Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-20 14:17 +0100
                        Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 06:29 -0700
                          Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 15:51 +0100
                            Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-21 01:41 +0100
                              Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-21 02:05 +0100
                              Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 19:57 -0700
                                Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-21 10:14 +0100
                                  Re: A glitch regarding the usual malloc() idiom Rosario19 <Ros@invalid.invalid> - 2016-07-21 11:20 +0200
                                  Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-21 02:32 -0700
                                    Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-21 11:09 +0100
                                    Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 16:08 +0100
                                      Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-21 17:04 +0100
                                        Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-21 19:19 +0100
                                  Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-21 09:44 -0700
                          Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 09:05 -0700
                        Size augments for legacy code "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-20 07:22 -0700
              Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-20 11:10 +0100
              Re: A glitch regarding the usual malloc() idiom John Bode <jfbode1029@gmail.com> - 2016-08-04 13:07 -0700
                Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-08-04 14:02 -0700
                Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-08-04 22:14 +0100
                  Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-08-04 14:28 -0700
                  Re: A glitch regarding the usual malloc() idiom John Bode <jfbode1029@gmail.com> - 2016-08-04 15:58 -0700
                Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 23:29 -0700
                  Re: A glitch regarding the usual malloc() idiom John Bode <jfbode1029@gmail.com> - 2016-08-05 08:21 -0700
                  Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-08-05 08:38 -0700
                    Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-05 09:32 -0700
                      Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-08-05 10:30 -0700
                        Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-08-05 19:01 +0100
                          Re: A glitch regarding the usual malloc() idiom crisd <crisdunbar@gmail.com> - 2016-08-05 11:33 -0700
                          Re: A glitch regarding the usual malloc() idiom John Bode <jfbode1029@gmail.com> - 2016-08-05 12:01 -0700
                          Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-08-05 12:07 -0700
          Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 09:09 -0700
            Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 12:00 -0700
              Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-20 20:25 +0100
                Re: A glitch regarding the usual malloc() idiom Gareth Owen <gwowen@gmail.com> - 2016-07-20 20:38 +0100
                  Re: A glitch regarding the usual malloc() idiom Ike Naar <ike@iceland.freeshell.org> - 2016-07-20 20:03 +0000
                    Re: A glitch regarding the usual malloc() idiom Gareth Owen <gwowen@gmail.com> - 2016-07-20 22:31 +0100
                  Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 14:42 -0700
                    Re: A glitch regarding the usual malloc() idiom Gareth Owen <gwowen@gmail.com> - 2016-07-20 23:21 +0100
                Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-20 20:49 +0100
              Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 12:29 -0700
                Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 13:03 -0700
                  Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 16:55 -0700
                    Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 21:40 -0700
                      Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-21 07:16 +0100
                      Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-21 09:47 -0700
                      Re: A glitch regarding the usual malloc() idiom raltbos@xs4all.nl (Richard Bos) - 2016-07-23 09:37 +0000
                        Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-23 03:23 -0700
                          Re: A glitch regarding the usual malloc() idiom raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:47 +0000
                            Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-23 13:38 -0700
                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-23 17:53 -0400
                                Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-24 01:52 +0100
                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 11:06 -0400
                                    Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 16:32 +0100
                                      Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 17:27 -0400
                                        Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 22:58 +0100
                                          Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 18:19 -0400
                                            Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 23:44 +0100
                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 20:57 -0400
                                                Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 02:11 +0100
                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:12 -0400
                                        Re: A glitch regarding the usual malloc() idiom Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-24 17:28 -0600
                                          Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 00:37 +0100
                                          Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-24 16:59 -0700
                                            Re: A glitch regarding the usual malloc() idiom Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-24 19:32 -0600
                                              Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 02:35 +0100
                                                Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:14 -0400
                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:13 -0400
                                                Re: A glitch regarding the usual malloc() idiom Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-24 21:54 -0600
                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:08 -0400
                                                    Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 13:09 +0100
                                                      Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:22 -0400
                                                        Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 13:50 +0100
                                                          Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 11:48 -0400
                                                            Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 17:32 +0100
                                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 12:41 -0400
                                                            Re: A glitch regarding the usual malloc() idiom cross@spitfire.i.gajendra.net (Dan Cross) - 2016-07-25 16:35 +0000
                                                              Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 17:50 +0100
                                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 14:57 -0400
                                            Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-24 19:01 -0700
                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:14 -0400
                                          Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 20:58 -0400
                                            Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 02:14 +0100
                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:16 -0400
                                            Re: A glitch regarding the usual malloc() idiom Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-24 19:35 -0600
                                    Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-24 09:38 -0700
                                      Re: A glitch regarding the usual malloc() idiom "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-24 12:58 -0400
                                      Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 17:28 -0400
                                        Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 23:01 +0100
                                          Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-24 15:13 -0700
                                          Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 18:20 -0400
                                            Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-24 23:46 +0100
                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 20:59 -0400
                                                Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 02:21 +0100
                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:17 -0400
                                                    Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 03:34 +0100
                                                      Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:09 -0400
                                                        Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 13:21 +0100
                                                          Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 11:50 -0400
                                                            Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 17:38 +0100
                                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 14:59 -0400
                                                        Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-25 05:28 -0700
                                                          Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 11:52 -0400
                                                            Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-25 08:59 -0700
                                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 12:29 -0400
                                                                Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-25 09:39 -0700
                                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 15:00 -0400
                                          Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-24 19:09 -0700
                                            Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:19 -0400
                                            Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 03:31 +0100
                                              Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-24 21:20 -0700
                                                Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:10 -0400
                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:12 -0400
                                            Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-27 09:09 -0700
                                              Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-27 09:57 -0700
                                                Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 11:15 -0700
                                                  Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-28 15:18 -0700
                                                    Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-30 11:59 -0700
                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-28 21:02 -0400
                                                    Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-30 12:09 -0700
                                                      Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-31 14:07 -0700
                                                        Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 16:56 -0700
                                                          Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-08-01 08:57 -0700
                                              Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-27 11:41 -0700
                                                Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 11:25 -0700
                                        Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-24 15:28 -0700
                                          Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 21:00 -0400
                                            Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 02:31 +0100
                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 22:21 -0400
                                            Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-24 19:38 -0700
                                              Re: A glitch regarding the usual malloc() idiom Siri Cruise <chine.bleu@yahoo.com> - 2016-07-24 20:18 -0700
                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:15 -0400
                                                Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-25 07:31 -0700
                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 11:59 -0400
                                                    Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-25 10:31 -0700
                                                      Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-25 18:57 +0100
                                                      Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 15:04 -0400
                                          Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-24 19:14 -0700
                                            Re: A glitch regarding the usual malloc() idiom James Kuyper <jameskuyper@verizon.net> - 2016-07-24 22:49 -0400
                                              Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-24 21:12 -0700
                                            Re: A glitch regarding the usual malloc() idiom Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-24 21:58 -0600
                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:19 -0400
                                                Re: A glitch regarding the usual malloc() idiom Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-07-25 08:34 -0600
                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 12:01 -0400
                                                Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-25 08:32 -0700
                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 12:03 -0400
                                    Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-25 00:24 +0100
                                      Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-24 21:01 -0400
                                        Re: A glitch regarding the usual malloc() idiom Ian Collins <ian-news@hotmail.com> - 2016-07-25 17:08 +1200
                                          Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 08:19 -0400
                                        Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-25 17:07 +0100
                                          Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 12:36 -0400
                                            Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-25 10:34 -0700
                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 15:05 -0400
                                                Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-25 12:18 -0700
                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-25 16:05 -0400
                                            Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-26 01:08 +0100
                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 12:29 -0400
                                                Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-26 09:41 -0700
                                                  Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-26 10:50 -0700
                                                  Re: A glitch regarding the usual malloc() idiom Ike Naar <ike@iceland.freeshell.org> - 2016-07-26 18:09 +0000
                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 14:43 -0400
                                                Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-26 20:25 +0100
                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 15:33 -0400
                                                    Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-26 21:05 +0100
                                                      Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 16:37 -0400
                                                    Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-26 13:23 -0700
                                                      Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 16:39 -0400
                                                        Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-26 14:07 -0700
                                                        Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-26 14:51 -0700
                                                          Re: A glitch regarding the usual malloc() idiom Öö Tiib <ootiib@hot.ee> - 2016-07-26 15:17 -0700
                                                          Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 23:26 -0400
                                                            Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-26 20:46 -0700
                                                            Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 07:52 +0100
                                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 08:47 -0400
                                                                Re: A glitch regarding the usual malloc() idiom David Brown <david.brown@hesbynett.no> - 2016-07-27 17:13 +0200
                                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 12:03 -0400
                                                                Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-27 09:57 -0700
                                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 16:18 -0400
                                                            Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-27 07:58 -0700
                                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 12:05 -0400
                                                                Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 17:18 +0100
                                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 16:20 -0400
                                                                    Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-28 07:14 +0100
                                                                      Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-28 08:59 -0700
                                                                      Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-28 13:37 -0400
                                                                Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-27 09:42 -0700
                                                                  Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 16:20 -0400
                                                        Re: A glitch regarding the usual malloc() idiom jameskuyper@verizon.net - 2016-07-26 15:31 -0700
                                                          Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 23:32 -0400
                                                            Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 07:58 +0100
                                                              Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-27 08:52 -0400
                                                      Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-27 11:21 +0100
                                                        Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 13:34 +0100
                                                          Re: A glitch regarding the usual malloc() idiom David Brown <david.brown@hesbynett.no> - 2016-07-27 16:31 +0200
                                                            Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-27 16:20 +0100
                                                              Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-27 23:36 +0100
                                                                Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-28 14:51 +0100
                                                                  Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 09:26 -0700
                                                              Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 10:54 -0700
                                                    Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-27 03:12 +0100
                                                      Re: A glitch regarding the usual malloc() idiom Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-26 23:35 -0400
                                                      Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-26 20:41 -0700
                                                        Re: A glitch regarding the usual malloc() idiom raltbos@xs4all.nl (Richard Bos) - 2016-07-27 15:04 +0000
                                                        Re: A glitch regarding the usual malloc() idiom Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-27 16:05 +0100
                                                          Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-27 08:17 -0700
                                                            Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-27 09:21 -0700
                                                              Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-27 09:37 -0700
                                                                Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-27 10:11 -0700
                                                                  Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-27 10:21 -0700
                                                                    Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-27 11:34 -0700
                                                                      Re: A glitch regarding the usual malloc() idiom luser droog <luser.droog@gmail.com> - 2016-07-27 14:46 -0700
                                                                      Re: A glitch regarding the usual malloc() idiom David Brown <david.brown@hesbynett.no> - 2016-07-27 22:29 +0200
                                                                Re: A glitch regarding the usual malloc() idiom David Brown <david.brown@hesbynett.no> - 2016-07-27 20:32 +0200
                                                                  Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 00:22 -0700
                                                                    Re: A glitch regarding the usual malloc() idiom David Brown <david.brown@hesbynett.no> - 2016-07-28 13:01 +0200
                                                                      Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-28 04:46 -0700
                                                  Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-26 12:57 -0700
                                                  Re: A glitch regarding the usual malloc() idiom "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-26 16:00 -0400
                                Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-24 00:08 -0700
                              Re: A glitch regarding the usual malloc() idiom raltbos@xs4all.nl (Richard Bos) - 2016-07-27 14:58 +0000
                                Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-27 09:14 -0700
                                Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-27 11:55 -0700
              Re: A glitch regarding the usual malloc() idiom Ike Naar <ike@iceland.freeshell.org> - 2016-07-20 19:47 +0000
                Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 13:09 -0700
                  Re: A glitch regarding the usual malloc() idiom Ike Naar <ike@iceland.freeshell.org> - 2016-07-20 20:49 +0000
                    Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 14:35 -0700
        Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 09:01 -0700
      Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 08:59 -0700
    Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-20 09:24 -0700
      Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 11:28 -0700
        Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 18:38 -0700
    Re: A glitch regarding the usual malloc() idiom Rosario19 <Ros@invalid.invalid> - 2016-07-20 22:10 +0200
    Re: A glitch regarding the usual malloc() idiom Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2016-07-20 16:16 -0700
      Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-20 19:56 -0700
      Re: A glitch regarding the usual malloc() idiom Udyant Wig <udyant.wig@gmail.com> - 2016-07-21 18:46 +0530
        Re: A glitch regarding the usual malloc() idiom Ike Naar <ike@iceland.freeshell.org> - 2016-07-21 17:20 +0000
          Re: A glitch regarding the usual malloc() idiom Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 18:03 +0530
        Re: A glitch regarding the usual malloc() idiom James Kuyper <jameskuyper@verizon.net> - 2016-07-21 15:39 -0400
          Re: A glitch regarding the usual malloc() idiom Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 18:04 +0530
            Re: A glitch regarding the usual malloc() idiom James Kuyper <jameskuyper@verizon.net> - 2016-07-22 13:44 -0400
              Re: A glitch regarding the usual malloc() idiom Udyant Wig <udyant.wig@gmail.com> - 2016-07-23 15:38 +0530
          Re: A glitch regarding the usual malloc() idiom Udyant Wig <udyant.wig@gmail.com> - 2016-07-23 15:36 +0530
            Re: A glitch regarding the usual malloc() idiom "James R. Kuyper" <jameskuyper@verizon.net> - 2016-07-23 13:08 -0400
              Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-23 13:23 -0700
            Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-23 19:57 +0100
            Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-23 13:03 -0700
              Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-24 08:06 -0700
                Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-24 14:17 -0700
        Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 19:45 -0700
          Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 13:13 +0100
      Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 19:23 -0700
        Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-21 20:02 -0700
          Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 07:57 +0100
            Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 00:18 -0700
              Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 08:20 +0100
                Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 00:49 -0700
                  Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 09:31 +0100
                    Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 10:22 +0100
                      Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 12:21 +0100
                        Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 17:15 +0100
                          Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-23 19:46 +0100
                        Re: A glitch regarding the usual malloc() idiom supercat@casperkitty.com - 2016-07-22 16:43 -0700
                      Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-22 09:17 -0700
                        Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 18:21 +0100
                          Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-22 11:05 -0700
                            Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 22:38 +0100
                        Re: A glitch regarding the usual malloc() idiom James Kuyper <jameskuyper@verizon.net> - 2016-07-22 13:58 -0400
                          Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-22 11:14 -0700
                    Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 02:23 -0700
                      Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 12:23 +0100
                        Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 06:44 -0700
                          Re: A glitch regarding the usual malloc() idiom Keith Thompson <kst-u@mib.org> - 2016-07-22 09:18 -0700
                        Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 17:00 +0100
                          Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-23 19:48 +0100
            Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 10:08 +0100
              Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 10:26 +0100
              Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 12:12 +0100
                Re: A glitch regarding the usual malloc() idiom BartC <bc@freeuk.com> - 2016-07-22 12:35 +0100
                  Re: A glitch regarding the usual malloc() idiom Richard Heathfield <rjh@cpax.org.uk> - 2016-07-22 14:47 +0100
          Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-25 09:37 -0700
            Re: A glitch regarding the usual malloc() idiom Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-25 09:50 -0700
              Re: A glitch regarding the usual malloc() idiom Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 11:40 -0700

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

#90655

On 20/07/2016 12:19, Malcolm McLean wrote:
> On Wednesday, July 20, 2016 at 11:17:15 AM UTC+1, Richard Heathfield wrote:
>> On 20/07/16 11:01, Malcolm McLean wrote:
>
>>> So junk it.
>>
>> Junk what? C? Why?
>>
> Junk sizeof.
>
> What is it achieving?
> On some machines int is two bytes, on others four. So sizeof() allows code to work
> portably on both architectures.
> That's all we're getting out of it. It adds no further functionality.

sizeof or some equivalent that does the same job is needed.

Not just for malloc, but also for use with memcpy, memcmp and memset for 
example.

While if passing a struct to Win32, it often needs to contain its size 
(as that is used to check the version).

There must be innumerable other uses where the lack of sizeof would be 
very awkward. (Checking whether a pointer is 32 or 64 bits for example.)

Getting rid just of the ability to use sizeof on expressions is however 
workable (apart from the billion lines of existing code that uses it, 
and the unpopularity of doing so).

--
Bartc

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

#90656

On Wednesday, July 20, 2016 at 2:17:44 PM UTC+1, Bart wrote:
> 
> sizeof or some equivalent that does the same job is needed.
> 
> Not just for malloc, but also for use with memcpy, memcmp and memset for 
> example.
> 
I know, I'm just teasing Richard.

The point is that sizeof is just a little detail. We want to pass N employees to
memcpy. So we need to pass N, and the type of structure we want to copy,
which C collapses to a size because it allows objects to be treated as raw bytes.

But the sizeof(EMPLOYEE) factor is just a little thing, a minor fix up. 

Most other languages don't have it or, as with C++, it's effectively obsolete,
because to copy an array of employees to another you need to execute
structure-specific code.

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

#90659

On 20/07/16 14:29, Malcolm McLean wrote:
> On Wednesday, July 20, 2016 at 2:17:44 PM UTC+1, Bart wrote:
>>
>> sizeof or some equivalent that does the same job is needed.
>>
>> Not just for malloc, but also for use with memcpy, memcmp and memset for
>> example.
>>
> I know, I'm just teasing Richard.

Well, I suppose I should be relieved. I didn't think you could be that 
stupid, and it turns out, thankfully, that I was right.

> The point is that sizeof is just a little detail.

Of course it's a little detail. It's even littler if you don't (clog) 
(it) (up) (with) (extra) (bits).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#90704

On 20/07/2016 15:51, Richard Heathfield wrote:
> On 20/07/16 14:29, Malcolm McLean wrote:
>> On Wednesday, July 20, 2016 at 2:17:44 PM UTC+1, Bart wrote:
>>>
>>> sizeof or some equivalent that does the same job is needed.
>>>
>>> Not just for malloc, but also for use with memcpy, memcmp and memset for
>>> example.
>>>
>> I know, I'm just teasing Richard.
>
> Well, I suppose I should be relieved. I didn't think you could be that
> stupid, and it turns out, thankfully, that I was right.
>
>> The point is that sizeof is just a little detail.
>
> Of course it's a little detail. It's even littler if you don't (clog)
> (it) (up) (with) (extra) (bits).

Yeah, that makes sense in the context of a language which:

* Requires parentheses around every condition or switch expression

* Requires { } every time you have two or more statements in a branch

* Requires a simple A to B iterative loop to have double the number of
   tokens of any other syntax

* Requires ";" after every statement

* Requires "*" to be repeated in 'int *p,*q,*r' when you want multiple
   pointers

* Requires multiple or consecutive case values to be written
   individually with "case" and ":" for each

* Requires the prototype/signature or an exported function to be
   duplicated in a header

* Requires you to write 'sizeof(array)/sizeof(array[0])' to extract
   the length of an array

* Requires you to repeat the 'int' when you have a set of
   params such as (int a, int b, int c)

* Requires parentheses (yes, the same things you're complaining
   about) to distinguish between a pointer to array type, and array
   of pointers (oddly I didn't need them in English!)

* Requires you to write 'break;' after practically every switch-
   case statement

* Requires you to write "%d" to print an int, "%s" to print a string
   etc, information the compiler already knows

* Requires four characters for each comment (/**/)

* Requires you, for a 64-bit unsigned type, to either write:
   'uint64_t' or 'unsigned long long'

I think if you have a problem with writing 'sizeof(*p)' in the interests 
of unambiguity, which is actually only one character more than 'sizeof 
*p', then perhaps C isn't the right language for you!

-- 
Bartc

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

#90706

On 21/07/16 01:41, BartC wrote:
<snip>
>
> I think if you have a problem with writing 'sizeof(*p)'

I don't. I can write it just fine. I just choose not to, because it's daft.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#90708

BartC <bc@freeuk.com> writes:
[...]
> I think if you have a problem with writing 'sizeof(*p)' in the interests 
> of unambiguity, which is actually only one character more than 'sizeof 
> *p', then perhaps C isn't the right language for you!

`sizeof *p` is not ambiguous, so adding parentheses "in the interests of
unambiguity" doesn't make sense.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#90712

On 21/07/2016 03:57, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> [...]
>> I think if you have a problem with writing 'sizeof(*p)' in the interests
>> of unambiguity, which is actually only one character more than 'sizeof
>> *p', then perhaps C isn't the right language for you!
>
> `sizeof *p` is not ambiguous, so adding parentheses "in the interests of
> unambiguity" doesn't make sense.

Neither is 'a*sizeof*p' ambiguous according to the language, yet people 
tend to write: 'a*sizeof *p'; why is that?

Neither is this example that someone posted:

    sizeof (long)-2

Not according to the language. But to me it looks confusing.

(long) can be the parenthesised type needed by sizeof, or it can be a 
cast at the start of a single-term non-parenthesised expression. 
Presumably some detail of the grammar tells you which is matched first**.

But, if parentheses were obligatory, or you knew the style always used 
them, then you'd know immediately the above would *always* appear as:

   sizeof (long)-2    // meaning (sizeof (long))-2
   sizeof ((long)-2)

You'd know /for sure/ that the sizeof operand ended at the first 
parenthesis matching the opening one.

(** The expression that follows sizeof is a single term (not a general 
expression unless it's parenthesised), however that single term is split 
into two kinds:

   * Those that start with a cast
   * All other terms that don't start with a cast

Normal unary ops can use either. But the one following sizeof can only 
be without a cast. (So a bodge IMO.)

Not everyone writing or reading C will be conversant with its formal 
grammar, so I say that that sizeof (long)-2 example /looks/ ambiguous.)

-- 
Bartc

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

#90713

On Thu, 21 Jul 2016 10:14:05 +0100, BartC <bc@freeuk.com> wrote:

>Neither is 'a*sizeof*p' ambiguous according to the language, yet people 
>tend to write: 'a*sizeof *p'; why is that?

a*(sizeof *p)

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

#90714

On Thursday, July 21, 2016 at 10:14:23 AM UTC+1, Bart wrote:
>
> But, if parentheses were obligatory, or you knew the style always used 
> them, then you'd know immediately the above would *always* appear as:
> 
>    sizeof (long)-2    // meaning (sizeof (long))-2
>    sizeof ((long)-2)
> 
> You'd know /for sure/ that the sizeof operand ended at the first 
> parenthesis matching the opening one.
> 
Yes, not requiring the parenthesis was a simple poor design feature.

There's also a nasty potential problem with allowing sizeof an expression,
which doesn't occur in normal C, but will occur if we extend the language
to make "types" runtime objects.
We simply introduce a new keyword, type_t,  which holds a type. That allows
the construction of safer generic containers, instead of passing raw memory
to them we require that the type be passed in and that types match.

But now 

ARRAY *makearray(type_t type, int N)
{
   type *buff = malloc(N * sizeof(type));
}

is ambiguous.

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

#90716

On 21/07/2016 10:32, Malcolm McLean wrote:
> On Thursday, July 21, 2016 at 10:14:23 AM UTC+1, Bart wrote:
>>
>> But, if parentheses were obligatory, or you knew the style always used
>> them, then you'd know immediately the above would *always* appear as:
>>
>>    sizeof (long)-2    // meaning (sizeof (long))-2
>>    sizeof ((long)-2)
>>
>> You'd know /for sure/ that the sizeof operand ended at the first
>> parenthesis matching the opening one.
>>
> Yes, not requiring the parenthesis was a simple poor design feature.
>
> There's also a nasty potential problem with allowing sizeof an expression,
> which doesn't occur in normal C, but will occur if we extend the language
> to make "types" runtime objects.
> We simply introduce a new keyword, type_t,  which holds a type. That allows
> the construction of safer generic containers, instead of passing raw memory
> to them we require that the type be passed in and that types match.
>
> But now
>
> ARRAY *makearray(type_t type, int N)
> {
>    type *buff = malloc(N * sizeof(type));
> }
>
> is ambiguous.

Yes, I've had exactly that problem. I think I used some workaround.

The answer might be to use different versions of 'sizeof', when it's not 
clear if you want the size of the type that contains a type, or the size 
of the type referred to.

The probability of it ever being a problem in C however is remote.

-- 
Bartc

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

#90720

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Thursday, July 21, 2016 at 10:14:23 AM UTC+1, Bart wrote:
>>
>> But, if parentheses were obligatory, or you knew the style always used 
>> them, then you'd know immediately the above would *always* appear as:
>> 
>>    sizeof (long)-2    // meaning (sizeof (long))-2
>>    sizeof ((long)-2)
>> 
>> You'd know /for sure/ that the sizeof operand ended at the first 
>> parenthesis matching the opening one.
>> 
> Yes, not requiring the parenthesis was a simple poor design feature.
>
> There's also a nasty potential problem with allowing sizeof an expression,
> which doesn't occur in normal C, but will occur if we extend the language
> to make "types" runtime objects.
> We simply introduce a new keyword, type_t,  which holds a type. That allows
> the construction of safer generic containers, instead of passing raw memory
> to them we require that the type be passed in and that types match.
>
> But now 
>
> ARRAY *makearray(type_t type, int N)
> {
>    type *buff = malloc(N * sizeof(type));
> }
>
> is ambiguous.

The sizeof part isn't, at least in any technical sense.  Note that this
is a neat example of the advantage of the

  *buff = malloc(N * sizeof *buff)

syntax.

It would be daft to give sizeof type (I'm leaving off the brackets
deliberately) any meaning other than the obvious one: the size of the
type_t object.  I should, after all, be permitted to do all the usual
things with type values like allocate arrays of them and examine their
representation.

I would provide syntax to turn a type value into a type name:

void *makearray(type_t T, int N)
{
    _Type(T) *buff = malloc(N * sizeof *buff);
}

so if you insist on a type name operand for sizeof it would be

    _Type(T) *buff = malloc(N * sizeof (_Type(T));

-- 
Ben.

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

#90721

On 21/07/2016 16:08, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

>> ARRAY *makearray(type_t type, int N)
>> {
>>    type *buff = malloc(N * sizeof(type));
>> }
>>
>> is ambiguous.

> I would provide syntax to turn a type value into a type name:
>
> void *makearray(type_t T, int N)
> {
>     _Type(T) *buff = malloc(N * sizeof *buff);
> }
>
> so if you insist on a type name operand for sizeof it would be
>
>     _Type(T) *buff = malloc(N * sizeof (_Type(T));

Very ambitious I think to try and use _Type() in any context where a 
static type normally goes. At least in a language one step up from C.

It might be OK purely for sizeof. Otherwise it might be a can of worms.

-- 
Bartc

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

#90734

On 21/07/2016 17:04, BartC wrote:
> On 21/07/2016 16:08, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>>> ARRAY *makearray(type_t type, int N)
>>> {
>>>    type *buff = malloc(N * sizeof(type));
>>> }
>>>
>>> is ambiguous.
>
>> I would provide syntax to turn a type value into a type name:
>>
>> void *makearray(type_t T, int N)
>> {
>>     _Type(T) *buff = malloc(N * sizeof *buff);
>> }
>>
>> so if you insist on a type name operand for sizeof it would be
>>
>>     _Type(T) *buff = malloc(N * sizeof (_Type(T));
>
> Very ambitious I think to try and use _Type() in any context where a
> static type normally goes. At least in a language one step up from C.
>
> It might be OK purely for sizeof. Otherwise it might be a can of worms.

(I use the equivalent of 'type_t' in a dynamic language of mine:

* A type_t value can only appear in an expression

* A type_t expression can't appear where a normal type goes, and
   there is no equivalent of your '_Type()' to transform it

* A standard type such as 'int' appearing in an expression (where
   it's not part of a cast) is treated as a type_t constant or literal.

* The equivalent of sizeof either works on a static type, or an
   expression of type_t. (In this dynamic language, the byte-size
   of a general expression value is less meaningful.))


-- 
bartc

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

#90725

BartC <bc@freeuk.com> writes:
> On 21/07/2016 03:57, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> I think if you have a problem with writing 'sizeof(*p)' in the interests
>>> of unambiguity, which is actually only one character more than 'sizeof
>>> *p', then perhaps C isn't the right language for you!
>>
>> `sizeof *p` is not ambiguous, so adding parentheses "in the interests of
>> unambiguity" doesn't make sense.
>
> Neither is 'a*sizeof*p' ambiguous according to the language, yet people 
> tend to write: 'a*sizeof *p'; why is that?
>
> Neither is this example that someone posted:
>
>     sizeof (long)-2
>
> Not according to the language. But to me it looks confusing.

Sure, if you deliberately use whitespace in a way that conflicts
with the meaning of the expression.  See also `x+y * z`.

> (long) can be the parenthesised type needed by sizeof, or it can be a 
> cast at the start of a single-term non-parenthesised expression. 
> Presumably some detail of the grammar tells you which is matched first**.
>
> But, if parentheses were obligatory, or you knew the style always used 
> them, then you'd know immediately the above would *always* appear as:
>
>    sizeof (long)-2    // meaning (sizeof (long))-2
>    sizeof ((long)-2)
>
> You'd know /for sure/ that the sizeof operand ended at the first 
> parenthesis matching the opening one.

Of course there are cases where adding parentheses, even if
they aren't strictly necessary, can make an expression clearer.
`sizeof (long) - 2` may be one of those cases.  We simply disagree
on whether `sizeof *p` is another -- and I've wasted too much time
arguing the point with you.

> (** The expression that follows sizeof is a single term (not a general 
> expression unless it's parenthesised), however that single term is split 
> into two kinds:
>
>    * Those that start with a cast
>    * All other terms that don't start with a cast

No, the parenthesized type name in `sizeof ( type-name )` is not a cast,
any more than the commas in a function call are comma operators.

> Normal unary ops can use either. But the one following sizeof can only 
> be without a cast. (So a bodge IMO.)
>
> Not everyone writing or reading C will be conversant with its formal 
> grammar, so I say that that sizeof (long)-2 example /looks/ ambiguous.)

Strawman argument.  It looks ambiguous because you deliberately used
deceptive whitespace to make it look ambiguous.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#90668

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, July 20, 2016 at 2:17:44 PM UTC+1, Bart wrote:
>> 
>> sizeof or some equivalent that does the same job is needed.
>> 
>> Not just for malloc, but also for use with memcpy, memcmp and memset for 
>> example.
>> 
> I know, I'm just teasing Richard.

So you were trolling.

Please don't.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#90657 — Size augments for legacy code

On Wednesday, July 20, 2016 at 9:17:44 AM UTC-4, Bart wrote:
> While if passing a struct to Win32, it often needs to contain its size 
> (as that is used to check the version).

I've wondered about that.  Why wouldn't it be possible to maintain a
legacy history of developmental changes through versions which then
automatically, as by the compiler, relate to named function entry points
which contain the version of the function which existed at that time?

This would be primarily for previously publicly published API functions,
so as to not break earlier functionality.  Here's an example using
structs, but it could be applied to many things (including changes in
parameters or sizes used in a function).

    // Version 1.0
    struct SAbc
    {
        int a;
    };

    // Version 2.0
    struct SAbc
    {
        int a;
        int b;
    };

    // Version 3.0
    struct SAbc
    {
        int a;
        float b;
    };

With compiler support for something like this:

    struct SAbc [|version|1.0||]
    {
        int a;
    };

    struct SAbc [|version|2.0||]
    {
        int a;
        int b;
    };

    struct SAbc [|version|3.0||]
    {
        int a;
        float b;
    };


The married GUI editor and compiler could then automatically maintain
the prior functionality in function by name+version, and automatically
determine entry points to the correct function based on the parameters
which then exist in the essentially overloaded function.

I realize this wouldn't work with legacy code, but in moving forward.
Any new changes to the [|version|1.0||] algorithm could then be added
as necessary to support the extensions provided for in later versions.
A call to a new OS function could also be auto-injected which records
use of legacy functions which are in some ways notably affecting app
performance.  The user could then see the notes auto-generated which
are attached to the running application, requesting them to get a new
version which is not using the legacy API ports.

> Getting rid just of the ability to use sizeof on expressions is however 
> workable (apart from the billion lines of existing code that uses it, 
> and the unpopularity of doing so).

Sizeof, offsetof, lengthof, countof, are all fundamental and essential,
and should only support and generate compile-time known information.  If
there are variables involved, they should be runtime checked, or guaranteed
to be in their proper form on that line of code because the app would've
suspended before reaching the point where a NULL pointer due to failed
malloc() would be encountered, for example.

Best regards,
Rick C. Hodgin

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

#90648

On 20/07/2016 10:27, Malcolm McLean wrote:
> On Wednesday, July 20, 2016 at 10:09:34 AM UTC+1, Richard Heathfield wrote:

>> Since this dereferencing /doesn't happen/, the question of its
>> desirability doesn't arise.
>>
> Ok, so we've got a special rule.
>
> * does not dereference a pointer when preceded by a sizeof.
>
> That seems to me sufficiently undesirable that it has no place in
> release-quality C code.

Maybe you have to think of it like 'quote' in Lisp. It treats the 
expression itself as data, applies a notional 'typeof' operator to it, 
and then applies 'sizeof' to that.

The same would apply to sizeof (a[i]) when i is not yet defined. No code 
is generated to evaluate the expression operand of sizeof, so nothing 
bad can happen. (I don't understand the VLA angle.)

(I can't say this shouldn't be used because I have the same thing in my 
own parallel language! Except there it looks like p^.bytes or 
a[i].bytes. Usually however I work from types.)

-- 
Bartc

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

#91674

On Wednesday, July 20, 2016 at 4:28:00 AM UTC-5, Malcolm McLean wrote:
> On Wednesday, July 20, 2016 at 10:09:34 AM UTC+1, Richard Heathfield wrote:
> > On 20/07/16 09:11, Malcolm McLean wrote:
> > > On Wednesday, July 20, 2016 at 6:07:50 AM UTC+1, Charles Richmond wrote:
> > >>
> > >> IMHO, a better choice for the standard would have been... to *forbid* any
> > >> variable length array type name to be used in sizeof().
> > >>
> > > Only types should be passed to sizeof().
> > 
> > Firstly, the verb is wrong. Operands aren't "passed" to operators. 
> > Secondly, the claim is wrong. Whilst it is true that C supports 
> > parenthesised types as legitimate operands to sizeof, it also supports 
> > expressions. In general, I have found that it's a good idea to use 
> > expressions wherever possible, and parenthesised types only when necessary.
> > 
> > > In particular, uninitialised pointers should not be dereferenced
> > > in a sizeof expression.
> > 
> > They aren't.
> > 
> > T *new = malloc(n * sizeof *new);
> > 
> > DOES NOT dereference 'new'. The code is perfectly fine.
> > 
> > > By a quirk of the language, that happens
> > > to be legal. But it's very obviously undesirable.
> > 
> > Since this dereferencing /doesn't happen/, the question of its 
> > desirability doesn't arise.
> > 
> Ok, so we've got a special rule.
> 
> * does not dereference a pointer when preceded by a sizeof.
> 

With the sole exception of VLAs, sizeof doesn't evaluate its operand
*at all*:  

    sizeof a[i] 

does not perform the subscript operation;

    sizeof a+b

does not perform the addition;

    sizeof a&&b 

does not perform the logical AND operation.

In all three cases, the type of the expression can be deduced at compile
time, so the size of each can be computed at compile time.  There's no
need to actually *evaluate* a or b or i.  

It's VLAs that are special, not pointers.

> That seems to me sufficiently undesirable that it has no place in
> release-quality C code.

The issue is that using the type name introduces a maintenance burden that
using the expression doesn't.  Imagine you're supporting code on a C89 
implementation that doesn't allow mixed declarations and code, so you have
to separate the declaration of a pointer from its use in a malloc call:

    T *p = NULL;
    int n = 0;
    printf( "Gimme a size: " );
    if ( scanf( "%d", &n ) == 1 )
    {
      p = malloc( sizeof *p * n );
      if ( !p )
      {
        ...
      }
    }

(In a modern C99 or C2011 environment, you'd defer the declaration of p 
until after reading n, but let's assume we have to run on an ancient 
implementation)

If I need to change the type of `p`, I only need to make that change in one
location.  However, if I used

    p = malloc( sizeof (T) * n );

it's now *my* responsibility to make sure the T in the malloc call matches
up with the T in the declaration.  I'm suddenly the strong link in the 
maintenance chain, which is almost always a bad idea.  Let the language or
compiler do the hard work for you:  

    p = malloc( n * sizeof *p );

will *always* allocate the right amount of memory to store n instances of
whatever the type of *p is.  The pointer doesn't get dereferenced; all 
sizeof does is deduce the type of *p.  

WRT to the issue Keith's talking about, it crops up when we try to
try to dynamically allocate multi-dimensional VLAs:

    size_t n = ..., m = ...;
    T (*arr)[m] = malloc( sizeof *arr * n );

I'm aiming to create a *contiguous* nxm array of T on the heap for whatever
reason (either the array is going to be large, or I want to use it at file
scope, etc.).  This works fine if the outer dimension is a compile-time
constant:

    #define M ...
    ...
    T (*arr)[M] = malloc( sizeof *arr * n );

sizeof *arr is able to deduce the type T [M] at compile time.  However,
if m isn't known until runtime, then the expression sizeof *arr has to be
"evaluated" at run time.  Again, there should be no reason to *dereference*
*arr to deduce its type (which is T [m]), but because of how the standard
is worded, the behavior is undefined.  I've yet to find a platform that
*didn't* give me the result I expect, but "it works on my machine" isn't
exactly a ringing endorsement of good practice.  Instead, if I wanted
to be good, I'd have to write something like

    T (*arr)[m] = malloc( sizeof ( T [m] ) * n );

which can get eye-stabby in a hurry depending on T.  

Yes, it would be awesome if C had a good way for determining how much 
memory to allocate without using sizeof.  It would be awesome if my 1996
Ford Ranger had all the features of a 2016 Ford F-150.  Both aren't 
happening for what should hopefully be obvious reasons.  You want better
dynamic memory management, use a language better suited for it.    

I would really like for the next revision of the standard to clarify this
a bit.  What does "evaluate" mean in the context of sizeof on a VLA?  What
sort of pitfalls are there when deducing a type (more properly, the *size*
of a type) at runtime?  

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

#91680

John Bode <jfbode1029@gmail.com> writes:
[...]
> With the sole exception of VLAs, sizeof doesn't evaluate its operand
> *at all*:  
>
>     sizeof a[i] 
>
> does not perform the subscript operation;
>
>     sizeof a+b
>
> does not perform the addition;
>
>     sizeof a&&b 
>
> does not perform the logical AND operation.

Perhaps a more striking example:

    sizeof printf("hello, world\n")

doesn't print anything.  It's equivalent to `sizeof (int)`, since
int is printf's return type.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#91683

On 04/08/2016 21:07, John Bode wrote:
> On Wednesday, July 20, 2016 at 4:28:00 AM UTC-5, Malcolm McLean wrote:

>> * does not dereference a pointer when preceded by a sizeof.
>>
>
> With the sole exception of VLAs, sizeof doesn't evaluate its operand
> *at all*:
>
>     sizeof a[i]
>
> does not perform the subscript operation;
>
>     sizeof a+b
>
> does not perform the addition;

I think it does.


>     sizeof a&&b
>
> does not perform the logical AND operation.

And it does here too. Because they are parsed as (sizeof a)+b and 
(sizeof a)&&b.


--
Bartc

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

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

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

csiph-web