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

#9626 — Re: C is not a low level language

On 2/24/2019 12:11 PM, Mr. Man-wai Chang wrote:
> On 2/24/2019 4:59 AM, jacobnavia wrote:
>> http://delivery.acm.org/10.1145/3220000/3212479/p10-chisnall.pdf?ip=90.22.143.233&id=3212479&acc=OPEN&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E6D218144511F3437&__acm__=1550954647_0d9af87c752b221627509ce89da282a8
>> 
> 
> C is definitely no 4GL (4th generation language)!
> But .... many 4GLs were written in C! :)
> 

And many operating systems are written in C.
In short, C is a pillar!

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
¤£­É¶U! ¤£¶BÄF! ¤£½ä¿ú! ¤£´©¥æ! ¤£¥´¥æ! ¤£¥´§T! ¤£¦Û±þ! ¤£¨D¯«! 
½Ð¦Ò¼{ºî´© (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [next] | [standalone]

#9627

On 24/02/2019 04:40, Mr. Man-wai Chang wrote:
> On 2/24/2019 12:11 PM, Mr. Man-wai Chang wrote:
>> On 2/24/2019 4:59 AM, jacobnavia wrote:
>>> http://delivery.acm.org/10.1145/3220000/3212479/p10-chisnall.pdf?ip=90.22.143.233&id=3212479&acc=OPEN&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E6D218144511F3437&__acm__=1550954647_0d9af87c752b221627509ce89da282a8 
>>>
>>>
>>
>> C is definitely no 4GL (4th generation language)!
>> But .... many 4GLs were written in C! :)
>>
> 
> And many operating systems are written in C.
> In short, C is a pillar!
> 
Well its a very fast way to write portable assembler.

And if more programs were written in it we would have programs of one 
tenth the size runninmg ten times faster and a huge number of crap 
programmers would be flipping burgers.



-- 
Gun Control: The law that ensures that only criminals have guns.

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

#9628

On 2/24/2019 1:16 PM, The Natural Philosopher wrote:
>
> Well its a very fast way to write portable assembler.
> 
> And if more programs were written in it we would have programs of one
> tenth the size runninmg ten times faster and a huge number of crap
> programmers would be flipping burgers.

Only if programmers HONESTLY share codes and make them open source and 
free, no license crap!

But the fight between evil and good (aka security) continues anyway!

May the Force and farces be with you!

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
¤£­É¶U! ¤£¶BÄF! ¤£½ä¿ú! ¤£´©¥æ! ¤£¥´¥æ! ¤£¥´§T! ¤£¦Û±þ! ¤£¨D¯«! 
½Ð¦Ò¼{ºî´© (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

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

#9629

On 2/24/2019 1:20 PM, Mr. Man-wai Chang wrote:
> 
> But the fight between evil and good (aka security) continues anyway!
> 
> May the Force and farces be with you!
> 

Because... it's a game of chess or cards, a casino! You need opponents! ;)

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
¤£­É¶U! ¤£¶BÄF! ¤£½ä¿ú! ¤£´©¥æ! ¤£¥´¥æ! ¤£¥´§T! ¤£¦Û±þ! ¤£¨D¯«! 
½Ð¦Ò¼{ºî´© (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

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

#9640

On 2/24/2019 4:11 PM, Martin Gregorie wrote:

> 
> Do you have a scanner that picks up use of insecure library functions in
> your code? Do you patch code when the scanner spots insecure functions?
> If not, why not?
> 
> These days all my personal library functions (and many of my self-
> contained, non-trivial Java classes as well as C modules) have test
> harnesses and sets of regression tests that deal with edge cases. The
> code I write is more robust and reliable as a result. Do you do this?
> Again, if not, why not?

How do you scan and test GUI? DO you trust the GUI? :)

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
¤£­É¶U! ¤£¶BÄF! ¤£½ä¿ú! ¤£´©¥æ! ¤£¥´¥æ! ¤£¥´§T! ¤£¦Û±þ! ¤£¨D¯«! 
½Ð¦Ò¼{ºî´© (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

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

#9641

On 24/02/2019 08:11, Martin Gregorie wrote:

<snip>

> There are (relatively) simple ways to write secure code, such as always
> using the 'strn...' functions rather than the older 'str...' equivalents

This is a common misconception. The strn functions are, in some ways, 
even easier to abuse than the str functions.

Hitchens's Razor, right? Okay, my rationale is this: those who think the 
strn functions are somehow "safe" are far more likely to use them 
*instead* of taking trouble to ensure that the right amount of storage 
is allocated. And consider this:

  char s[12];
  strncpy(s, argv[1], 12);

(Heck no, of course I wouldn't do that. But people do, you know.)

The problem here is that if argv[1] is longer than 11 characters, you 
end up with no terminator on the stri... well, it's not a string because 
it doesn't have a terminator!

So much for "safe" functions.

> and *taking the trouble to size storage correctly* that make code a lot
> more bullet-proof.

This, however, is absolutely spot on.

If you don't have enough space for your data, you're going to get the 
wrong answer even if you use strn. If I'm allowed to get the wrong 
answer, I can write code that runs in almost zero time and takes almost 
zero memory.

If you take the trouble to ensure that you have enough space for your 
data, there's nothing wrong with using str.

<snip>

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

#9644

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);


-- 
To ban Christmas, simply give turkeys the vote.

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

#9647

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.


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

#9651

(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.

Ofcourse, I would rather check the length of the to-be-copied string and
throw an error when it doesn't fit, but maybe thats just me ... (Just
imagine you're copying some kind of commandline string, with a few argument
switches at the end).

Regards,
Rudy Wieser

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

#9653

On 24/02/2019 16:21, R.Wieser wrote:
> (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.
> 
> Ofcourse, I would rather check the length of the to-be-copied string and
> throw an error when it doesn't fit, but maybe thats just me ... (Just
> imagine you're copying some kind of commandline string, with a few argument
> switches at the end).
> 
That is an option if you know roughly what SHOULD be there.

> Regards,
> Rudy Wieser
> 
> 
> 
> 


-- 
"The most difficult subjects can be explained to the most slow witted 
man if he has not formed any idea of them already; but the simplest 
thing cannot be made clear to the most intelligent man if he is firmly 
persuaded that he knows already, without a shadow of doubt, what is laid 
before him."

    - Leo Tolstoy

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

#9659

TNP,

>> Ofcourse, I would rather check the length of the to-be-copied string and 
>> throw an error when it doesn't fit, but maybe thats just me ... (Just
>> imagine you're copying some kind of commandline string, with a few 
>> argument switches at the end).
>>
> That is an option if you know roughly what SHOULD be there.

You got that backwards I'm afraid: the usage of "strncpy" in a "disregard 
whatever you can't copy" way is only a good(ish) idea when you /know/ that 
what you dropped is of no consequence.

In all other circumstances letting a program (or human!) act on partial data 
will be a hommage to the old "garbage in, garbage out" saying. :-)

Regards,
Rudy Wieser

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

#9655

On 24/02/2019 16:21, R.Wieser wrote:
> (too many newsgroups, had to snip a few)

(Sorry, didn't notice. But you left comp.programming in, so we're good.)

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

That last character is the null terminator. Given the choice, that's how 
I like my strings to end. :-)

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?

> 
> Ofcourse, I would rather check the length of the to-be-copied string and
> throw an error when it doesn't fit, but maybe thats just me ... (Just
> imagine you're copying some kind of commandline string, with a few argument
> switches at the end).

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.

(There may be times when it's *not* reasonable to try to grab all the 
data - for example, if someone is deliberately throwing 
complete-Shakespeare-in-one-line at you over and over again in an 
attempt to make you consume the whole of memory. So of course you have 
to do your threat assessment: is the program going to be used in a 
context where this sort of thing is likely? If so, you need some rules 
for how much data is to be considered acceptable.)

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

#9658

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.

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

Regards,
Rudy Wieser

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

#9660

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.

With you so far...

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

But my code protected against that possibility by obtaining the length 
of the source string including terminator: len = strlen(src) + 1; and 
then allocating exactly that amount of memory via malloc, and then using 
memcpy to copy exactly that many bytes. 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. This *could* happen in a multi-threaded 
context, of course, but in a multi-threaded context one would take 
additional precautions to ensure that only one thread had access to the 
string at the point of duplication.

OR... I'm missing something! :-)

> 
>> 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, if it's impossible it's impossible and that's all there is to it. 
And I gave an example of a scenario in which an unreasonable amount of 
data could be deliberately thrown at the program with the express intent 
of consuming all available memory. 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.

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

#9661

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.

Regards,
Rudy Wieser

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

#9663

On 24/02/2019 20:36, R.Wieser wrote:
> Richard,
> 
>> But my code protected against that possibility by [snip]
> 
> Thats why I said "In this simple example it will work".

<nod>

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

I will grant that some programmers might be in that position, but I'm 
not one of them.

It has rightly been said that threading is for people who don't 
understand state machines, and state machines are for people who don't 
understand threading. I am in the latter camp!

In the more general case, however, your point is taken.

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

#9671

On 24/02/2019 20:47, Richard Heathfield wrote:
> On 24/02/2019 20:36, R.Wieser wrote:
>> Richard,
>>
>>> But my code protected against that possibility by [snip]
>>
>> Thats why I said "In this simple example it will work".
> 
> <nod>
> 
>>> 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 ?
> 
> I will grant that some programmers might be in that position, but I'm 
> not one of them.
> 
> It has rightly been said that threading is for people who don't 
> understand state machines, and state machines are for people who don't 
> understand threading. I am in the latter camp!
> 
Hey, I understand both!

And have written code to implement both!

Sometimes in the same program! That was the program that also uses longjmp()

30 subroutrines deep you are reading characters from a telex line, and 
the line drops...exit up through 30 subs? nah. set an error code 
LINE_DROP and longjmp back to an exit point, look at the error code and 
clean up the hardware and print what of the telex you did get...

I remember sitting with a telex directory deliberatrely tring to contact 
companies in equatorial africa to send them test telexes on the basis 
that they were usually only capable of sustaining a connection till the 
mext lightning strike.

No idea who they were.




> In the more general case, however, your point is taken.
> 


-- 
Socialism is the philosophy of failure, the creed of ignorance and the 
gospel of envy.

Its inherent virtue is the equal sharing of misery.

Winston Churchill

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

#9681

Richard,

> It has rightly been said that threading is for people who don't understand 
> state machines, and state machines are for people who don't understand 
> threading. I am in the latter camp!

You're only strengthening my position you know. :-)

/Especially/ when you do not know what could happen it is a good idea to be 
defensive about what you're doing.

But, do me a favour: think about the ammount of effort you would need to do 
to follow my suggestion, and the amount of fall-out you could be facing when 
the string doesn't get terminated (regardless of by mistake or by an attack) 
and compare those two.  What do you say, which of the two would "win" ?

Regards,
Rudy Wieser 

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

#9701

On 25/02/2019 07:25, R.Wieser wrote:
> Richard,
> 
>> It has rightly been said that threading is for people who don't understand
>> state machines, and state machines are for people who don't understand
>> threading. I am in the latter camp!
> 
> You're only strengthening my position you know. :-)

Hence the next sentence in my reply, which you've snipped:

"In the more general case, however, your point is taken."

> /Especially/ when you do not know what could happen it is a good idea to be
> defensive about what you're doing.

But I do know what could happen. Someone could use my code in a 
multi-threaded environment. Equally, someone could use my code and 
replace all instances of sin() with cos(), cos() with tan(), and tan() 
with sin(). Or they could change all the #defines. Or they could use the 
code in an environment where CHAR_BIT is not 8 (a restriction I regret, 
but not as much as I'd regret static arrays of, say, 16 giga-octets). Or 
they could flip a few random bits in the object code. Or they could use 
a compiler that assumes one calling convention and a linker that assumes 
a different one.

If they do any of those things, that really is their problem.

> But, do me a favour: think about the ammount of effort you would need to do
> to follow my suggestion, and the amount of fall-out you could be facing when
> the string doesn't get terminated (regardless of by mistake or by an attack)
> and compare those two.  What do you say, which of the two would "win" ?

It would have to be a mistake - that of using, in a multi-threaded 
environment, code designed for use in a single-threaded environment.

A *deliberate* single-threaded attempt to stop my code from 
null-terminating a copy of a string would fail. (If an attack is likely, 
the place to guard against it is after the length caching but before the 
malloc.)

And a deliberate *multi*-threaded attempt to attack the code would 
entail the mistake of using my code in a multi-threaded environment.

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

#9718

Richard,

> Someone could use my code in a multi-threaded environment.

/You/ brought multi-threading up, I didn't.  Solve your own problems.

Furthermore, do you think that those problems will be any different when you 
do /not/ use my suggestion ?

If not, what the fuck are you babbeling against /me/ in regard to them ? 
Dishonest much ?

tl;dr:
Try to concentrate on the difference between applying my suggestion or not. 
If you can that is.   Can you ?

Regards,
Rudy Wieser

P.s.
Yes, you pissed me off.   How did you guess ?

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

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

Back to top | Article view | comp.programming

csiph-web