Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #141169 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2019-02-23 21:59 +0100 |
| Last post | 2019-03-01 19:30 +0100 |
| Articles | 20 on this page of 308 — 53 participants |
Back to article view | Back to comp.lang.c
C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-23 21:59 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-23 22:02 +0100
Re: C is not a low level language Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-02-23 16:05 -0500
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-24 08:37 +0100
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 12:12 +0800
Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 12:11 +0800
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 "R.Wieser" <address@not.available> - 2019-02-25 09:19 +0100
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 09:41 +0100
Re: C is not a low level language Mateusz Viste <mateusz@wont.tell> - 2019-02-25 09:01 +0000
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 01:55 -0800
Re: C is not a low level language James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-25 10:24 -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 James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-25 10:31 -0800
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 Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 22:57 +0000
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 James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-25 10:46 -0800
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:34 +0200
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 already5chosen@yahoo.com - 2019-02-25 08:48 -0800
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 already5chosen@yahoo.com - 2019-02-26 00:29 -0800
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-26 01:33 -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 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-28 13:18 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-28 21:48 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-28 17:54 -0800
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-03-01 20:19 +1300
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 03:05 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-03-01 11:29 +0000
The extent of Rick's experience (Was: C is not a low level language) gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-01 12:19 +0000
Re: The extent of Rick's experience (Was: C is not a low level language) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-03-01 04:28 -0800
Re: The extent of Rick's experience (Was: C is not a low level language) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 04:34 -0800
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 04:32 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-01 14:28 +0100
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-03-01 15:57 +0200
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 06:24 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-04 09:21 +0100
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-04 11:23 +0100
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-04 14:47 +0000
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-04 15:58 +0100
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-04 07:02 -0800
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-05 06:36 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-05 05:14 -0800
Re: C is not a low level language jadill33@gmail.com - 2019-03-05 05:44 -0800
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-05 16:47 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-03-01 14:02 +0000
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-03-01 15:50 +0200
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 06:11 -0800
Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-03-01 16:50 +0200
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 07:22 -0800
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 07:24 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-03 19:55 +0100
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-03-02 08:39 +1300
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-03-02 08:37 +1300
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-01 11:43 -0800
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-03-02 07:20 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-02 04:18 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-03-02 12:28 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-02 05:19 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-03-02 23:47 +0000
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-03-02 18:24 -0800
Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-03-02 16:02 +0100
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-03-03 06:53 +1300
Yep, I'm not surprised. (Was: C is not a low level language) gazelle@shell.xmission.com (Kenny McCormack) - 2019-03-01 07:31 +0000
Re: C is not a low level language Wes Newell <w.newell@tx.rr.com> - 2019-03-01 06:13 +0000
Re: C is not a low level language Wes Newell <w.newell@tx.rr.com> - 2019-03-01 06:11 +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 already5chosen@yahoo.com - 2019-02-26 01:35 -0800
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 fir <profesor.fir@gmail.com> - 2019-02-27 07:20 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-27 07:36 -0800
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 already5chosen@yahoo.com - 2019-02-25 02:43 -0800
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 fir <profesor.fir@gmail.com> - 2019-02-24 04:33 -0800
Re: C is not a low level language lonelydad <lonelydad58@gmail.com> - 2019-02-24 14:44 +0000
You were not meant to undersand this was: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-26 09:47 -0800
Re: You were not meant to undersand this was: C is not a low level language pjp <pjpoirier_is_located@hotmail.com> - 2019-02-26 16:05 -0400
Re: C is not a low level language luser droog <luser.droog@gmail.com> - 2019-02-26 20:16 -0800
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 fir <profesor.fir@gmail.com> - 2019-02-24 04:57 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 05:15 -0800
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 already5chosen@yahoo.com - 2019-02-25 09:00 -0800
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 already5chosen@yahoo.com - 2019-02-26 01:58 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 12:19 +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 already5chosen@yahoo.com - 2019-02-25 10:01 -0800
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 already5chosen@yahoo.com - 2019-02-26 09:04 -0800
Re: C is not a low level language Robert Wessel <robertwessel2@yahoo.com> - 2019-02-26 13:25 -0600
Re: C is not a low level language Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-26 09:16 -0800
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 already5chosen@yahoo.com - 2019-02-26 10:29 -0800
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 already5chosen@yahoo.com - 2019-02-27 03:29 -0800
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 10:26 -0800
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-26 12:41 -0800
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 mark.bluemel@gmail.com - 2019-02-25 07:24 -0800
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
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 09:51 +0100
Re: C is not a low level language Melzzzzz <Melzzzzz@zzzzz.com> - 2019-02-24 09:37 +0000
Re: C is not a low level language Ian Collins <ian-news@hotmail.com> - 2019-02-24 22:52 +1300
Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-24 11:13 +0000
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 16:30 +0100
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 07:50 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 08:14 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 08:29 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 09:00 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-24 17:16 +0100
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 08:42 -0800
Re: C is not a low level language bart4858@gmail.com - 2019-02-24 09:38 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 10:09 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 10:13 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 10:23 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 10:48 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-24 19:07 +0000
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 11:10 -0800
Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-24 19:19 +0000
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-25 10:32 -0800
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 20:49 +0100
Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 12:59 -0800
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 18:02 +0100
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-24 21:56 +0100
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 23:00 +0100
Re: C is not a low level language BGB <cr88192@hotmail.com> - 2019-02-28 17:07 -0600
Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-24 20:34 +0000
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 23:04 +0100
Re: C is not a low level language already5chosen@yahoo.com - 2019-02-24 14:29 -0800
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-25 07:12 +0100
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-24 10:41 +0000
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 06:47 -0800
Re: C is not a low level language Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-24 17:30 +0000
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-24 16:32 +0100
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-24 03:19 -0800
Re: C is not a low level language fir <profesor.fir@gmail.com> - 2019-02-24 04:29 -0800
Re: C is not a low level language Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-02-24 11:11 -0500
Re: C is not a low level language Rosario19 <Ros@invalid.invalid> - 2019-02-25 12:57 +0100
Re: C is not a low level language "l.s." <l.s@cryptolab.net> - 2019-02-28 19:17 +0100
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-02-28 21:09 +0100
Re: C is not a low level language "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-28 13:20 -0800
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-01 10:27 +0100
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-03-01 14:18 +0100
Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-03-01 15:10 +0100
Re: C is not a low level language jacobnavia <jacob@jacob.remcomp.fr> - 2019-03-01 19:30 +0100
Page 3 of 16 — ← Prev page 1 2 [3] 4 5 … 16 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-25 13:36 -0800 |
| Message-ID | <lnva17o8jh.fsf@kst-u.example.com> |
| In reply to | #141304 |
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]
| From | Ahem A Rivet's Shot <steveo@eircom.net> |
|---|---|
| Date | 2019-02-25 22:57 +0000 |
| Message-ID | <20190225225753.db2d1b8eb0ba448a47c89003@eircom.net> |
| In reply to | #141359 |
On Mon, 25 Feb 2019 13:36:02 -0800 Keith Thompson <kst-u@mib.org> wrote: > 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. You are quite right of course. It's been a long time since I used it. > Incidentally, I don't believe strtok is used to turn a string into argc > and argv. Perhaps not now but AIUI that was its original purpose. -- 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]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-02-25 10:29 +0200 |
| Message-ID | <ejlckf-vvf.ln1@gangtai.home.grep.be> |
| In reply to | #141245 |
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]
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2019-02-25 09:41 +0100 |
| Message-ID | <q509o2$l6p$1@gioia.aioe.org> |
| In reply to | #141281 |
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]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-02-25 10:55 +0200 |
| Message-ID | <k5nckf-hgh.ln1@gangtai.home.grep.be> |
| In reply to | #141286 |
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]
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2019-02-25 10:24 +0100 |
| Message-ID | <q50c82$10ri$1@gioia.aioe.org> |
| In reply to | #141287 |
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]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-25 10:46 -0800 |
| Message-ID | <53063d30-df5d-40e6-a20d-0f20c6eb4402@googlegroups.com> |
| In reply to | #141286 |
On Monday, February 25, 2019 at 3:41:45 AM UTC-5, 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. > > 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 The current version of the C standard says the following about ALL functions in the C standard library in section 7.1.4: "4 The functions in the standard library are not guaranteed to be reentrant and may modify objects with static or thread storage duration. 188) 5 Unless explicitly stated otherwise in the detailed descriptions that follow, library functions shall prevent data races as follows: A library function shall not directly or indirectly access objects accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function’s arguments. A library function shall not directly or indirectly modify objects accessible by threads other than the current thread unless the objects are accessed directly or indirectly via the function’s non-const arguments. 189) Implementations may share their own internal objects between threads if the objects are not visible to users and are protected against data races. 6 Unless otherwise specified, library functions shall perform all operations solely within the current thread if those operations have effects that are visible to users. 190)" With respect to paragraph 5 above: nothing is "otherwise stated" anywhere in section 7.24, covering <string.h>, and therefore in particular strncpy(). That's a lot more than it said in previous versions of the standard - Wouter might have been thinking about those earlier versions, rather than the current one. However, I'm not an expert on writing multi- threaded code. I'm therefore not sure whether what it currently says about those functions would be sufficient to make Wouter be willing to label strncpy() "thread-safe".
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-02-26 12:34 +0200 |
| Message-ID | <o9hfkf-319.ln1@gangtai.home.grep.be> |
| In reply to | #141355 |
On 25/02/2019 20:46, James Kuyper wrote: > 5 Unless explicitly stated otherwise in the detailed descriptions that > follow, library functions shall prevent data races as follows: A library > function shall not directly or indirectly access objects accessible by > threads other than the current thread unless the objects are accessed > directly or indirectly via the function’s arguments. This is the critical bit: "unless the objects are accessed directly or indirectly via the function's arguments". What that means is that the function can access whatever was passed to it through its arguments, and assume that it won't change over the course of its run. If, however, the arguments do change (like, say, another thread overwriting the string pointed to by one of the arguments with a longer or shorter value), then undefined behaviour results.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2019-02-24 21:03 +0000 |
| Message-ID | <q4v0s0$533$1@dont-email.me> |
| In reply to | #141236 |
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]
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2019-02-25 08:58 +0100 |
| Message-ID | <q5077m$9k6$1@gioia.aioe.org> |
| In reply to | #141257 |
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]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-02-25 09:40 +0100 |
| Message-ID | <m2zhqk6z33.fsf@despina.home> |
| In reply to | #141279 |
"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]
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2019-02-25 10:01 +0100 |
| Message-ID | <q50asp$qis$1@gioia.aioe.org> |
| In reply to | #141284 |
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]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-24 12:55 -0800 |
| Message-ID | <lnk1hoq53j.fsf@kst-u.example.com> |
| In reply to | #141219 |
"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]
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2019-02-25 08:31 +0100 |
| Message-ID | <q505jt$2g0$1@gioia.aioe.org> |
| In reply to | #141251 |
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]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2019-02-24 17:42 +0000 |
| Message-ID | <q4ul2i$leb$1@dont-email.me> |
| In reply to | #141208 |
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]
| 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 | #141226 |
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]
| From | Bill Findlay <findlaybill@blueyonder.co.uk> |
|---|---|
| Date | 2019-02-24 17:56 +0000 |
| Message-ID | <0001HW.2223125A02182A717000059092EF@news.individual.net> |
| In reply to | #141208 |
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]
| 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 | #141228 |
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]
| 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 | #141234 |
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]
| 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 | #141228 |
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]
Page 3 of 16 — ← Prev page 1 2 [3] 4 5 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web