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

Groups > comp.programming > #9626 > unrolled thread

Re: C is not a low level language

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.

Contents

  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 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9  Next page →

#9723

On 25/02/2019 16:04, R.Wieser wrote:
> Richard,
> 
>> Someone could use my code in a multi-threaded environment.
> 
> /You/ brought multi-threading up, I didn't.

Indeed. I was trying to imagine a situation in which the code I'd posted 
could break, and that was the only one I could come up with.

> Solve your own problems.

I do. That isn't one of my problems.

The rest of your reply suggests that we're not going to have a pleasant 
discussion, so I'll stop there.

<nonsense snipped>

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

#9676

"R.Wieser" <address@not.available> writes:
[...]
> True.  But that only goes as far as the programmer can imagine such attacks. 
> "strncpy" is ment as a "last ditch" effort to safeguard against the 
> /unforseen/ circumstances which could lead to memory/stack being clobbered. 
> My suggestion to provide it an argument that is one less than what the 
> buffer can actually hold is just an extension on that.

No, strncpy is designed to work with a specific (and, in recent
history, rare) data structure, namely a fixed-length character
array containing some bytes of meaningful data padded to the end
by zero or more null bytes.  (I believe it was used to store file
names in Unix directory entries.)

(followups to comp.lang.c only)

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

#9684

"R.Wieser" <address@not.available> writes:

> Richard,
>
>> But my code protected against that possibility by [snip]
>
> Thats why I said "In this simple example it will work".
>
>> The only way this could break would be if the source string grew between 
>> two consecutive lines of code that did not grow that string.
>
> In your example ?  Yes (and the same as I was thinking).
>
> Now imagine that you're programming and you /could/ be working on a 
> single-thread string, but as easily on a multi-thread one.  Wouldn't it be 
> easier to use a method which will work in either circumstance ?
>
>> If these circumstances are at all likely, it seems to me that it is better 
>> to protect against them than to succumb blindly to them.
>
> True.  But that only goes as far as the programmer can imagine such attacks. 
> "strncpy" is ment as a "last ditch" effort to safeguard against the 
> /unforseen/ circumstances which could lead to memory/stack being clobbered. 
> My suggestion to provide it an argument that is one less than what the 
> buffer can actually hold is just an extension on that.
>
> Personally I would not mind at all when it would throw or return an error 
> when the target buffer was found to be too small for the source string.   It 
> should never happen, and for that reason should not be silently ignored 
> either.   But thats just my take on it, YMMV.

Sorry to interject this important argument so deep in an unrelated
thread, but

In case you didn't notice, the terminating null is not stored or
transmitted to external devices.  When you display the string on a
screen, print it in a printer, transmit it to a remote terminal, etc,
the null byte should not be displayed, printed, transmitted.  It is NOT
part of the string.

So why C uses a null terminating byte for string literals?
The alternatives are:

- pascal strings: a length prefix (but is it a byte,
  a word, a long? In "modern" pascal implementations all those variants
  are possisble.

- no length, but a different type, and a stringly typed language that
  let you copy the literal only to an array of the same size
  (eg. Modula-2, IIRC).

- a designated string class used to implement strings (eg. Objective-C;
  it's even customizable in Objective-C, since the specific string class
  can be specified as argument to the compiler).

you can notice that 1960's C solution of using a terminating null byte
looked as the simpliest solution, and provided also the safety that if
you lost a null byte, there should be another null byte in memory not
too far away, so everything would be ok.  But that was before paged
memory existed! (well not chronologically, but on the PDP-7/11).
Ie. basically the argument was: we're ok with buffer overflows because
they're benign on our PDP-7 in 1969.

Obviously this only argument for null-terminated strings should be
revised!


This is a place where C could be improved, and I like Objective-C
solution of providing a class (a "plug-in") to implement the
representation of string literals.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

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

#9689

Pascal,

> In case you didn't notice, the terminating null is not stored

Really ?    Good luck with "printf" -ing such a non-terminated string than. 
:-)

> or transmitted to external devices.

Wrong.    See below.

> When you display the string on a screen, print it in a printer, transmit 
> it to
> a remote terminal, etc, the null byte should not be displayed, printed

While you are right there, seeing it or not is a whole other matter.

> transmitted.

Good luck with determining where one string ends and the next one starts I 
would say. :-)

And by the way: The "nul" character was used as a short delay for the, long 
ago, mechanical(!) teletypes (no handshaking, no hold-off or buffering 
facilities) as a short delay - so that the stream of send characters could 
be continuous but the TTY had a chance to actually return is carriage and 
progres a line before type the next actual character.

And yes, once upon a time I had such a device. :-)


> So why C uses a null terminating byte for string literals?

Wrong subject I'm afraid.

Regards,
Rudy Wieser

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

#9696

"R.Wieser" <address@not.available> writes:

> Pascal,
>
>> In case you didn't notice, the terminating null is not stored
>
> Really ?    Good luck with "printf" -ing such a non-terminated string than. 
> :-)
>
>> or transmitted to external devices.
>
> Wrong.    See below.
>
>> When you display the string on a screen, print it in a printer, transmit 
>> it to
>> a remote terminal, etc, the null byte should not be displayed, printed
>
> While you are right there, seeing it or not is a whole other matter.
>
>> transmitted.
>
> Good luck with determining where one string ends and the next one starts I 
> would say. :-)
>
> And by the way: The "nul" character was used as a short delay for the, long 
> ago, mechanical(!) teletypes (no handshaking, no hold-off or buffering 
> facilities) as a short delay - so that the stream of send characters could 
> be continuous but the TTY had a chance to actually return is carriage and 
> progres a line before type the next actual character.
>
> And yes, once upon a time I had such a device. :-)

Indeed, null introduced a delay, due to the time needed to transmit it.
But it was entirely ignored (had to be), by the receiving device.

To separate your strings, you would use the US (Unit Separator) ASCII
code, or transmit a binary length first.


-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

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

#9771

Pascal,

> Indeed, null introduced a delay, due to the time needed to
> transmit it. But it was entirely ignored (had to be), by the
> receiving device.

So I may take you agree that such a nul character did indeed get send and 
that your statement that its not is false ?   Thank you.

> To separate your strings, you would use the US (Unit Separator)
> ASCII code,

For /certain types/ of old machines ?   True.

For all other machines, including most, if not all of the computers in the 
last decennia or two ?   They mostly do not even recogise that character and 
handle it the same as the nul character: displaying some kind of made-up 
glyph or simply ignoring it (as was the case for that teletype I spoke of). 
In other words: wrong again.

> or transmit a binary length first.

And than how would you than send a zero-length string ?    Yep, thats right: 
By sending one-or-more nul bytes/chars (depending on the size of the 
character-count field).   In other words, such a nul /does/ gets send in 
such a situation.

And /these/ nul characters do /not/ get ignored on reception in any way.

Which means that your "But it was entirely ignored (had to be), by the 
receiving device." is false too.

Bottom line: You have been making blanket statements on a wide range of 
machines and usages, without even considering that even their 
functioning/usage is uncomparable.

Regards,
Rudy Wieser

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

#9705

"R.Wieser" <address@not.available> writes:

>> In case you didn't notice, the terminating null is not stored
>
> Really ?    Good luck with "printf" -ing such a non-terminated string than. 
> :-)

You can safely use printf with such non-strings:

  #include <stdio.h>
  #include <string.h>
   
  int main(void)
  {
       char s[11];
       strncpy(s, "hello world", sizeof s);
       printf("%.*s\n", (int)sizeof s, s);
  }

(Your reply breaks a sentence to give it a meaning that was no intended,
but even so, I think it's useful to point out the printf can be used
with some non-strings.)

-- 
Ben.

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

#9704

On Mon, 25 Feb 2019 08:46:55 +0100
"Pascal J. Bourguignon" <pjb@informatimago.com> wrote:

> So why C uses a null terminating byte for string literals?
> The alternatives are:

	I can only give you the answer Dennis Ritchie gave me. There were
a number of factors. Using a length indicator would have meant deciding on
a size for the length which would be a machine dependent size[1]. Whatever
size of length indicator you choose has issues - use a char and on most
machines that limits you to 256 character strings, use an int on a 64 bit
machine and no string is shorter than nine bytes long (think of all those
two letter commands in unix) - remember memory was expensive and wasting it
was not sensible. Using a null terminator meant that the only limit was the
machines address range and avoided any risk of making dangerous assumptions
about the maximum possible string size.

	Finally there is the important point that C was designed for
efficiency *not* safety - the implementation of strcpy from the first
edition of K&R is gloriously efficient and did not depend on you handing
pointers to the start of the string.

strcpy(d, s)
char *d;
char *s;
{
	while (*d++ = *s++);
}

	For a more dramatic example of efficiency consider strtok(), the
routine at the heart of turning a string into argc and argv. It works by
injecting nulls into the string where the spaces are and returning an array
of pointers to the starts of the words in the original string - In other
words it turns a single string into several strings and returns them in an
array - and it does so in place without using more memory than is
absolutely essential. Doing string manipulation in place with minimal
overhead was very important at the time C was designed.

	Yes this violates several modern principles - all of which are
about preferring safety to efficiency, which in these days of pocket super
computers is laudable but in the days of souped up adding machines with
memory would have been insanely impractical.

[1] remember in C we have char is no larger than int is no larger than long
and char is big enough to hold the character set required for C source and
sizes are in terms of char. Also think how much that would impact the parts
of the compiler code that you would really like to be machine independent.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

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

#9745

Ahem A Rivet's Shot <steveo@eircom.net> writes:
[...]
> 	For a more dramatic example of efficiency consider strtok(), the
> routine at the heart of turning a string into argc and argv. It works by
> injecting nulls into the string where the spaces are and returning an array
> of pointers to the starts of the words in the original string - In other
> words it turns a single string into several strings and returns them in an
> array - and it does so in place without using more memory than is
> absolutely essential. Doing string manipulation in place with minimal
> overhead was very important at the time C was designed.

Quibble: No, strtok() doesn't return an array of pointers (for the
simple reason that a C function cannot return an array value).  It
returns a single string pointer on each call.  You have to call it
multiple times to get pointers to all the tokens.  It uses its own
static memory to keep track.

Incidentally, I don't believe strtok is used to turn a string into argc
and argv.  That's handled by the shell, and tokenizing on white space
doesn't work.  For example:

    echo arg1 'arg 2'

passes two arguments to echo, not three.  (bash does use strtok in some
places; I'm not sure just how it's used.)

[followups to comp.lang.c]

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

#9688

On 24/02/2019 22:36, R.Wieser wrote:
> Now imagine that you're programming and you /could/ be working on a 
> single-thread string, but as easily on a multi-thread one.  Wouldn't it be 
> easier to use a method which will work in either circumstance ?

Except that strn... is not guaranteed to be thread-safe.

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

#9692

Wouter,

> Except that strn... is not guaranteed to be thread-safe.

You mean that the other thread could throw the string away and invalidate 
the memory, causing "strn..." to try to access memory thats not available 
anymore ?    True.   But thats a whole other can of worms.

Besides, the resulting exception/crash would be a whole lot better than the 
silent memory overrun a non-terminated string c|would cause. :-)

Regards,
Rudy Wieser

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

#9694

On 25/02/2019 10:41, R.Wieser wrote:
> Wouter,
> 
>> Except that strn... is not guaranteed to be thread-safe.
> 
> You mean that the other thread could throw the string away and invalidate 
> the memory, causing "strn..." to try to access memory thats not available 
> anymore ?    True.   But thats a whole other can of worms.

That too.

Also that between strn... starting to do its operation and finishing it,
another thread might have grown (or shrunk) the string.

> Besides, the resulting exception/crash would be a whole lot better than the 
> silent memory overrun a non-terminated string c|would cause. :-)

Sure.

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

#9697

Wouter,

> Also that between strn... starting to do its operation and finishing
> it, another thread might have grown (or shrunk) the string.

True.   The former would result in an unterminated string (which my 
suggestion would ward against).  The latter would either return a string 
starting with the old and ending with the new, or just return the full old 
one (in other words, not a buffer overflow)

Though my take on it was more about trying to copy from strings/ string 
buffers you're not fully aware of what they contain anymore - regardless of 
in the same or another thread.

Regards,
Rudy Wieser

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

#9670

On 24/02/2019 19:02, R.Wieser wrote:
> Richard,
> 
>> Okay, so that's so obvious a retort that I have to deduce you meant
>> something else, but I don't know what. Care to explain for the benefit of
>> my befuddled grey cells?
> 
> You responded to a post in which was explained that "strncpy" could be
> dangerous because you could fill the buffer out with a too-long string,
> leaving it without a terminator.   The defensive method would be to stop
> copying before you overwrite the last byte in the target buffer - thereby
> making sure that whatever may happen, the buffer will hold a zero-terminated
> string.
> 
Assuming you bzeroed the target block before copying first. strncpy does 
npot zero terminate te target block


>> Reporting an error is certainly preferable to undefined behaviour, but I
>> would prefer to grab the data - all of it - if that's possible and
>> reasonable.
> 
> I went along with you upto-and-including the "- all of it -".  The latter
> part ?  Not so much.  Not even humans are really capable of acting
> (correctly!) on partial messages, let alone un-imaginative programs.  And
> boy, can they do a lot of damage ...
> 
Well sometimes one can say 'sorry buffer overflowed: can you resend that 
last bit"

Case where its nopt reasonable to garb all et data? well mail programs. 
I blacklist anything endi in .tv, .info, .biz and dozens of other top 
level domains that are entirely owned by spam marketing companies.

I only grab enough data to establish that before sending them packing


-- 
You can get much farther with a kind word and a gun than you can with a 
kind word alone.

Al Capone

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

#9686

TNP,

> Assuming you bzeroed the target block before copying first. strncpy does 
> not zero terminate te target block

You want to be pedantic and point out the obvious ?   No, you do not need to 
do that.  Just making sure that the /last/ character is zero will do fine.

Though I must say that I thought that "malloc" already took care of that. 
My mistake.  You would need to use "calloc" instead.

> Well sometimes one can say 'sorry buffer overflowed: can you resend that 
> last bit

Exactly.    You should /not/, as a default, just work with whatever you 
where able to copy.

> I only grab enough data to establish that before sending them packing

Bingo!  You found one of the exceptions-to-the-rule.  Well done. :-)

But tell me, how does that counter my suggestion to tell "strncpy" that the 
buffer is one char smaller than it actually is ?

Worse: it is a situation (string possibly longer than what the target buffer 
can hold) where you should actually be using it.

And do tell me: You seem to be opposing my suggestion.  Why ?   What 
/benefit/ would you gain from /not/ doing it ?

Regards,
Rudy Wieser

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

#9691

"R.Wieser" <address@not.available> writes:

> TNP,
>
>> Assuming you bzeroed the target block before copying first. strncpy does 
>> not zero terminate te target block
>
> You want to be pedantic and point out the obvious ?   No, you do not need to 
> do that.  Just making sure that the /last/ character is zero will do fine.

How do you make sure that the last character is zero?
Do you prove it mathematically? Have you tested it too?
Do you ensure it manually? Are you use you didn't miss one or made a
mistake?

Using strn with strlen is dumb.

The only way to make sure that the last character is zero is to keep the
buffer size and the string length along with the string:

typedef {
   size_t allocated;
   size_t length;
   char*  characters;
} string;

and to let the code perform the check itself!

void string_validate(string* string){
   if(string==NULL){error("null string");}
   if(string->characters==NULL){error("invalid string");
   if(string->allocated<1+string->length){error("string length too big for allocated size");}
   if(string->characters[string->length]){error("string internal representation is not null-terminated!");}
}

> But tell me, how does that counter my suggestion to tell "strncpy" that the 
> buffer is one char smaller than it actually is ?

You didn't ensure it by code.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

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

#9695

Pascal,

> How do you make sure that the last character is zero?
> Do you prove it mathematically? Have you tested it too?
> Do you ensure it manually? Are you use you didn't miss one or
> made a mistake?

The same goes for TNPs and your own code.   Funnily I do not see you have 
any problems with either of that ....

I think you are looking for a way out, and for that demand I prove 
any-and-everything.  Which makes me think its better to terminate our 
conversation before harsher words are spoken.

So, goodbye.   Have a good life and do not let the (bed) bugs bite you. :-)

Regards,
Rudy Wieser

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

#9666

"R.Wieser" <address@not.available> writes:
> (too many newsgroups, had to snip a few)
>
> Richard,
>
>> Indeed, although I'd cache the length rather than make the compiler find
>
> :-) And thats exactly the kind of thing you should try to avoid.
>
> In this simple example it will work, but you're /still/ trying to write a
> full buffers worth - when you should leave that last character untouched,
> just in case.

"Just in case" what, exactly?  Are you trying to guard against an
off-by-one error but not worry about an off-by-two error?

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

#9683

Keith,

> "Just in case" what, exactly?

"Just in case" the string you're copying is not what you expect it to be. 
I thought that would be obvious.

> Are you trying to guard against an off-by-one
> error but not worry about an off-by-two error?

Are you suggesting that I am only allowed to think about off-by-one errors 
as long as I'm also considering off-by-two (and by three, four, nine, etc. , 
power outages, disk crashes, cats peeing on keyboards) too ?   I hope not. 
:-(

But no, I was not trying to guard against especially that (see the first 
line).

Regards,
Rudy Wieser

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

#9652

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.


-- 
All political activity makes complete sense once the proposition that 
all government is basically a self-legalising protection racket, is 
fully understood.

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

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

Back to top | Article view | comp.programming

csiph-web