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 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-03-01 20:19 +1300 |
| Message-ID | <gds4nsF7ehsU1@mid.individual.net> |
| In reply to | #141525 |
On 01/03/2019 14:54, Rick C. Hodgin wrote: > On Thursday, February 28, 2019 at 4:48:41 PM UTC-5, Bart wrote: >> On 28/02/2019 21:18, Rick C. Hodgin wrote: >>> Do you have a "Bart Compiler Debugger" that you've created, one >>> that handles Windows debug events and allows you to look at your >>> own languages' source code in your own debugger at the source >>> code level? >> >> No I've never used a debugger nor created one. > > I could not get by without one. Using a debugger is an admission of defeat... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-01 03:05 -0800 |
| Message-ID | <4945eb58-8a6b-466f-9dbf-52e0f95da0e6@googlegroups.com> |
| In reply to | #141528 |
On Friday, March 1, 2019 at 2:19:33 AM UTC-5, Ian Collins wrote: > On 01/03/2019 14:54, Rick C. Hodgin wrote: > > On Thursday, February 28, 2019 at 4:48:41 PM UTC-5, Bart wrote: > >> On 28/02/2019 21:18, Rick C. Hodgin wrote: > >>> Do you have a "Bart Compiler Debugger" that you've created... > >> No I've never used a debugger nor created one. > > I could not get by without one. > > Using a debugger is an admission of defeat... If your debugger is gdb, then I agree. :-) In the Windows developer environment we have the Visual Studio Debugger. It's one of the sole reasons I use Microsoft tools for development. Its debugger environment is unrivaled. Remote debugging, simultaneous multi-process, multi-thread debugging, edit-and-continue, exception handling, memory and watch windows that handle ad hoc expressions, a Code Definition window which tracks the text under your cursor and contextually brings up class and struct definitions in other source files, variable definitions, function definitions, class and struct definitions, etc. It's a developer's greatest asset for non-trivial development. Visual Studio 2017 has integrated gcc+gdb support now, bringing a nice skin to gdb's abilities, though it's still lacking relative to Visual Studio's native debugger. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-01 11:29 +0000 |
| Message-ID | <RI8eE.1639$bf4.687@fx18.am4> |
| In reply to | #141531 |
On 01/03/2019 11:05, Rick C. Hodgin wrote: > On Friday, March 1, 2019 at 2:19:33 AM UTC-5, Ian Collins wrote: >> On 01/03/2019 14:54, Rick C. Hodgin wrote: >>> On Thursday, February 28, 2019 at 4:48:41 PM UTC-5, Bart wrote: >>>> On 28/02/2019 21:18, Rick C. Hodgin wrote: >>>>> Do you have a "Bart Compiler Debugger" that you've created... >>>> No I've never used a debugger nor created one. >>> I could not get by without one. >> >> Using a debugger is an admission of defeat... > > > If your debugger is gdb, then I agree. :-) > > In the Windows developer environment we have the Visual Studio > Debugger. It's one of the sole reasons I use Microsoft tools for > development. Its debugger environment is unrivaled. Remote > debugging, simultaneous multi-process, multi-thread debugging, > edit-and-continue, exception handling, memory and watch windows > that handle ad hoc expressions, a Code Definition window which > tracks the text under your cursor and contextually brings up class > and struct definitions in other source files, variable definitions, > function definitions, class and struct definitions, etc. > > It's a developer's greatest asset for non-trivial development. > > Visual Studio 2017 has integrated gcc+gdb support now, bringing a > nice skin to gdb's abilities, though it's still lacking relative > to Visual Studio's native debugger. That doesn't help me because I don't code in C or C++. And if I'm debugging generated C code, then the true source is one level removed. Besides, the issues I face are somewhat different: Language/compiler X is used to build a compiler X in its own language, using X1.exe to create X2.exe (actually there are multiple generations of this). X2.exe is used to build a C compiler Y.exe, which is written in X. C compiler Y.exe is used to build Tiny C, and the resulting tcc1.exe 'works' in that it can compile and run C programs. But then tcc1.exe it used to build Tiny C again, but the new tcc2.exe doesn't work (I believe when once again applied to itself). Where is the problem? It's not in the Tiny C sources, since that works when built with a third party compiler (ie. gcc). But that is all that your fabulous debugger is going to know about. Actually, it probably won't even be able to show the sources, since my Y.exe may not include the necessary debug info when generating tcc1.exe. The true bug may have been in one of those previous steps in one of several different programs. That's one type of problem. Another is when developing using my interpreted language. Even if the interpreter is written in pure C and compiled with MSVC, the problems I'm looking for will be in the language source that is being interpreted, not the interpreter source. (And in practice, there are multiple levels involved too.) IME, the really tricky bugs are not things that are going to be helped by any debugger, even if it can directly deal with the source code where the problem lies. For example, there's a crash caused by some failure that happened in the previous one billion instructions scattered all over a 50,000 line program. Or they are intermittent. Or they disappear as soon as you apply a debugger. Or the crash occurs while it's executing an OS call. I can see one being useful for logic errors in a small test program that happens to be written in a supported language, then you can step through the code, but that's about it.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2019-03-01 12:19 +0000 |
| Subject | The extent of Rick's experience (Was: C is not a low level language) |
| Message-ID | <q5b80l$vvc$1@news.xmission.com> |
| In reply to | #141532 |
In article <RI8eE.1639$bf4.687@fx18.am4>, Bart <bc@freeuk.com> wrote:
...
(on debuggers)
>I can see one being useful for logic errors in a small test program that
>happens to be written in a supported language, then you can step through
>the code, but that's about it.
That's the extent of (and the highest thing to which he aspires) Rick's
experience and needs.
So it (using a debugger) makes sense in his context.
Don't underestimate the value of low expectations.
--
The Trump playbook. Every action by Trump or his supporters can be categorized as
one (or more) of:
outrageous, incompetent, or mentally ill.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-03-01 04:28 -0800 |
| Subject | Re: The extent of Rick's experience (Was: C is not a low level language) |
| Message-ID | <0cbe1ee8-ed8d-42fc-aedf-3fac5d237ede@googlegroups.com> |
| In reply to | #141534 |
On Friday, 1 March 2019 12:19:40 UTC, Kenny McCormack wrote: > In article <RI8eE.1639$bf4.687@fx18.am4>, Bart <bc@freeuk.com> wrote: > ... > (on debuggers) > >I can see one being useful for logic errors in a small test program that > >happens to be written in a supported language, then you can step through > >the code, but that's about it. > > That's the extent of (and the highest thing to which he aspires) Rick's > experience and needs. > > So it (using a debugger) makes sense in his context. > > Don't underestimate the value of low expectations. > Debuggers are good for "business logic" code. They're less useful for mathematical routines.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-01 04:34 -0800 |
| Subject | Re: The extent of Rick's experience (Was: C is not a low level language) |
| Message-ID | <3b9931be-7c44-4814-8b8c-5a37b1b6c64a@googlegroups.com> |
| In reply to | #141535 |
On Friday, March 1, 2019 at 7:29:12 AM UTC-5, Malcolm McLean wrote: > On Friday, 1 March 2019 12:19:40 UTC, Kenny McCormack wrote: > > In article <RI8eE.1639$bf4.687@fx18.am4>, Bart <bc@freeuk.com> wrote: > > ... > > (on debuggers) > > >I can see one being useful for logic errors in a small test program that > > >happens to be written in a supported language, then you can step through > > >the code, but that's about it. > > > > That's the extent of (and the highest thing to which he aspires) Rick's > > experience and needs. > > > > So it (using a debugger) makes sense in his context. > > > > Don't underestimate the value of low expectations. > > Debuggers are good for "business logic" code. They're less useful for > mathematical routines. They're good for everything. Single-stepping through code allows you to identify where things go awry. I'm amazed to hear people make these statements about the limited usefulness of debuggers. I will admit that if you're fully cogni- zant of your surroundings and developmental environment you can write code that is without error, but with dylexia I introduce some errors I don't even see with code review (because I typed them wrong, and in my thinking meant something different from what I typed), and with interruptions from co-workers coming in, and the required business meetings, etc., it's hard to keep it all in your mind without error continuously. Debuggers make life significantly easier. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-01 04:32 -0800 |
| Message-ID | <6da8b57a-b12a-4293-ac46-dd579c6dab04@googlegroups.com> |
| In reply to | #141532 |
On Friday, March 1, 2019 at 6:30:00 AM UTC-5, Bart wrote:
> That doesn't help me because I don't code in C or C++.
What do you code in, Bart?
RDC, CAlive, Visual FreePro, Visual FreePro, Jr., Logician, and
many other tools I've written, are all coded in a combination
of C/C++. I use Visual Studio to debug that code.
> The true bug may have been in one of those previous steps in one of
> several different programs.
That's where a debugger comes into play.
> That's one type of problem. Another is when developing using my
> interpreted language. Even if the interpreter is written in pure C and
> compiled with MSVC, the problems I'm looking for will be in the language
> source that is being interpreted, not the interpreter source. (And in
> practice, there are multiple levels involved too.)
You can examine where the interpreter is doing something unexpected
or incorrectly. Or even to validate what it is doing, that it is,
in fact, correct.
> IME, the really tricky bugs are not things that are going to be helped
> by any debugger, even if it can directly deal with the source code where
> the problem lies. For example, there's a crash caused by some failure
> that happened in the previous one billion instructions scattered all
> over a 50,000 line program.
I have one program I've chased a bug for 5+ years. Still haven't
found it. I've used various code profilers Microsoft's own code
analysis feature, set warning levels to maximum, tried finding the
bug in GCC, added code to analyze buffer overrun writes, memory
leaks, etc., and I still can't find it.
I don't know where it's coming from, and it doesn't appear to be
anything obvious in code or the profilers would've found it. I
am able to work-around it by allocating extra bytes before and
after each variable, so it's a non-issue in production, but the
bug remains.
I haven't spent exhaustively on it, but I have spent more than a
couple weeks installing the various tools and profiling the code
over the several years.
> Or they are intermittent. Or they disappear as soon as you apply a
> debugger. Or the crash occurs while it's executing an OS call.
I have some bugs which appear under optimization that do not appear
without optimization. I can only think of one off the top of my
head, and I'm sure it's due to some UB I've coded in there, but I
don't know where it is, and again the code profilers I've tried do
not find it.
> I can see one being useful for logic errors in a small test program that
> happens to be written in a supported language, then you can step through
> the code, but that's about it.
You should watch a tutorial on Visual Studio debugging and see
how it can benefit you.
WinDbg also has a nice feature now called Time Travel Debugging,
where the runtime full capture of every instruction, every piece
of memory and register for your app running is captured. It has
about a 20x performance hit, but you can run your app, get to
the point where it failed, and then open up the environment in
WinDbg and then set breakpoints on conditions where the error
occurred, and go backwards, to see what events led up to the
failure.
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview
It's quite a thing ... these debuggers.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-01 14:28 +0100 |
| Message-ID | <q5bc17$qaa$1@dont-email.me> |
| In reply to | #141536 |
On 01/03/2019 13:32, Rick C. Hodgin wrote: > On Friday, March 1, 2019 at 6:30:00 AM UTC-5, Bart wrote: >> That doesn't help me because I don't code in C or C++. > > What do you code in, Bart? > > RDC, CAlive, Visual FreePro, Visual FreePro, Jr., Logician, and > many other tools I've written, are all coded in a combination > of C/C++. I use Visual Studio to debug that code. > >> The true bug may have been in one of those previous steps in one of >> several different programs. > > That's where a debugger comes into play. > >> That's one type of problem. Another is when developing using my >> interpreted language. Even if the interpreter is written in pure C and >> compiled with MSVC, the problems I'm looking for will be in the language >> source that is being interpreted, not the interpreter source. (And in >> practice, there are multiple levels involved too.) > > You can examine where the interpreter is doing something unexpected > or incorrectly. Or even to validate what it is doing, that it is, > in fact, correct. > >> IME, the really tricky bugs are not things that are going to be helped >> by any debugger, even if it can directly deal with the source code where >> the problem lies. For example, there's a crash caused by some failure >> that happened in the previous one billion instructions scattered all >> over a 50,000 line program. > > I have one program I've chased a bug for 5+ years. Still haven't > found it. I've used various code profilers Microsoft's own code > analysis feature, set warning levels to maximum, tried finding the > bug in GCC, added code to analyze buffer overrun writes, memory > leaks, etc., and I still can't find it. > > I don't know where it's coming from, and it doesn't appear to be > anything obvious in code or the profilers would've found it. I > am able to work-around it by allocating extra bytes before and > after each variable, so it's a non-issue in production, but the > bug remains. It sounds like you are facing a "something has changed this variable, but I don't know what" bug. Usually that means a pointer or access error in a completely different part of the program that is stomping on an innocent variable, which is when you see the effect. These can be hard to find, since the symptoms appear in a very different place from the actual error. I can't tell you how to hunt this using MS's tools - I don't use them myself. But I can give you some pointers from the gcc world, and you can maybe do something similar here. First, make sure you generate a map file for the project link. Look at the variable where you see the problem. Look for arrays that come before it in memory - there is a fair chance you are seeing a buffer overrun of one of these. Second, use sanitizers, especially -fsanitize=address and -fsanitize=undefined. There is a reasonable chance that these will spot the problem and halt with a diagnostic when it first hits. Thirdly, use watchpoints in the debugger. If your variable "foo" is supposed to be in the range 0..3, and something is setting it to 100, then in gdb you'd write: watch foo if (foo > 3) When something stores a value greater than 3 to foo, the debugger will stop. > > I haven't spent exhaustively on it, but I have spent more than a > couple weeks installing the various tools and profiling the code > over the several years. > >> Or they are intermittent. Or they disappear as soon as you apply a >> debugger. Or the crash occurs while it's executing an OS call. > > I have some bugs which appear under optimization that do not appear > without optimization. I can only think of one off the top of my > head, and I'm sure it's due to some UB I've coded in there, but I > don't know where it is, and again the code profilers I've tried do > not find it. Almost all "it works when optimisation is disabled" problems are due to undefined behaviour in the code. Prime causes are integer overflow and type alias errors (these can often be found by static analysis with the right tools and options). Again, sanitizers could be helpful. Profilers are not debugging tools - I don't know why you are trying to use them here. > >> I can see one being useful for logic errors in a small test program that >> happens to be written in a supported language, then you can step through >> the code, but that's about it. > > You should watch a tutorial on Visual Studio debugging and see > how it can benefit you. > It doesn't work for my usual targets, so it is of no use to me. But if other people find it useful, great. > WinDbg also has a nice feature now called Time Travel Debugging, > where the runtime full capture of every instruction, every piece > of memory and register for your app running is captured. It has > about a 20x performance hit, but you can run your app, get to > the point where it failed, and then open up the environment in > WinDbg and then set breakpoints on conditions where the error > occurred, and go backwards, to see what events led up to the > failure. > > https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview > > It's quite a thing ... these debuggers. > There are a variety of ways to do "reverse debugging", with different mixes of pros and cons.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-03-01 15:57 +0200 |
| Message-ID | <6cqnkf-tv4.ln1@gangtai.home.grep.be> |
| In reply to | #141536 |
On 1/03/2019 14:32, Rick C. Hodgin wrote: > I have one program I've chased a bug for 5+ years. Still haven't > found it. I've used various code profilers Microsoft's own code > analysis feature, set warning levels to maximum, tried finding the > bug in GCC, added code to analyze buffer overrun writes, memory > leaks, etc., and I still can't find it. > > I don't know where it's coming from, and it doesn't appear to be > anything obvious in code or the profilers would've found it. I > am able to work-around it by allocating extra bytes before and > after each variable, so it's a non-issue in production, but the > bug remains. That sounds like a buffer-overflow thing, which is the kind of thing that valgrind is *very* good at helping you hunt down. Have you tried that? http://valgrind.org/
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-01 06:24 -0800 |
| Message-ID | <1b7447e6-fbc4-4481-8a28-28c30d7070e1@googlegroups.com> |
| In reply to | #141546 |
On Friday, March 1, 2019 at 8:59:15 AM UTC-5, Wouter Verhelst wrote: > On 1/03/2019 14:32, Rick C. Hodgin wrote: > > I have one program I've chased a bug for 5+ years. Still haven't > > found it. I've used various code profilers Microsoft's own code > > analysis feature, set warning levels to maximum, tried finding the > > bug in GCC, added code to analyze buffer overrun writes, memory > > leaks, etc., and I still can't find it. > > > > I don't know where it's coming from, and it doesn't appear to be > > anything obvious in code or the profilers would've found it. I > > am able to work-around it by allocating extra bytes before and > > after each variable, so it's a non-issue in production, but the > > bug remains. > > That sounds like a buffer-overflow thing, which is the kind of thing > that valgrind is *very* good at helping you hunt down. Have you tried that? I'm positive it is because when I pad the variables with the extra leading and trailing space there's no issue. But, I can't find it. > http://valgrind.org/ I haven't used valgrind. I tried to get it setup at one point, but the version I found was rather old and wouldn't work prop- erly on my dev environment (at the time Windows 7). I've compiled it into GCC and used various sanitizers. I've used that guy's tool who consistently advertises his app on the comp.lang.c++ group. I can't remember the name, but I tried his tool on it. He found the most issues of all, but most of the results were false positives, such as my app having a i() and ii() functions, so that ii() functions are known to have already passed through a validation verifying pointers are valid, and so on, so they don't need to be tested before use. His tool would report those as possible null pointer deferences, etc. I've used several plugins which replace memory allocation functions with their own memory engines, and other ones which report memory leaks or unclosed memory blocks. These have helped find some bugs, but not this particular one. When Visual Studio 2015 and 2017 came out I used their code analyzers on it as well. They found several things that were issues that could theoretically occur (they would not occur in regular code), and others that weren't really issues like the other guy's tool, but even in most of those cases I tried to "correct" the code so the analyzer wouldn't identify them as issues any longer. I wrote my own malloc(), realloc(), and free() functions (those are the only ones I use in my app), and, at the suggestion of someone here in comp.lang.c I think (maybe clc++), added signed memory before and after each legitimate write space, and even virtual guard pages beyond each allocated block, and didn't find the error. I did get a much faster memory allocation algorithm out of it though. It shows up in debug mode and release mode, so I'm pretty sure it's a real bug somewhere. On the day I find it I'm planning to cele- brate. :-) -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-04 09:21 +0100 |
| Message-ID | <q5in6a$ahi$1@dont-email.me> |
| In reply to | #141550 |
On 01/03/2019 15:24, Rick C. Hodgin wrote: > On Friday, March 1, 2019 at 8:59:15 AM UTC-5, Wouter Verhelst wrote: >> On 1/03/2019 14:32, Rick C. Hodgin wrote: >>> I have one program I've chased a bug for 5+ years. Still haven't >>> found it. I've used various code profilers Microsoft's own code >>> analysis feature, set warning levels to maximum, tried finding the >>> bug in GCC, added code to analyze buffer overrun writes, memory >>> leaks, etc., and I still can't find it. >>> >>> I don't know where it's coming from, and it doesn't appear to be >>> anything obvious in code or the profilers would've found it. I >>> am able to work-around it by allocating extra bytes before and >>> after each variable, so it's a non-issue in production, but the >>> bug remains. >> >> That sounds like a buffer-overflow thing, which is the kind of thing >> that valgrind is *very* good at helping you hunt down. Have you tried that? > > I'm positive it is because when I pad the variables with the extra > leading and trailing space there's no issue. But, I can't find > it. > >> http://valgrind.org/ > > I haven't used valgrind. I tried to get it setup at one point, > but the version I found was rather old and wouldn't work prop- > erly on my dev environment (at the time Windows 7). > > I've compiled it into GCC and used various sanitizers. > Tools like sanitizers and valgrind often round up allocation sizes, perhaps to lumps of 64 bytes (check the particular tools for details). This means if you have an array of 100 32-bit words, you could overrun it by 12 entries before a tool with a 64-byte block will spot it. And I think the most common overruns are off-by-one errors, and thus harder to find. Also, some of these tools are only for dynamically allocated memory - the problem here may lie with access to statically allocated memory. If that is the case, then a study of the linker map file is the first step. I mentioned that before, but you haven't shown the results of such checks.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-04 11:23 +0100 |
| Message-ID | <q5iubc$g6i$2@dont-email.me> |
| In reply to | #141658 |
On 04/03/2019 09:21, David Brown wrote: > On 01/03/2019 15:24, Rick C. Hodgin wrote: >> On Friday, March 1, 2019 at 8:59:15 AM UTC-5, Wouter Verhelst wrote: >>> On 1/03/2019 14:32, Rick C. Hodgin wrote: >>>> I have one program I've chased a bug for 5+ years. Still haven't >>>> found it. I've used various code profilers Microsoft's own code >>>> analysis feature, set warning levels to maximum, tried finding the >>>> bug in GCC, added code to analyze buffer overrun writes, memory >>>> leaks, etc., and I still can't find it. >>>> >>>> I don't know where it's coming from, and it doesn't appear to be >>>> anything obvious in code or the profilers would've found it. I >>>> am able to work-around it by allocating extra bytes before and >>>> after each variable, so it's a non-issue in production, but the >>>> bug remains. >>> >>> That sounds like a buffer-overflow thing, which is the kind of thing >>> that valgrind is *very* good at helping you hunt down. Have you tried that? >> >> I'm positive it is because when I pad the variables with the extra >> leading and trailing space there's no issue. But, I can't find >> it. >> >>> http://valgrind.org/ >> >> I haven't used valgrind. I tried to get it setup at one point, >> but the version I found was rather old and wouldn't work prop- >> erly on my dev environment (at the time Windows 7). >> >> I've compiled it into GCC and used various sanitizers. >> > > Tools like sanitizers and valgrind often round up allocation sizes, > perhaps to lumps of 64 bytes (check the particular tools for details). > This means if you have an array of 100 32-bit words, you could overrun > it by 12 entries before a tool with a 64-byte block will spot it. And I > think the most common overruns are off-by-one errors, and thus harder to > find. > > Also, some of these tools are only for dynamically allocated memory - > the problem here may lie with access to statically allocated memory. If > that is the case, then a study of the linker map file is the first step. > I mentioned that before, but you haven't shown the results of such checks. > I have just used gdb watchpoints to catch a buffer overrun error in some code on an embedded ARM device. It worked like a charm. (Valgrind would not have helped, as this is not dynamic memory, and many of the gcc sanitizers can't work on such small systems with no MMU.)
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-03-04 14:47 +0000 |
| Message-ID | <slrnq7qekf.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #141658 |
On Mon, 2019-03-04, David Brown wrote: > On 01/03/2019 15:24, Rick C. Hodgin wrote: >> On Friday, March 1, 2019 at 8:59:15 AM UTC-5, Wouter Verhelst wrote: ... >>> http://valgrind.org/ >> >> I haven't used valgrind. I tried to get it setup at one point, >> but the version I found was rather old and wouldn't work prop- >> erly on my dev environment (at the time Windows 7). Rick, you must be thinking of some other software, because the home page says "Windows is not under consideration because porting to it would require so many changes it would almost be a separate project." Someone here pointed to a Windows tool under development; maybe that's what you were trying to build? I forget its name. >> I've compiled it into GCC and used various sanitizers. >> > > Tools like sanitizers and valgrind often round up allocation sizes, > perhaps to lumps of 64 bytes (check the particular tools for details). > This means if you have an array of 100 32-bit words, you could overrun > it by 12 entries before a tool with a 64-byte block will spot it. And I > think the most common overruns are off-by-one errors, and thus harder to > find. For valgrind --memcheck, I don't recognize that at all. I'd be very disappointed if it hid off-by-one errors. > Also, some of these tools are only for dynamically allocated memory - > the problem here may lie with access to statically allocated memory. Yeah. In the valgrind --memcheck case, IIUC, those segments are seen as just an opaque chunk of initialized memory. Similarly with the stack. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-03-04 15:58 +0100 |
| Message-ID | <q5jee7$k0v$1@dont-email.me> |
| In reply to | #141665 |
On 04/03/2019 15:47, Jorgen Grahn wrote: > On Mon, 2019-03-04, David Brown wrote: >> Tools like sanitizers and valgrind often round up allocation sizes, >> perhaps to lumps of 64 bytes (check the particular tools for details). >> This means if you have an array of 100 32-bit words, you could overrun >> it by 12 entries before a tool with a 64-byte block will spot it. And I >> think the most common overruns are off-by-one errors, and thus harder to >> find. > > For valgrind --memcheck, I don't recognize that at all. I'd be very > disappointed if it hid off-by-one errors. > I don't know the details (these kind of tools are rarely or never supported on my typical targets), so you'll know better than me. I just know that at least some of these tools are implemented by using MMU tricks, such as putting each allocation in its own segment, or allocating inaccessible pages above and below each allocation. This gives very fast checking, at the expense of wasted memory, and it the limited granularity of the MMU means limited granularity of the checking. Perhaps Valgrind uses other techniques. Or perhaps it has to use large granularity allocations but instead of returning a pointer to the start of the memory block, it moves it further up so that the end of the array matches the end of the checked block (since +1 overruns are more common than -1 underruns).
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-04 07:02 -0800 |
| Message-ID | <0640ac26-9fd0-4a9f-bfbf-0b7886220090@googlegroups.com> |
| In reply to | #141665 |
On Monday, March 4, 2019 at 9:47:52 AM UTC-5, Jorgen Grahn wrote:
> > On 01/03/2019 15:24, Rick C. Hodgin wrote:
> >> On Friday, March 1, 2019 at 8:59:15 AM UTC-5, Wouter Verhelst wrote:
> >>> http://valgrind.org/
> >>
> >> I haven't used valgrind. I tried to get it setup at one point,
> >> but the version I found was rather old and wouldn't work prop-
> >> erly on my dev environment (at the time Windows 7).
>
> Rick, you must be thinking of some other software, because the home
> page says "Windows is not under consideration because porting to it
> would require so many changes it would almost be a separate project."
>
> Someone here pointed to a Windows tool under development; maybe that's
> what you were trying to build? I forget its name.
A company I worked at in 2006-2007 used it, and I thought it was
valgrind, but it's apparently another name I was thinking of.
I did find that you can use valgrind under Windows however:
http://www.albertgao.xyz/2016/09/28/how-to-use-valgrind-on-windows/
I wonder what I'm thinking of now. Are there Windows-based checkers
like this that worked back in the early 2000s but no longer work
under Windows? I would've bet money it was valgrind. Hmmm...
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2019-03-05 06:36 +0000 |
| Message-ID | <slrnq7s67g.4jo.grahn+nntp@frailea.sa.invalid> |
| In reply to | #141667 |
On Mon, 2019-03-04, Rick C. Hodgin wrote: > On Monday, March 4, 2019 at 9:47:52 AM UTC-5, Jorgen Grahn wrote: >> > On 01/03/2019 15:24, Rick C. Hodgin wrote: >> >> On Friday, March 1, 2019 at 8:59:15 AM UTC-5, Wouter Verhelst wrote: >> >>> http://valgrind.org/ >> >> >> >> I haven't used valgrind. I tried to get it setup at one point, >> >> but the version I found was rather old and wouldn't work prop- >> >> erly on my dev environment (at the time Windows 7). >> >> Rick, you must be thinking of some other software, because the home >> page says "Windows is not under consideration because porting to it >> would require so many changes it would almost be a separate project." >> >> Someone here pointed to a Windows tool under development; maybe that's >> what you were trying to build? I forget its name. > > A company I worked at in 2006-2007 used it, and I thought it was > valgrind, but it's apparently another name I was thinking of. Purify, maybe. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-05 05:14 -0800 |
| Message-ID | <e7be2797-6281-4a8f-bf32-19b0b617801e@googlegroups.com> |
| In reply to | #141681 |
On Tuesday, March 5, 2019 at 1:36:40 AM UTC-5, Jorgen Grahn wrote: > On Mon, 2019-03-04, Rick C. Hodgin wrote: > > On Monday, March 4, 2019 at 9:47:52 AM UTC-5, Jorgen Grahn wrote: > >> > On 01/03/2019 15:24, Rick C. Hodgin wrote: > >> >> On Friday, March 1, 2019 at 8:59:15 AM UTC-5, Wouter Verhelst wrote: > >> >>> http://valgrind.org/ > >> >> > >> >> I haven't used valgrind. I tried to get it setup at one point, > >> >> but the version I found was rather old and wouldn't work prop- > >> >> erly on my dev environment (at the time Windows 7). > >> > >> Rick, you must be thinking of some other software, because the home > >> page says "Windows is not under consideration because porting to it > >> would require so many changes it would almost be a separate project." > >> > >> Someone here pointed to a Windows tool under development; maybe that's > >> what you were trying to build? I forget its name. > > > > A company I worked at in 2006-2007 used it, and I thought it was > > valgrind, but it's apparently another name I was thinking of. > > Purify, maybe. I'm 99% convinced it was Valgrind. I tried to get information about it at the time, but the group doing the debugging and unit testing in that area were separate from my dev group, and they weren't the most forthcoming. The code we wrote was all C++ code, so maybe they had a develop- ment environment on a Linux machine which would simulate enough Windows-based functions that they could perform tests on the rest of the more generic C++ algorithms. They brought us periodic fixes to introduce into our code. I can't remember for certain, but I am 99% sure it was Valgrind. And I'm also 90% sure it was a Windows box, but I don't know. I may have been assuming things that weren't really there based on our app being a Windows-based app. Regardless, the company I work for now has blocked the Microsoft Store on our work computers, so I'm having a difficult time getting the Ubuntu subsystem for Windows installed. I'd really like to be able to use the Google sanitizer tools, as well as Valgrind, to try and track down this bug. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | jadill33@gmail.com |
|---|---|
| Date | 2019-03-05 05:44 -0800 |
| Message-ID | <55b134d5-f14a-4d95-83c3-cd7f0f85ec78@googlegroups.com> |
| In reply to | #141687 |
On Tuesday, March 5, 2019 at 8:14:36 AM UTC-5, Rick C. Hodgin wrote: > On Tuesday, March 5, 2019 at 1:36:40 AM UTC-5, Jorgen Grahn wrote: > > On Mon, 2019-03-04, Rick C. Hodgin wrote: > > > On Monday, March 4, 2019 at 9:47:52 AM UTC-5, Jorgen Grahn wrote: > > >> > On 01/03/2019 15:24, Rick C. Hodgin wrote: > > >> >> On Friday, March 1, 2019 at 8:59:15 AM UTC-5, Wouter Verhelst wrote: > > >> >>> http://valgrind.org/ > > >> >> > > >> >> I haven't used valgrind. I tried to get it setup at one point, > > >> >> but the version I found was rather old and wouldn't work prop- > > >> >> erly on my dev environment (at the time Windows 7). > > >> > > >> Rick, you must be thinking of some other software, because the home > > >> page says "Windows is not under consideration because porting to it > > >> would require so many changes it would almost be a separate project." > > >> > > >> Someone here pointed to a Windows tool under development; maybe that's > > >> what you were trying to build? I forget its name. > > > > > > A company I worked at in 2006-2007 used it, and I thought it was > > > valgrind, but it's apparently another name I was thinking of. > > > > Purify, maybe. > > > I'm 99% convinced it was Valgrind. I tried to get information > about it at the time, but the group doing the debugging and unit > testing in that area were separate from my dev group, and they > weren't the most forthcoming. > > The code we wrote was all C++ code, so maybe they had a develop- > ment environment on a Linux machine which would simulate enough > Windows-based functions that they could perform tests on the > rest of the more generic C++ algorithms. > > They brought us periodic fixes to introduce into our code. > > I can't remember for certain, but I am 99% sure it was Valgrind. > And I'm also 90% sure it was a Windows box, but I don't know. > I may have been assuming things that weren't really there based > on our app being a Windows-based app. > > Regardless, the company I work for now has blocked the Microsoft > Store on our work computers, so I'm having a difficult time > getting the Ubuntu subsystem for Windows installed. I'd really > like to be able to use the Google sanitizer tools, as well as > Valgrind, to try and track down this bug. You can also try dmalloc. I've used that on Windows though it's not as feature rich as valgrind. Best regards, John D.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-03-05 16:47 -0800 |
| Message-ID | <7f8151d2-b963-411c-968e-e8654b9157f2@googlegroups.com> |
| In reply to | #141689 |
On Tuesday, March 5, 2019 at 8:45:53 AM UTC-5, jadi...@gmail.com wrote: > You can also try dmalloc. I've used that on Windows though it's not as > feature rich as valgrind. John, I'll check it out. Also, I've been able to get Ubuntu installed in Windows. Have been able to access bash, and run sudo apt-get install build- essential and other apps, including subversion and download the source for valgrind and compile it. In bash I'm able to run both Windows and Linux apps. I'm not sure if it's running in WINE or not yet, but it's interesting. I was able to install cgdb and have a console-based gdb wrapper, which was nice. I'll see how it goes. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-03-01 14:02 +0000 |
| Message-ID | <oYaeE.2191$MT2.130@fx21.am4> |
| In reply to | #141536 |
On 01/03/2019 12:32, Rick C. Hodgin wrote: > On Friday, March 1, 2019 at 6:30:00 AM UTC-5, Bart wrote: >> That doesn't help me because I don't code in C or C++. > > What do you code in, Bart? > > RDC, CAlive, Visual FreePro, Visual FreePro, Jr., Logician, and > many other tools I've written, are all coded in a combination > of C/C++. I use Visual Studio to debug that code. > >> The true bug may have been in one of those previous steps in one of >> several different programs. > > That's where a debugger comes into play. > >> That's one type of problem. Another is when developing using my >> interpreted language. Even if the interpreter is written in pure C and >> compiled with MSVC, the problems I'm looking for will be in the language >> source that is being interpreted, not the interpreter source. (And in >> practice, there are multiple levels involved too.) > > You can examine where the interpreter is doing something unexpected > or incorrectly. Or even to validate what it is doing, that it is, > in fact, correct. The interpreter itself, or the program it's trying to execute? You want to debugger to work with the latter if it's application error. Your debuggers don't work with interpreted code; those that do, will be for a specific language, not mine. >> IME, the really tricky bugs are not things that are going to be helped >> by any debugger, even if it can directly deal with the source code where >> the problem lies. For example, there's a crash caused by some failure >> that happened in the previous one billion instructions scattered all >> over a 50,000 line program. > > I have one program I've chased a bug for 5+ years. My worst ones might involve a couple of days' entertaining sport hunting them down. Which is actually more fun than when everything works perfectly (which means you have to get on with the next lot of routine work). But 5 years? I'm actually impressed. > You should watch a tutorial on Visual Studio debugging and see > how it can benefit you. I find VS completely unusable. I don't even know to to build and run hello.c with it. (Somebody kindly posted some instructions once, but I've lost them.) If I inadvertently select something that invokes VS, then it takes a minute and a half before I can shut it down again. It's a monster. However, I have sometimes needed to correlate an address where a program crashes, with source code. Then I have used VS for that once or twice, but it will only give me the machine instructions at around that point, which can be enough to find that pattern in my ASM file, and from there to my source code. That would be a useful add-on to one of my own tools. So there are a few useful things that can be done, but I don't need a full debugger. > WinDbg also has a nice feature now called Time Travel Debugging, > where the runtime full capture of every instruction, every piece > of memory and register for your app running is captured. It has > about a 20x performance hit, but you can run your app, get to > the point where it failed, and then open up the environment in > WinDbg and then set breakpoints on conditions where the error > occurred, and go backwards, to see what events led up to the > failure. > > https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/time-travel-debugging-overview > > It's quite a thing ... these debuggers. > The last real app I worked on was last century. There I'd offloaded most of the functionality into add-on interpreted scripts. If a module failed, it reported that, but you were still inside the running app with the same data present. You could edit and re-run the module from the app's command line. Now that was a nice way to work.
[toc] | [prev] | [next] | [standalone]
Page 5 of 16 — ← Prev page 1 … 3 4 [5] 6 7 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web