Groups > comp.programming > #9626 > unrolled thread

Re: C is not a low level language

Started by	"Mr. Man-wai Chang" <toylet.toylet@gmail.com>
First post	2019-02-24 12:40 +0800
Last post	2019-02-25 19:04 +0800
Articles	20 on this page of 180 — 32 participants

Back to article view | Back to comp.programming

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

  Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 12:40 +0800
    Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 05:16 +0000
      Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 13:20 +0800
        Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 13:24 +0800
        Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 19:45 +0800
        Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 13:09 +0000
          Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 14:38 +0000
            Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 15:18 +0000
              Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 17:21 +0100
                Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 17:43 +0000
                  Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 20:17 +0100
                Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:19 +0000
                  Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 20:02 +0100
                    Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 19:26 +0000
                      Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 21:36 +0100
                        Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 20:47 +0000
                          Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:10 +0000
                          Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:25 +0100
                            Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 12:24 +0000
                              Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 17:04 +0100
                                Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 16:52 +0000
                        Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 17:59 -0800
                        Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 08:46 +0100
                          Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 09:36 +0100
                            Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 10:13 +0100
                              Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-26 09:56 +0100
                            Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-25 14:12 +0000
                          Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 12:20 +0000
                            Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 13:36 -0800
                        Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:29 +0200
                          Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 09:41 +0100
                            Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:55 +0200
                              Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 10:24 +0100
                    Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:03 +0000
                      Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:58 +0100
                        Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 09:40 +0100
                          Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 10:01 +0100
                Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 12:55 -0800
                  Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:31 +0100
              Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 17:42 +0000
                Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:19 +0000
              Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-24 17:56 +0000
                Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:23 +0000
                  Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 20:58 +0000
                Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 20:52 +0000
                  Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-25 16:31 +0000
                Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 14:01 -0800
                  Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-25 23:04 +0000
                    Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 15:53 -0800
                    Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:07 +0000
                Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 20:50 +0100
                  Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:04 +0000
                    Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-28 16:25 +0000
                      Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-28 11:56 -0500
                        Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-28 19:45 +0000
                Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 17:55 +0000
                  Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:03 +0000
                    Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-28 11:25 -0800
                      Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-28 19:30 +0000
            Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-24 20:47 +0000
              Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:29 +0000
                Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-25 20:16 +0000
        Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 12:53 -0800
        Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 09:49 +0200
      Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 21:07 +0100
        Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 22:59 +0000
          Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-26 09:57 +0100
            Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 09:59 +0000
    Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-02-24 19:54 +1300
      Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 07:56 +0000
        Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-02-24 21:58 +1300
          Re: C is not a low level language "A. Dumas" <alexandre@dumas.fr.invalid> - 2019-02-24 10:57 +0100
          Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 10:13 +0000
          Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 10:47 +0000
            Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 08:48 -0500
              Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 14:42 +0000
              Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 07:15 +0000
                Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 09:25 -0500
                  Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 15:03 +0000
                    Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 12:10 -0500
                      Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 17:58 +0000
                  Re: C is not a low level language Axel Berger <Spam@Berger-Odenthal.De> - 2019-02-25 17:44 +0100
                    Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 19:18 +0200
              Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:35 +0200
                Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 10:44 +0000
                  Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 12:29 +0000
                    Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 14:26 +0000
                      Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 17:08 +0000
                        Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:08 +0200
                        Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 18:00 +0000
                      Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-27 22:37 -0800
                        Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-28 02:25 -0800
                  Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
                Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 12:27 +0000
                Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 09:36 -0500
                  Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 15:05 +0000
                    Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 19:20 +0200
                      Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 23:02 +0000
                        Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 06:52 +0000
                        Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:41 +0200
                          Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 12:20 +0000
                          Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 14:01 +0100
                          Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-26 08:48 -0500
                          Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-26 19:20 +0100
                Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 10:04 -0500
          Re: C is not a low level language lonelydad <lonelydad58@gmail.com> - 2019-02-24 14:44 +0000
          Re: C is not a low level language "U-laptop\\Norah" <Norah@laptop.i-did-not-set--mail-host-address--so-tickle-me> - 2019-02-27 16:16 -0600
            Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-03-01 12:12 +1300
              Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-03-01 00:19 +0000
        Re: C is not a low level language Gene Wirchenko <genew@telus.net> - 2019-02-24 19:59 -0800
          Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-25 16:10 +0000
          Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 21:02 +0100
            Re: C is not a low level language Lars Enderin <lars.enderin@telia.com> - 2019-02-26 00:37 +0100
              Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 19:09 -0500
              Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 06:52 +0000
      Re: C is not a low level language T <T@invalid.invalid> - 2019-02-24 00:30 -0800
        Re: C is not a low level language T <T@invalid.invalid> - 2019-02-24 00:31 -0800
        Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 10:16 +0000
      Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-24 11:22 +0000
        Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 08:51 -0500
          Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 07:20 -0800
            Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-24 15:35 +0000
              Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 11:05 -0500
              Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 14:39 -0800
                Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 19:11 -0800
                Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 09:41 -0500
                  Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 14:53 +0000
                    Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 10:19 -0500
                      Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-25 16:38 +0100
                        Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 11:20 -0500
                          Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 17:49 +0000
                            Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:18 +0100
                        Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
                          Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:25 +0200
                            Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:40 -0500
                              Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:45 +0200
                                Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-26 08:02 -0500
                                Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-26 09:11 -0500
                            Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
                          Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:23 +0100
                            Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-26 08:02 -0500
                              Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 17:57 +0200
                          Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
                        Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 17:42 -0500
                        Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 22:33 +0000
                          Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:30 +0100
                      Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
                      Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 13:52 -0800
                    Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 15:20 +0000
                      Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
                        Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 18:47 +0000
                          Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:50 -0500
                            Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 18:59 +0000
                        Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:15 +0200
                          Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-25 18:38 +0000
                            Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:49 +0200
                          Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:40 -0500
                            Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:55 +0200
                              Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-26 16:29 +0000
                                Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
                                  Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-03-04 23:43 -0500
                        Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 18:16 +0000
                        Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 17:44 +0000
                          Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:05 -0500
                            Re: C is not a low level language Robert Wessel <robertwessel2@yahoo.com> - 2019-02-26 00:51 -0600
                              Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 10:58 +0100
                                Re: C is not a low level language Robert Wessel <robertwessel2@yahoo.com> - 2019-02-26 10:53 -0600
                                  Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 17:49 +0000
                                  Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-26 18:11 +0000
                                    Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-26 18:24 +0000
                                  Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 19:24 +0100
                                    Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 19:44 +0100
                        Re: C is not a low level language nobody@example.org (Scott) - 2019-02-26 06:33 +0000
                    Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
          Re: C is not a low level language Gene Wirchenko <genew@telus.net> - 2019-02-24 20:03 -0800
        Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 14:56 -0800
    Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-24 20:43 +0000
      Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-25 14:14 +0800
        Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 10:45 +0000
          Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-25 19:04 +0800

Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →

#9656

From	Richard Heathfield <rjh@cpax.org.uk>
Date	2019-02-24 18:19 +0000
Message-ID	<q4un8c$5bo$2@dont-email.me>
In reply to	#9652

On 24/02/2019 17:42, The Natural Philosopher wrote:
> On 24/02/2019 15:18, Richard Heathfield wrote:
>> On 24/02/2019 14:38, The Natural Philosopher wrote:
>>> On 24/02/2019 13:09, Richard Heathfield wrote:
>>>> If you take the trouble to ensure that you have enough space for 
>>>> your data, there's nothing wrong with using str.
>>>
>>> c=malloc(strlen(str)+1);
>>> if(c)
>>>      strcpy (c,str);
>>
>> Indeed, although I'd cache the length rather than make the compiler 
>> find it twice:
>>
>> size_t len = strlen(str) + 1;
>> c = malloc(len);
>> if(c)
>>    memcpy(c, str, len);
>>
>> but it's a minor point.
>>
>>
> Bet you the compiler output would be identical
> 
> They are staggeringly cunning.

You may well be right. And yes, they are, aren't they?!

-- 
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]

#9654

From	Bill Findlay <findlaybill@blueyonder.co.uk>
Date	2019-02-24 17:56 +0000
Message-ID	<0001HW.2223125A02182A717000059092EF@news.individual.net>
In reply to	#9647

On 24 Feb 2019, Richard Heathfield wrote
(in article <q4ucji$vqc$1@dont-email.me>):

> On 24/02/2019 14:38, The Natural Philosopher wrote:
> > On 24/02/2019 13:09, Richard Heathfield wrote:
> > > If you take the trouble to ensure that you have enough space for your
> > > data, there's nothing wrong with using str.
> >
> > c=malloc(strlen(str)+1);
> > if(c)
> > strcpy (c,str);
>
> Indeed, although I'd cache the length rather than make the compiler find
> it twice:
>
> size_t len = strlen(str) + 1;
> c = malloc(len);
> if(c)
> memcpy(c, str, len);
>
> but it's a minor point.

There is language in which you can write:

copy : String := source;

The compiler does all the work.
No need to use the heap.
The errors being discussed cannot happen, so no need for defensive coding.
It is used when lives are at stake.
It runs, at least some, code faster than C.
It is available on the R Pi.

Any guesses?

-- 
Bill Findlay

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

#9657

From	Richard Heathfield <rjh@cpax.org.uk>
Date	2019-02-24 18:23 +0000
Message-ID	<q4unf5$6vu$1@dont-email.me>
In reply to	#9654

On 24/02/2019 17:56, Bill Findlay wrote:

<snip>

> There is language in which you can write:
> 
> copy : String := source;

I'm sure there is.

There is an old saying:

"Memory management is far too important to be left to the programmer."

There is another old saying:

"Memory management is far too important to be left to the machine."

:-)

-- 
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]

#9667

From	The Natural Philosopher <tnp@invalid.invalid>
Date	2019-02-24 20:58 +0000
Message-ID	<q4v0ht$2dt$1@dont-email.me>
In reply to	#9657

On 24/02/2019 18:23, Richard Heathfield wrote:
> On 24/02/2019 17:56, Bill Findlay wrote:
> 
> <snip>
> 
>> There is language in which you can write:
>>
>> copy : String := source;
> 
> I'm sure there is.
> 
> There is an old saying:
> 
> "Memory management is far too important to be left to the programmer."

Yeah, I've worked on projects like that. They were just coders really. 
one step up from chimpanzees.

> 
> There is another old saying:
> 
> "Memory management is far too important to be left to the machine."

Indeed. Thats one good programmer who knows his hardware and host 
language and doesnt forget to free memory up after allocating it.

Wasnt there a bug in Windo0ws NT ore thereabouts that every time you 
allocated and deallocated a memory block you lost 4 bytes, and 
eventually the machine would crash from lack of kernel memory?

> 
> :-)
> 

-- 
"In our post-modern world, climate science is not powerful because it is 
true: it is true because it is powerful."

Lucas Bergkamp

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

#9664

From	The Natural Philosopher <tnp@invalid.invalid>
Date	2019-02-24 20:52 +0000
Message-ID	<q4v076$v0p$1@dont-email.me>
In reply to	#9654

On 24/02/2019 17:56, Bill Findlay wrote:
> On 24 Feb 2019, Richard Heathfield wrote
> (in article <q4ucji$vqc$1@dont-email.me>):
> 
>> On 24/02/2019 14:38, The Natural Philosopher wrote:
>>> On 24/02/2019 13:09, Richard Heathfield wrote:
>>>> If you take the trouble to ensure that you have enough space for your
>>>> data, there's nothing wrong with using str.
>>>
>>> c=malloc(strlen(str)+1);
>>> if(c)
>>> strcpy (c,str);
>>
>> Indeed, although I'd cache the length rather than make the compiler find
>> it twice:
>>
>> size_t len = strlen(str) + 1;
>> c = malloc(len);
>> if(c)
>> memcpy(c, str, len);
>>
>> but it's a minor point.
> 
> There is language in which you can write:
> 
> copy : String := source;
> 
> The compiler does all the work.
> No need to use the heap.

Instead it uses some sort of memory management that may do garbage 
collection at any time not under your control

> The errors being discussed cannot happen, so no need for defensive coding.
> It is used when lives are at stake.

It puts lives at risk

> It runs, at least some, code faster than C.
> It is available on the R Pi.
> 
> Any guesses?
> 
could be any one of a dozen me too languages.



-- 
"In our post-modern world, climate science is not powerful because it is 
true: it is true because it is powerful."

Lucas Bergkamp

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

#9721

From	Bill Findlay <findlaybill@blueyonder.co.uk>
Date	2019-02-25 16:31 +0000
Message-ID	<0001HW.22244FD40549FFD170000F02C2EF@news.individual.net>
In reply to	#9664

On 24 Feb 2019, The Natural Philosopher wrote
(in article <q4v076$v0p$1@dont-email.me>):

> On 24/02/2019 17:56, Bill Findlay wrote:
> > On 24 Feb 2019, Richard Heathfield wrote
> > (in article <q4ucji$vqc$1@dont-email.me>):
> >
> > > On 24/02/2019 14:38, The Natural Philosopher wrote:
> > > > On 24/02/2019 13:09, Richard Heathfield wrote:
> > > > > If you take the trouble to ensure that you have enough space for your
> > > > > data, there's nothing wrong with using str.
> > > >
> > > > c=malloc(strlen(str)+1);
> > > > if(c)
> > > > strcpy (c,str);
> > >
> > > Indeed, although I'd cache the length rather than make the compiler find
> > > it twice:
> > >
> > > size_t len = strlen(str) + 1;
> > > c = malloc(len);
> > > if(c)
> > > memcpy(c, str, len);
> > >
> > > but it's a minor point.
> >
> > There is language in which you can write:
> >
> > copy : String := source;
> >
> > The compiler does all the work. No need to use the heap.
>
> Instead it uses some sort of memory management that may do garbage
> collection at any time not under your control

No, it does not. You have jumped to an unwarranted conclusion.

> > The errors being discussed cannot happen, so no need for defensive coding.
> > It is used when lives are at stake.
>
> It puts lives at risk

Bollocks.
> > It runs, at least some, code faster than C. It is available on the R Pi.
> > Any guesses?
> could be any one of a dozen me too languages.

Name one.

-- 
Bill Findlay

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

#9733

From	Keith Thompson <kst-u@mib.org>
Date	2019-02-25 14:01 -0800
Message-ID	<lnmumjo7cw.fsf@kst-u.example.com>
In reply to	#9654

Bill Findlay <findlaybill@blueyonder.co.uk> writes:
[...]
> There is language in which you can write:
>
> copy : String := source;
>
> The compiler does all the work.
> No need to use the heap.
> The errors being discussed cannot happen, so no need for defensive coding.
> It is used when lives are at stake.
> It runs, at least some, code faster than C.
> It is available on the R Pi.
>
> Any guesses?

No.

You've posted at least two more followups without telling us what
language you're talking about.

So, what language are you talking about?  I, for one, am not interested
in guessing.

Please consider trimming the newsgroups to which this discussion is
being inappropriately cross-posted.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#9759

From	scott@slp53.sl.home (Scott Lurndal)
Date	2019-02-25 23:04 +0000
Message-ID	<Hv_cE.106749$qz5.28149@fx37.iad>
In reply to	#9733

Keith Thompson <kst-u@mib.org> writes:
>Bill Findlay <findlaybill@blueyonder.co.uk> writes:
>[...]
>> There is language in which you can write:
>>
>> copy : String := source;
>>
>> The compiler does all the work.
>> No need to use the heap.
>> The errors being discussed cannot happen, so no need for defensive coding.
>> It is used when lives are at stake.
>> It runs, at least some, code faster than C.
>> It is available on the R Pi.
>>
>> Any guesses?
>
>No.
>
>You've posted at least two more followups without telling us what
>language you're talking about.
>
>So, what language are you talking about?  I, for one, am not interested
>in guessing.
>
>Please consider trimming the newsgroups to which this discussion is
>being inappropriately cross-posted.

I'm pretty sure it is ADA.

   type ALIs_Record is record
      Afile : File_Name_Type;
      --  Name of ALI file

      Ofile_Full_Name : Name_Id;
      --  Full name of object file corresponding to the ALI file

      Sfile : File_Name_Type;
      --  Name of source file that generates this ALI file (which is equal
      --  to the name of the source file in the first unit table entry for
      --  this ALI file, since the body if present is always first).
...


Which would make the above example simple string assignment; in C

strcpy(copy, source);

I believe that ADA strings, however, have an implicit length field.

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

#9762

From	Keith Thompson <kst-u@mib.org>
Date	2019-02-25 15:53 -0800
Message-ID	<lnimx7o25s.fsf@kst-u.example.com>
In reply to	#9759

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <kst-u@mib.org> writes:
>>Bill Findlay <findlaybill@blueyonder.co.uk> writes:
>>[...]
>>> There is language in which you can write:
>>>
>>> copy : String := source;
>>>
>>> The compiler does all the work.
>>> No need to use the heap.
>>> The errors being discussed cannot happen, so no need for defensive coding.
>>> It is used when lives are at stake.
>>> It runs, at least some, code faster than C.
>>> It is available on the R Pi.
>>>
>>> Any guesses?
>>
>>No.
>>
>>You've posted at least two more followups without telling us what
>>language you're talking about.
>>
>>So, what language are you talking about?  I, for one, am not interested
>>in guessing.
>>
>>Please consider trimming the newsgroups to which this discussion is
>>being inappropriately cross-posted.
>
> I'm pretty sure it is ADA.

It's spelled "Ada"; the name is not an acronym.

That's certainly one possibility, but the question I'm asking is
not which languages Bill *might* be talking about.  I see no point
in continuing the discussion unless Bill tells us which language
he *is* talking about.

[...]

> I believe that ADA strings, however, have an implicit length field.

Not exactly.  It's more complicated than that.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#9801

From	Bill Findlay <findlaybill@blueyonder.co.uk>
Date	2019-02-28 16:07 +0000
Message-ID	<0001HW.22283EB60635FD2770000F02C2EF@news.individual.net>
In reply to	#9759

On 25 Feb 2019, Scott Lurndal wrote
(in article <Hv_cE.106749$qz5.28149@fx37.iad>):

> Keith Thompson <kst-u@mib.org> writes:
> > Bill Findlay<findlaybill@blueyonder.co.uk>  writes:
> > [...]
> > > There is language in which you can write:
> > >
> > > copy : String := source;
> > >
> > > The compiler does all the work.
> > > No need to use the heap.
> > > The errors being discussed cannot happen, so no need for defensive coding.
> > > It is used when lives are at stake.
> > > It runs, at least some, code faster than C.
> > > It is available on the R Pi.
> > >
> > > Any guesses?
> >
> > No.
> >
> > You've posted at least two more followups without telling us what
> > language you're talking about.
> >
> > So, what language are you talking about? I, for one, am not interested
> > in guessing.
> >
> > Please consider trimming the newsgroups to which this discussion is
> > being inappropriately cross-posted.
>
> I'm pretty sure it is ADA.

Ada (2012).

> type ALIs_Record is record
> Afile : File_Name_Type;
> -- Name of ALI file
>
> Ofile_Full_Name : Name_Id;
> -- Full name of object file corresponding to the ALI file
>
> Sfile : File_Name_Type;
> -- Name of source file that generates this ALI file (which is equal
> -- to the name of the source file in the first unit table entry for
> -- this ALI file, since the body if present is always first).
> ...
>
> Which would make the above example simple string assignment; in C
>
> strcpy(copy, source);
>
> I believe that ADA strings, however, have an implicit length field.

There are actually several kinds of string type.
One has an explicit length field.
One is actually allocated on the heap.
String, as you say, may have an implicit length field,
although the compiler can discard that if the length is
known at compile type.
-- 
Bill Findlay

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

#9740

From	Björn Lundin <b.f.lundin@gmail.com>
Date	2019-02-25 20:50 +0100
Message-ID	<q51gu2$1o6$1@dont-email.me>
In reply to	#9654

Den 2019-02-25 kl. 18:55, skrev Bart:
> On 24/02/2019 17:56, Bill Findlay wrote:
>> On 24 Feb 2019, Richard Heathfield wrote
>> (in article <q4ucji$vqc$1@dont-email.me>):
>>
>>> On 24/02/2019 14:38, The Natural Philosopher wrote:
>>>> On 24/02/2019 13:09, Richard Heathfield wrote:
>>>>> If you take the trouble to ensure that you have enough space for your
>>>>> data, there's nothing wrong with using str.
>>>>
>>>> c=malloc(strlen(str)+1);
>>>> if(c)
>>>> strcpy (c,str);
>>>
>>> Indeed, although I'd cache the length rather than make the compiler find
>>> it twice:
>>>
>>> size_t len = strlen(str) + 1;
>>> c = malloc(len);
>>> if(c)
>>> memcpy(c, str, len);
>>>
>>> but it's a minor point.
>>
>> There is language in which you can write:
>>
>> copy : String := source;
>>
>> The compiler does all the work.
>> No need to use the heap.
> 
> That depends on exactly what your line does. (Which actually is not that 
> clear: is String the name of a type or of a variable? 

>What's the 'copy:' 
> for? I assume it copies one string to another, but if so, does it copy 
> by value, or does it share the original string? Are the strings mutable? 
> What is the maximum string length (since non-heap space is usually 
> limited). etc.)

It pretty obvious.

'copy' is the name of a varible of type String.
String is mos likely an array of characters.
'Source' is also a name of a string varible.

So, 'copy' will become a string varible with a copy of the content of 
'source', and it will have the sme size. and same boundaries.
(an array does not have to start with index zero)

strings are mutable as any array.
max size is dependend on heap-size.


> 
>> The errors being discussed cannot happen, so no need for defensive 
>> coding.
>> It is used when lives are at stake.
>> It runs, at least some, code faster than C.
>> It is available on the R Pi.
>>
>> Any guesses?
> 
> No. Which one was it?


Ada


-- 
Björn

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

#9800

From	Bill Findlay <findlaybill@blueyonder.co.uk>
Date	2019-02-28 16:04 +0000
Message-ID	<0001HW.22283DFA0635D11A70000F02C2EF@news.individual.net>
In reply to	#9740

On 25 Feb 2019, Björn Lundin wrote
(in article <q51gu2$1o6$1@dont-email.me>):

> Den 2019-02-25 kl. 18:55, skrev Bart:
> > On 24/02/2019 17:56, Bill Findlay wrote:
> > > On 24 Feb 2019, Richard Heathfield wrote
> > > (in article <q4ucji$vqc$1@dont-email.me>):
> > >
> > > > On 24/02/2019 14:38, The Natural Philosopher wrote:
> > > > > On 24/02/2019 13:09, Richard Heathfield wrote:
> > > > > > If you take the trouble to ensure that you have enough space for your
> > > > > > data, there's nothing wrong with using str.
> > > > >
> > > > > c=malloc(strlen(str)+1);
> > > > > if(c)
> > > > > strcpy (c,str);
> > > >
> > > > Indeed, although I'd cache the length rather than make the compiler find
> > > > it twice:
> > > >
> > > > size_t len = strlen(str) + 1;
> > > > c = malloc(len);
> > > > if(c)
> > > > memcpy(c, str, len);
> > > >
> > > > but it's a minor point.
> > >
> > > There is language in which you can write:
> > >
> > > copy : String := source;
> > >
> > > The compiler does all the work.
> > > No need to use the heap.
> >
> > That depends on exactly what your line does. (Which actually is not that
> > clear: is String the name of a type or of a variable?
>
> > What's the 'copy:'
> > for? I assume it copies one string to another, but if so, does it copy
> > by value, or does it share the original string? Are the strings mutable?
> > What is the maximum string length (since non-heap space is usually
> > limited). etc.)
>
> It pretty obvious.
>
> 'copy' is the name of a varible of type String.
> String is mos likely an array of characters.
> 'Source' is also a name of a string varible.
>
> So, 'copy' will become a string varible with a copy of the content of
> 'source', and it will have the sme size. and same boundaries.
> (an array does not have to start with index zero)
>
> strings are mutable as any array.
> max size is dependend on heap-size.
>
> >
> > > The errors being discussed cannot happen, so no need for defensive
> > > coding.
> > > It is used when lives are at stake.
> > > It runs, at least some, code faster than C.
> > > It is available on the R Pi.
> > >
> > > Any guesses?
> >
> > No. Which one was it?
>
> Ada

Yup! 8-)

-- 
Bill Findlay

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

#9802

From	"J. P. Gilliver (John)" <G6JPG-255@255soft.uk>
Date	2019-02-28 16:25 +0000
Message-ID	<dZ33ROaSuAecFw5T@255soft.uk>
In reply to	#9800

In message <0001HW.22283DFA0635D11A70000F02C2EF@news.individual.net>, 
Bill Findlay <findlaybill@blueyonder.co.uk> writes:
>On 25 Feb 2019, Björn Lundin wrote
>(in article <q51gu2$1o6$1@dont-email.me>):
>
>> Den 2019-02-25 kl. 18:55, skrev Bart:
>> > On 24/02/2019 17:56, Bill Findlay wrote:
[]
>> > > There is language in which you can write:
>> > >
>> > > copy : String := source;
[]
>> > That depends on exactly what your line does. (Which actually is not that
>> > clear: is String the name of a type or of a variable?
[]
>> It pretty obvious.
[]
I'm sorry, but the above is why this sort of discussion never ends. When 
someone is intimately familiar with the syntax of a language, the 
meaning/functioning of a line like the above - or, say, in C, something 
like *a++=b(&c--) - _is_ obvious; to anyone else, it is far from so. And 
the person to whom it _is_ second nature sees no point in explaining it 
with a comment, either: (a) it just _does_ seem so obvious to them, (b) 
they'd actually find it difficult _to_ explain, in much the same way as 
describing the mechanics of walking isn't easy, even though most of us 
can do it. (Forgetting it took us some _years_ to learn!)
-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

... a series about a grumpy old man who lives in a phone box is unlikely to
have been commissioned these days. 798 episodes later ...

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

#9803

From	"Mayayana" <mayayana@invalid.nospam>
Date	2019-02-28 11:56 -0500
Message-ID	<q593ve$pih$1@dont-email.me>
In reply to	#9802

"J. P. Gilliver (John)" <G6JPG-255@255soft.uk> wrote

| I'm sorry, but the above is why this sort of discussion never ends. When
| someone is intimately familiar with the syntax of a language, the
| meaning/functioning of a line like the above - or, say, in C, something
| like *a++=b(&c--) - _is_ obvious; to anyone else, it is far from so. And
| the person to whom it _is_ second nature sees no point in explaining it
| with a comment, either: (a) it just _does_ seem so obvious to them, (b)
| they'd actually find it difficult _to_ explain, in much the same way as
| describing the mechanics of walking isn't easy, even though most of us
| can do it. (Forgetting it took us some _years_ to learn!)

   You're generous to ascribe honest intentions. It's
usually just a case of swagger: "I dare you to grovel
and ask me what this means." People do it. Officials
do it. Trades do it. Just look at the tech world,
"leveraging solutions across the enterprise". Their
jargon is gibberish to everyone else but they think
they sound technical.

   My favorite example is "micturate". Medical doctors
like to use obscure words to sound authoritative. So
when the general public got used to "urinate" they had
to switch to micturate to make sure people wouldn't
know what they were talking about. I'm waiting for
penis and vagina to get overused to the point that
they sound like swears and can no longer be used in
polite company. (It's getting close to that time, I think.)
Somehow the experts will cook up somethnig more
obscure, probably derived from Greek, so that doctors
and TV commentators can talk about sex in an offical
capacity.

|  *a++=b(&c--)

Get out of town!

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

#9806

From	"NY" <me@privacy.net>
Date	2019-02-28 19:45 +0000
Message-ID	<25qdnfHAbtXwp-XBnZ2dnUU78c3NnZ2d@brightview.co.uk>
In reply to	#9803

"Mayayana" <mayayana@invalid.nospam> wrote in message 
news:q593ve$pih$1@dont-email.me...
> I'm waiting for
> penis and vagina to get overused to the point that
> they sound like swears and can no longer be used in
> polite company.

I read somewhere that in some African countries where English is spoken 
(maybe as a second language), the "correct" words such as "penis" and 
vagina" are regarded as foul-mouthed and offensive, whereas our four-letter 
words are regarded as the correct ones to use in polite company.

Reminds me of that Greek chap in Shirley Valentine who told Shirley that he 
wanted to "make fuck" with her.

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

#9748

From	Bart <bc@freeuk.com>
Date	2019-02-25 17:55 +0000
Message-ID	<6_VcE.2540$lRX.2246@fx12.am4>
In reply to	#9654

On 24/02/2019 17:56, Bill Findlay wrote:
> On 24 Feb 2019, Richard Heathfield wrote
> (in article <q4ucji$vqc$1@dont-email.me>):
> 
>> On 24/02/2019 14:38, The Natural Philosopher wrote:
>>> On 24/02/2019 13:09, Richard Heathfield wrote:
>>>> If you take the trouble to ensure that you have enough space for your
>>>> data, there's nothing wrong with using str.
>>>
>>> c=malloc(strlen(str)+1);
>>> if(c)
>>> strcpy (c,str);
>>
>> Indeed, although I'd cache the length rather than make the compiler find
>> it twice:
>>
>> size_t len = strlen(str) + 1;
>> c = malloc(len);
>> if(c)
>> memcpy(c, str, len);
>>
>> but it's a minor point.
> 
> There is language in which you can write:
> 
> copy : String := source;
> 
> The compiler does all the work.
> No need to use the heap.

That depends on exactly what your line does. (Which actually is not that 
clear: is String the name of a type or of a variable? What's the 'copy:' 
for? I assume it copies one string to another, but if so, does it copy 
by value, or does it share the original string? Are the strings mutable? 
What is the maximum string length (since non-heap space is usually 
limited). etc.)

> The errors being discussed cannot happen, so no need for defensive coding.
> It is used when lives are at stake.
> It runs, at least some, code faster than C.
> It is available on the R Pi.
> 
> Any guesses?

No. Which one was it?

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

#9799

From	Bill Findlay <findlaybill@blueyonder.co.uk>
Date	2019-02-28 16:03 +0000
Message-ID	<0001HW.22283DDB0635C9A470000F02C2EF@news.individual.net>
In reply to	#9748

On 25 Feb 2019, Bart wrote
(in article <6_VcE.2540$lRX.2246@fx12.am4>):

> On 24/02/2019 17:56, Bill Findlay wrote:
> > On 24 Feb 2019, Richard Heathfield wrote
> > (in article <q4ucji$vqc$1@dont-email.me>):
> >
> > > On 24/02/2019 14:38, The Natural Philosopher wrote:
> > > > On 24/02/2019 13:09, Richard Heathfield wrote:
> > > > > If you take the trouble to ensure that you have enough space for your
> > > > > data, there's nothing wrong with using str.
> > > >
> > > > c=malloc(strlen(str)+1);
> > > > if(c)
> > > > strcpy (c,str);
> > >
> > > Indeed, although I'd cache the length rather than make the compiler find
> > > it twice:
> > >
> > > size_t len = strlen(str) + 1;
> > > c = malloc(len);
> > > if(c)
> > > memcpy(c, str, len);
> > >
> > > but it's a minor point.
> >
> > There is language in which you can write:
> >
> > copy : String := source;
> >
> > The compiler does all the work.
> > No need to use the heap.
>
> That depends on exactly what your line does.

Well, this discussion has a context, copying strings.

> (Which actually is not that clear: is String the name of a type or of a variable?

type
> What's the 'copy: for?

It's the copy
> I assume it copies one string to another, but if so, does it copy by value, or does it share the original string?

by value
> Are the strings mutable?

yes
> What is the maximum string length (since non-heap space is usually limited). etc.)

limited by the available store
> > The errors being discussed cannot happen, so no need for defensive coding.
> > It is used when lives are at stake.
> > It runs, at least some, code faster than C.
> > It is available on the R Pi.
> >
> > Any guesses?
>
> No. Which one was it?

Not saying yet. 8-)

-- 
Bill Findlay

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

#9804

From	Keith Thompson <kst-u@mib.org>
Date	2019-02-28 11:25 -0800
Message-ID	<lnsgw7n29t.fsf@kst-u.example.com>
In reply to	#9799

Bill Findlay <findlaybill@blueyonder.co.uk> writes:
[...]
>> On 24/02/2019 17:56, Bill Findlay wrote:
[...]
>> > There is language in which you can write:
>> >
>> > copy : String := source;
>> >
>> > The compiler does all the work.
>> > No need to use the heap.
[...]
>> > Any guesses?
>>
>> No. Which one was it?
>
> Not saying yet. 8-)

Please don't waste everyone's time.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#9805

From	Bart <bc@freeuk.com>
Date	2019-02-28 19:30 +0000
Message-ID	<8FWdE.416$Af.92@fx29.am4>
In reply to	#9804

On 28/02/2019 19:25, Keith Thompson wrote:
> Bill Findlay <findlaybill@blueyonder.co.uk> writes:
> [...]
>>> On 24/02/2019 17:56, Bill Findlay wrote:
> [...]
>>>> There is language in which you can write:
>>>>
>>>> copy : String := source;
>>>>
>>>> The compiler does all the work.
>>>> No need to use the heap.
> [...]
>>>> Any guesses?
>>>
>>> No. Which one was it?
>>
>> Not saying yet. 8-)
> 
> Please don't waste everyone's time.

It's been suggested that this was Ada, and that has been confirmed.

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

#9669

From	Jasen Betts <jasen@xnet.co.nz>
Date	2019-02-24 20:47 +0000
Message-ID	<q4uvsl$t27$3@gonzo.revmaps.no-ip.org>
In reply to	#9644

On 2019-02-24, The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 24/02/2019 13:09, Richard Heathfield wrote:
>> If you take the trouble to ensure that you have enough space for your 
>> data, there's nothing wrong with using str.
>
> c=malloc(strlen(str)+1);
> if(c)
> 	strcpy (c,str);
>
> or
>
> c=stdup(str);
>
> ....
>
> free (c);


or alloc_sprintf(....  but someone cross-posted this to windows newsgroups.



-- 
  When I tried casting out nines I made a hash of it.

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

Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →

csiph-web

Re: C is not a low level language

Contents

#9656

#9654

#9657

#9667

#9664

#9721

#9733

#9759

#9762

#9801

#9740

#9800

#9802

#9803

#9806

#9748

#9799

#9804

#9805

#9669