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 2 of 16 — ← Prev page 1 [2] 3 4 … 16 Next page →
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2019-02-24 21:36 +0100 |
| Message-ID | <q4uv8j$v0m$1@gioia.aioe.org> |
| In reply to | #141241 |
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]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2019-02-24 20:47 +0000 |
| Message-ID | <q4uvt3$trh$1@dont-email.me> |
| In reply to | #141245 |
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]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2019-02-24 21:10 +0000 |
| Message-ID | <q4v18d$7ls$1@dont-email.me> |
| In reply to | #141247 |
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]
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2019-02-25 08:25 +0100 |
| Message-ID | <q5059c$12g$1@gioia.aioe.org> |
| In reply to | #141247 |
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]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2019-02-25 12:24 +0000 |
| Message-ID | <q50mp7$gvu$1@dont-email.me> |
| In reply to | #141274 |
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]
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2019-02-25 17:04 +0100 |
| Message-ID | <q513ll$g85$1@gioia.aioe.org> |
| In reply to | #141301 |
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]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2019-02-25 16:52 +0000 |
| Message-ID | <q516gm$o88$1@dont-email.me> |
| In reply to | #141319 |
On 25/02/2019 16:04, R.Wieser wrote: > Richard, > >> Someone could use my code in a multi-threaded environment. > > /You/ brought multi-threading up, I didn't. Indeed. I was trying to imagine a situation in which the code I'd posted could break, and that was the only one I could come up with. > Solve your own problems. I do. That isn't one of my problems. The rest of your reply suggests that we're not going to have a pleasant discussion, so I'll stop there. <nonsense snipped> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-24 17:59 -0800 |
| Message-ID | <lna7ikpr05.fsf@kst-u.example.com> |
| In reply to | #141245 |
"R.Wieser" <address@not.available> writes:
[...]
> True. But that only goes as far as the programmer can imagine such attacks.
> "strncpy" is ment as a "last ditch" effort to safeguard against the
> /unforseen/ circumstances which could lead to memory/stack being clobbered.
> My suggestion to provide it an argument that is one less than what the
> buffer can actually hold is just an extension on that.
No, strncpy is designed to work with a specific (and, in recent
history, rare) data structure, namely a fixed-length character
array containing some bytes of meaningful data padded to the end
by zero or more null bytes. (I believe it was used to store file
names in Unix directory entries.)
(followups to comp.lang.c only)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2019-02-25 09:19 +0100 |
| Message-ID | <q508f8$fam$1@gioia.aioe.org> |
| In reply to | #141268 |
Keith, > No, strncpy is designed to work with a specific (and, in > recent history, rare) data structure, namely a fixed-length > character array Yes, that is the, very old, description/explanation to it. Its /desiged to/ (according to the description) to work on fixed-length strings /that are not necessarily zero-terminated/. Q1: When was the last time you used it for such strings / for that purpose ? Q2: would that not mean that /you/ would need to append a string terminator (even just to be able to "printf" it) ? And to be blunt about it, for that case you would not even need a "strncpy", as just copying the whole block of memory the string is in (to a block of empty memory one char larger ofcourse) would be sufficient. And faster! Besides, you yourself already have shown that you use that function differently than its intended usage ... Regards, Rudy Wieser
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-02-25 09:41 +0100 |
| Message-ID | <m2va186z0g.fsf@despina.home> |
| In reply to | #141280 |
"R.Wieser" <address@not.available> writes:
> Keith,
>
>> No, strncpy is designed to work with a specific (and, in
>> recent history, rare) data structure, namely a fixed-length
>> character array
>
> Yes, that is the, very old, description/explanation to it. Its /desiged
> to/ (according to the description) to work on fixed-length strings /that are
> not necessarily zero-terminated/.
>
> Q1: When was the last time you used it for such strings / for that purpose ?
>
> Q2: would that not mean that /you/ would need to append a string terminator
> (even just to be able to "printf" it) ?
The bug is not in strncpy, but in printf, which takes null-terminated
strings, instead of objects of type typedef struct {
size_t allocated;
size_t length;
char* characters;
} string;
--
__Pascal J. Bourguignon__
http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@wont.tell> |
|---|---|
| Date | 2019-02-25 09:01 +0000 |
| Message-ID | <5c73aee0$0$31401$426a74cc@news.free.fr> |
| In reply to | #141285 |
On Mon, 25 Feb 2019 09:41:35 +0100, Pascal J. Bourguignon wrote:
> The bug is not in strncpy, but in printf, which takes null-terminated
> strings, instead of objects of type typedef struct {
> size_t allocated;
> size_t length;
> char* characters;
> } string;
That would be truly wasteful. Besides, lack of a string type is one of
the many things that makes for C beauty and simplicity. If unhappy, then
just use Pascal, or some other poor man's language :)
The problem of strncpy() is not in strncpy() itself, but simply in its
name, that may confuse the padawan programmer into falling into the
comfortable belief that strncpy() is to strcpy() what snprintf() is to
sprintf() or strncat() to strcat().
Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-25 01:55 -0800 |
| Message-ID | <lnzhqknqew.fsf@kst-u.example.com> |
| In reply to | #141280 |
"R.Wieser" <address@not.available> writes:
>> No, strncpy is designed to work with a specific (and, in
>> recent history, rare) data structure, namely a fixed-length
>> character array
>
> Yes, that is the, very old, description/explanation to it. Its /desiged
> to/ (according to the description) to work on fixed-length strings /that are
> not necessarily zero-terminated/.
So you agree?
> Q1: When was the last time you used it for such strings / for that purpose ?
I'm not sure that I ever have.
> Q2: would that not mean that /you/ would need to append a string terminator
> (even just to be able to "printf" it) ?
Of course I'd need to ensure that the target is null-terminated if I
wanted to use its contents *as a string*. In practice, I'd just use
something other than strncpy.
> And to be blunt about it, for that case you would not even need a "strncpy",
> as just copying the whole block of memory the string is in (to a block of
> empty memory one char larger ofcourse) would be sufficient. And faster!
>
> Besides, you yourself already have shown that you use that function
> differently than its intended usage ...
I don't know what you're referring to. I haven't said that I use
strncpy at all.
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-25 10:24 -0800 |
| Message-ID | <e0434581-8ad5-4d1e-b648-b3d3d613394f@googlegroups.com> |
| In reply to | #141280 |
On Monday, February 25, 2019 at 3:20:00 AM UTC-5, R.Wieser wrote: > Keith, > > > No, strncpy is designed to work with a specific (and, in > > recent history, rare) data structure, namely a fixed-length > > character array > > Yes, that is the, very old, description/explanation to it. Its /desiged > to/ (according to the description) to work on fixed-length strings /that are > not necessarily zero-terminated/. > > Q1: When was the last time you used it for such strings / for that purpose ? May, last year. The externally imposed file formats that the files produced by my code are required to match specify precisely that data structure for much of the text that they contain (most of the file contents are in integer or floating point format, text appears only as annotations). > Q2: would that not mean that /you/ would need to append a string terminator > (even just to be able to "printf" it) ? No - in precisely those situations where snprintf() would fail to write a terminating null character, manually appending a null character would place it in a position in the file that is reserved for some other field. You know that the end of the string has occurred because the file format specifies a fixed length that should either contain a string padded at the end with nulls, or a string that occupies the entire space set aside to hold that string. Such files can only be read by code that knows the format, and therefore knows what that fixed length is. It's often the case when reading such fields that you would append a null character to create a string usable with C standard library string routines, but that's not the case when writing such fields. > And to be blunt about it, for that case you would not even need a "strncpy", > as just copying the whole block of memory the string is in (to a block of > empty memory one char larger ofcourse) would be sufficient. And faster! Actually, that's not normally the case. The sources for the text that is supposed to go into the fixed-length text field are often null- terminated and followed by other data which should NOT be copied into the end of the fixed-length text field - it's either uninitialized memory or memory being used for some other purpose. The text field in the file should be null-padded, even if the source for that information is not. Now, of course I could reformat the source by padding it with null characters as needed before using memcpy(). But why should I do so, when that's exactly what strncpy() will end up doing as part of the copy process? > Besides, you yourself already have shown that you use that function > differently than its intended usage ... He never said that he used it at all - the need doesn't come up in the kinds of programming he does. Few people do need to do that kind of programming - but I do, and I use strncpy() precisely as intended.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-02-25 08:46 +0100 |
| Message-ID | <m24l8s8g40.fsf@despina.home> |
| In reply to | #141245 |
"R.Wieser" <address@not.available> writes: > Richard, > >> But my code protected against that possibility by [snip] > > Thats why I said "In this simple example it will work". > >> The only way this could break would be if the source string grew between >> two consecutive lines of code that did not grow that string. > > In your example ? Yes (and the same as I was thinking). > > Now imagine that you're programming and you /could/ be working on a > single-thread string, but as easily on a multi-thread one. Wouldn't it be > easier to use a method which will work in either circumstance ? > >> If these circumstances are at all likely, it seems to me that it is better >> to protect against them than to succumb blindly to them. > > True. But that only goes as far as the programmer can imagine such attacks. > "strncpy" is ment as a "last ditch" effort to safeguard against the > /unforseen/ circumstances which could lead to memory/stack being clobbered. > My suggestion to provide it an argument that is one less than what the > buffer can actually hold is just an extension on that. > > Personally I would not mind at all when it would throw or return an error > when the target buffer was found to be too small for the source string. It > should never happen, and for that reason should not be silently ignored > either. But thats just my take on it, YMMV. Sorry to interject this important argument so deep in an unrelated thread, but In case you didn't notice, the terminating null is not stored or transmitted to external devices. When you display the string on a screen, print it in a printer, transmit it to a remote terminal, etc, the null byte should not be displayed, printed, transmitted. It is NOT part of the string. So why C uses a null terminating byte for string literals? The alternatives are: - pascal strings: a length prefix (but is it a byte, a word, a long? In "modern" pascal implementations all those variants are possisble. - no length, but a different type, and a stringly typed language that let you copy the literal only to an array of the same size (eg. Modula-2, IIRC). - a designated string class used to implement strings (eg. Objective-C; it's even customizable in Objective-C, since the specific string class can be specified as argument to the compiler). you can notice that 1960's C solution of using a terminating null byte looked as the simpliest solution, and provided also the safety that if you lost a null byte, there should be another null byte in memory not too far away, so everything would be ok. But that was before paged memory existed! (well not chronologically, but on the PDP-7/11). Ie. basically the argument was: we're ok with buffer overflows because they're benign on our PDP-7 in 1969. Obviously this only argument for null-terminated strings should be revised! This is a place where C could be improved, and I like Objective-C solution of providing a class (a "plug-in") to implement the representation of string literals. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2019-02-25 09:36 +0100 |
| Message-ID | <q509ec$jsj$1@gioia.aioe.org> |
| In reply to | #141277 |
Pascal, > In case you didn't notice, the terminating null is not stored Really ? Good luck with "printf" -ing such a non-terminated string than. :-) > or transmitted to external devices. Wrong. See below. > When you display the string on a screen, print it in a printer, transmit > it to > a remote terminal, etc, the null byte should not be displayed, printed While you are right there, seeing it or not is a whole other matter. > transmitted. Good luck with determining where one string ends and the next one starts I would say. :-) And by the way: The "nul" character was used as a short delay for the, long ago, mechanical(!) teletypes (no handshaking, no hold-off or buffering facilities) as a short delay - so that the stream of send characters could be continuous but the TTY had a chance to actually return is carriage and progres a line before type the next actual character. And yes, once upon a time I had such a device. :-) > So why C uses a null terminating byte for string literals? Wrong subject I'm afraid. Regards, Rudy Wieser
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-02-25 10:13 +0100 |
| Message-ID | <m2mumk6xju.fsf@despina.home> |
| In reply to | #141282 |
"R.Wieser" <address@not.available> writes: > Pascal, > >> In case you didn't notice, the terminating null is not stored > > Really ? Good luck with "printf" -ing such a non-terminated string than. > :-) > >> or transmitted to external devices. > > Wrong. See below. > >> When you display the string on a screen, print it in a printer, transmit >> it to >> a remote terminal, etc, the null byte should not be displayed, printed > > While you are right there, seeing it or not is a whole other matter. > >> transmitted. > > Good luck with determining where one string ends and the next one starts I > would say. :-) > > And by the way: The "nul" character was used as a short delay for the, long > ago, mechanical(!) teletypes (no handshaking, no hold-off or buffering > facilities) as a short delay - so that the stream of send characters could > be continuous but the TTY had a chance to actually return is carriage and > progres a line before type the next actual character. > > And yes, once upon a time I had such a device. :-) Indeed, null introduced a delay, due to the time needed to transmit it. But it was entirely ignored (had to be), by the receiving device. To separate your strings, you would use the US (Unit Separator) ASCII code, or transmit a binary length first. -- __Pascal J. Bourguignon__ http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
| From | "R.Wieser" <address@not.available> |
|---|---|
| Date | 2019-02-26 09:56 +0100 |
| Message-ID | <q52uvg$r1v$1@gioia.aioe.org> |
| In reply to | #141291 |
Pascal, > Indeed, null introduced a delay, due to the time needed to > transmit it. But it was entirely ignored (had to be), by the > receiving device. So I may take you agree that such a nul character did indeed get send and that your statement that its not is false ? Thank you. > To separate your strings, you would use the US (Unit Separator) > ASCII code, For /certain types/ of old machines ? True. For all other machines, including most, if not all of the computers in the last decennia or two ? They mostly do not even recogise that character and handle it the same as the nul character: displaying some kind of made-up glyph or simply ignoring it (as was the case for that teletype I spoke of). In other words: wrong again. > or transmit a binary length first. And than how would you than send a zero-length string ? Yep, thats right: By sending one-or-more nul bytes/chars (depending on the size of the character-count field). In other words, such a nul /does/ gets send in such a situation. And /these/ nul characters do /not/ get ignored on reception in any way. Which means that your "But it was entirely ignored (had to be), by the receiving device." is false too. Bottom line: You have been making blanket statements on a wide range of machines and usages, without even considering that even their functioning/usage is uncomparable. Regards, Rudy Wieser
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-25 14:12 +0000 |
| Message-ID | <87k1ho2c03.fsf@bsb.me.uk> |
| In reply to | #141282 |
"R.Wieser" <address@not.available> writes:
>> In case you didn't notice, the terminating null is not stored
>
> Really ? Good luck with "printf" -ing such a non-terminated string than.
> :-)
You can safely use printf with such non-strings:
#include <stdio.h>
#include <string.h>
int main(void)
{
char s[11];
strncpy(s, "hello world", sizeof s);
printf("%.*s\n", (int)sizeof s, s);
}
(Your reply breaks a sentence to give it a meaning that was no intended,
but even so, I think it's useful to point out the printf can be used
with some non-strings.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-25 10:31 -0800 |
| Message-ID | <4f74dd52-44a6-48d3-a345-3eb63d5ce406@googlegroups.com> |
| In reply to | #141282 |
On Monday, February 25, 2019 at 3:36:36 AM UTC-5, R.Wieser wrote: ... > Good luck with determining where one string ends and the next one starts I > would say. :-) If the format for the data says that the first string should be null- padded, if necessary, to fill exactly 8 bytes, and that the next string starts immediately after that, there is very little trouble determining where the first string ends: after 8 bytes or before a null character, whichever comes first. Nor is there any difficulty in determining where the next one starts: it starts 8 bytes after the first string, regardless of any intervening null characters. I've lots of experience with data in formats like this. It isn't a particularly convenient format to parse using C standard library string functions, but neither is it extraordinarily difficult to deal with.
[toc] | [prev] | [next] | [standalone]
| From | Ahem A Rivet's Shot <steveo@eircom.net> |
|---|---|
| Date | 2019-02-25 12:20 +0000 |
| Message-ID | <20190225122040.a476b092a257d6c0a3100deb@eircom.net> |
| In reply to | #141277 |
On Mon, 25 Feb 2019 08:46:55 +0100
"Pascal J. Bourguignon" <pjb@informatimago.com> wrote:
> So why C uses a null terminating byte for string literals?
> The alternatives are:
I can only give you the answer Dennis Ritchie gave me. There were
a number of factors. Using a length indicator would have meant deciding on
a size for the length which would be a machine dependent size[1]. Whatever
size of length indicator you choose has issues - use a char and on most
machines that limits you to 256 character strings, use an int on a 64 bit
machine and no string is shorter than nine bytes long (think of all those
two letter commands in unix) - remember memory was expensive and wasting it
was not sensible. Using a null terminator meant that the only limit was the
machines address range and avoided any risk of making dangerous assumptions
about the maximum possible string size.
Finally there is the important point that C was designed for
efficiency *not* safety - the implementation of strcpy from the first
edition of K&R is gloriously efficient and did not depend on you handing
pointers to the start of the string.
strcpy(d, s)
char *d;
char *s;
{
while (*d++ = *s++);
}
For a more dramatic example of efficiency consider strtok(), the
routine at the heart of turning a string into argc and argv. It works by
injecting nulls into the string where the spaces are and returning an array
of pointers to the starts of the words in the original string - In other
words it turns a single string into several strings and returns them in an
array - and it does so in place without using more memory than is
absolutely essential. Doing string manipulation in place with minimal
overhead was very important at the time C was designed.
Yes this violates several modern principles - all of which are
about preferring safety to efficiency, which in these days of pocket super
computers is laudable but in the days of souped up adding machines with
memory would have been insanely impractical.
[1] remember in C we have char is no larger than int is no larger than long
and char is big enough to hold the character set required for C source and
sizes are in terms of char. Also think how much that would impact the parts
of the compiler code that you would really like to be machine independent.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
[toc] | [prev] | [next] | [standalone]
Page 2 of 16 — ← Prev page 1 [2] 3 4 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web