Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #129945 > unrolled thread
| Started by | Real Troll <real.troll@trolls.com> |
|---|---|
| First post | 2018-04-30 02:10 +0000 |
| Last post | 2018-05-01 13:46 +0000 |
| Articles | 20 on this page of 208 — 30 participants |
Back to article view | Back to comp.lang.c
The case AGAINST C Real Troll <real.troll@trolls.com> - 2018-04-30 02:10 +0000
Re: The case AGAINST C cross@spitfire.i.gajendra.net (Dan Cross) - 2018-04-30 03:14 +0000
Re: The case AGAINST C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-30 05:48 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 14:58 +0100
Re: The case AGAINST C Davs <johndemeert0@gmail.com> - 2018-05-07 04:18 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 05:26 -0700
Re: The case AGAINST C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-07 11:21 -0400
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 09:21 -0700
Re: The case AGAINST C Robert Wessel <robertwessel2@yahoo.com> - 2018-05-07 12:13 -0500
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 10:24 -0700
Re: The case AGAINST C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-07 13:27 -0400
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-07 17:33 +0000
Re: The case AGAINST C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-07 13:50 -0400
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 10:56 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 09:26 +0200
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 09:19 +0200
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-08 00:42 -0700
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 06:54 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-08 07:24 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 17:15 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 09:31 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 18:48 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 10:33 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 23:36 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 15:08 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 00:56 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 16:17 -0700
Re: The case AGAINST C Geoff <geoff@invalid.invalid> - 2018-05-08 11:09 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 23:43 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-08 15:24 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 00:58 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-09 08:11 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 08:51 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 11:45 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 13:03 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 23:40 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-09 15:48 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-10 13:48 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-10 08:28 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-11 10:06 +0200
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-11 02:22 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-11 05:29 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-11 13:31 +0000
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-11 15:47 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-11 09:16 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-12 17:43 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-12 14:06 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-10 00:13 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-10 01:31 -0700
Re: The case AGAINST C Wouter Verhelst <w@uter.be> - 2018-05-11 18:01 +0200
Re: The case AGAINST C Geoff <geoff@invalid.invalid> - 2018-05-10 08:30 -0700
Re: The case AGAINST C Wouter Verhelst <w@uter.be> - 2018-05-09 09:29 +0200
Re: The case AGAINST C Geoff <geoff@invalid.invalid> - 2018-05-10 08:41 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-11 04:43 -0700
Re: The case AGAINST C Richard Damon <Richard@Damon-Family.org> - 2018-05-08 21:24 -0400
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-09 09:10 +0200
Re: The case AGAINST C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-08 19:52 +0000
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-08 23:48 +0200
Re: The case AGAINST C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-29 22:07 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 12:22 +0100
Re: The case AGAINST C Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-30 12:08 +0000
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 13:38 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-30 06:05 -0700
Re: The case AGAINST C supercat@casperkitty.com - 2018-04-30 07:39 -0700
Re: The case AGAINST C Ed Kellett <e@kellett.im> - 2018-04-30 15:53 +0100
Re: The case AGAINST C supercat@casperkitty.com - 2018-04-30 08:14 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-30 21:26 -0700
Re: The case AGAINST C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-30 09:00 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-01 04:58 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-04-30 18:07 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 05:33 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 05:58 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 06:27 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 14:37 +0100
Re: The case AGAINST C Melzzzzz <Melzzzzz@zzzzz.com> - 2018-05-01 13:41 +0000
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 16:48 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-01 10:11 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 11:00 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 19:26 +0100
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-01 11:40 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 12:53 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 22:03 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-02 09:10 +1200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-01 14:21 -0700
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-02 09:26 +1200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-01 15:23 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-02 14:07 +0000
Re: The case AGAINST C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-03 06:28 +0000
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-01 23:03 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-02 04:52 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-02 05:12 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 05:34 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-02 14:08 +0000
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 07:39 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 17:13 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 11:01 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 21:51 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-03 08:52 +1200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 22:42 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-03 09:57 +1200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 23:22 +0100
Re: The case AGAINST C Ian Collins <ian-news@hotmail.com> - 2018-05-03 10:29 +1200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 00:14 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 03:59 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 04:15 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 12:50 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-03 13:36 -0700
Of course I get it... (Was: The case AGAINST C) gazelle@shell.xmission.com (Kenny McCormack) - 2018-05-03 08:44 +0000
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-03 12:42 +0000
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 05:52 -0700
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-03 12:56 +0000
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-03 05:58 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 14:36 +0100
Re: The case AGAINST C already5chosen@yahoo.com - 2018-05-03 13:27 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-03 22:43 +0100
Re: The case AGAINST C already5chosen@yahoo.com - 2018-05-03 15:17 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 00:50 +0100
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-03 15:41 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-04 11:36 +0200
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-04 08:52 -0700
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-04 17:28 +0000
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-04 12:06 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-05 18:45 +0200
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-06 18:43 +0000
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-06 23:35 +0200
Re: The case AGAINST C scott@slp53.sl.home (Scott Lurndal) - 2018-05-07 13:23 +0000
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 06:30 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-07 16:25 +0200
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 07:32 -0700
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 09:09 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 18:12 +0100
Global variables bartc <bc@freeuk.com> - 2018-05-06 14:07 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 20:03 +0200
Re: Global variables Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-06 15:21 -0400
Re: Global variables Keith Thompson <kst-u@mib.org> - 2018-05-06 13:07 -0700
Re: Global variables Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-06 16:13 -0400
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:39 +0200
Re: Global variables Richard Damon <Richard@Damon-Family.org> - 2018-05-06 17:50 -0400
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:57 +0200
Re: Global variables Richard Damon <Richard@Damon-Family.org> - 2018-05-06 19:56 -0400
Re: Global variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-05-07 03:21 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-07 09:09 +0200
Re: Global variables Keith Thompson <kst-u@mib.org> - 2018-05-07 08:49 -0700
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 20:55 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:51 +0200
Re: Global variables Keith Thompson <kst-u@mib.org> - 2018-05-06 15:40 -0700
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 23:54 +0100
Re: Global variables Ian Collins <ian-news@hotmail.com> - 2018-05-07 15:12 +1200
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-07 09:03 +0200
Re: Global variables Tim Rentsch <txr@alumni.caltech.edu> - 2018-05-18 20:23 -0700
Re: Global variables Steve Carroll <frelwizzen@gmail.com> - 2018-05-18 20:44 -0700
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-19 17:22 +0200
Re: Global variables supercat@casperkitty.com - 2018-05-19 11:56 -0700
Re: Global variables supercat@casperkitty.com - 2018-05-06 16:28 -0700
Re: Global variables Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-05-06 14:19 -0400
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 20:16 +0100
Re: Global variables David Brown <david.brown@hesbynett.no> - 2018-05-06 23:09 +0200
Re: Global variables bartc <bc@freeuk.com> - 2018-05-06 23:41 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-03 09:13 -0700
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-03 17:29 +0000
Re: The case AGAINST C gazelle@shell.xmission.com (Kenny McCormack) - 2018-05-03 19:24 +0000
Re: The case AGAINST C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-04 05:46 +0000
Re: The case AGAINST C Dan Purgert <dan@djph.net> - 2018-05-04 10:55 +0000
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 04:03 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 12:31 +0100
Re: The case AGAINST C already5chosen@yahoo.com - 2018-05-04 05:10 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 13:24 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 06:26 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 06:35 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 07:06 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 07:19 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 06:37 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 08:19 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 12:07 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 16:31 +0100
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 08:41 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 09:50 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 10:04 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 13:51 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-04 14:30 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 15:14 -0700
Re: The case AGAINST C Robert Wessel <robertwessel2@yahoo.com> - 2018-05-04 11:18 -0500
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 09:05 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 17:55 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 10:54 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 19:18 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-04 11:24 -0700
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-06 16:45 +0200
Re: The case AGAINST C jameskuyper@alumni.caltech.edu - 2018-05-04 11:51 -0700
Re: The case AGAINST C supercat@casperkitty.com - 2018-05-04 12:15 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-04 21:56 +0100
Re: The case AGAINST C David Brown <david.brown@hesbynett.no> - 2018-05-06 17:01 +0200
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-06 17:54 +0100
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-06 13:38 -0700
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-06 21:49 +0100
Re: The case AGAINST C Richard Damon <Richard@Damon-Family.org> - 2018-05-06 17:19 -0400
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-06 15:24 -0700
Re: The case AGAINST C Keith Thompson <kst-u@mib.org> - 2018-05-06 15:16 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-06 23:55 -0700
Re: The case AGAINST C Steve Carroll <frelwizzen@gmail.com> - 2018-05-06 11:59 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 14:51 -0700
Re: The case AGAINST C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-02 04:46 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 11:45 -0700
Re: The case AGAINST C fir <profesor.fir@gmail.com> - 2018-05-01 06:10 -0700
Re: The case AGAINST C C W Rose <cwr@seckford.org> - 2018-05-02 15:23 +0100
Re: The case AGAINST C bartc <bc@freeuk.com> - 2018-05-02 17:36 +0100
Re: The case AGAINST C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-04-30 22:03 +0800
Re: The case AGAINST C Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2018-05-01 13:46 +0000
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-08 09:31 -0700 |
| Message-ID | <8509bd56-f315-4a5b-838a-f4f16c176973@googlegroups.com> |
| In reply to | #130349 |
On Tuesday, May 8, 2018 at 10:15:51 AM UTC-5, David Brown wrote: > On 08/05/18 15:54, supercat@casperkitty.com wrote: > > Speed isn't the only issue. > > It is the excuse invariably used. The common case is that some > microcontrollers have a watchdog that is enabled at reset (a bad idea - > it's better to have a more reliable reset controller) with a short > timeout (an idiotic idea), and then to say that zeroing out large arrays > would take too long before main() is called and the user can kick the > watchdog. The sane solutions are to have watchdog control configured by > the C startup code, or to have a hook to allow user code to fix the > watchdog before the zeroing of the array. Having a watchdog enabled by startup code is a bad idea, because it means that glitches near startup (which in some cases may be the most likely time to have glitches) could leave the system inoperable for an arbitrarily long time. Having a user-code hook which would execute before C language initialization is the best approach. Too bad there's no standard for such things. > > On many platforms, various conditions may > > cause or require the processor to be reset while RAM holds useful > > information. > > Every embedded toolchain has a way to define areas of ram that is not > cleared or initialised at reset. It is very rare that these are needed > anyway. It is certainly not a justification for failing to clear bss data. The fact that an implementation that behaves a certain way may be more useful for some purposes than one which doesn't is a perfectly fine justification for implementations targeting those purposes to behave in such fashion, or at least be configurable to do so. Having a standard way to distinguish objects that must be cleared, those that must not, and those that may be cleared or not at the implementation's convenience, would be helpful. All systems could accommodate at least the first and third, and if a piece of code requires the second but an implementation cannot support it, having compilation fail outright would be better than generating code that won't work. > > Perhaps that could have been handled by having Standard > > suggest that objects which are qualified "volatile" may be initialized > > or not at the implementation's discretion since, an implementation would > > be allowed to change them at will, and there would be no C-observable > > difference between initializing them and then spontaneously setting them > > back to their previous value, versus simply leaving them holding whatever > > they held at the time the CPU was reset. > > No, it should not be connected to "volatile" in any way. Having some > standardised way to say that a particular variable should not be > initialised at startup might be nice, but I don't think the lack of > standardisation is a problem to anyone. I think the Standard would *allow* an implementation to treat "volatile" in such fashion. I think having a different standard way of indicating that would probably be better, but what's important is that some means exists.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-08 18:48 +0200 |
| Message-ID | <pcskda$ppp$1@dont-email.me> |
| In reply to | #130350 |
On 08/05/18 18:31, supercat@casperkitty.com wrote: > On Tuesday, May 8, 2018 at 10:15:51 AM UTC-5, David Brown wrote: >> On 08/05/18 15:54, supercat@casperkitty.com wrote: >>> Speed isn't the only issue. >> >> It is the excuse invariably used. The common case is that some >> microcontrollers have a watchdog that is enabled at reset (a bad idea - >> it's better to have a more reliable reset controller) with a short >> timeout (an idiotic idea), and then to say that zeroing out large arrays >> would take too long before main() is called and the user can kick the >> watchdog. The sane solutions are to have watchdog control configured by >> the C startup code, or to have a hook to allow user code to fix the >> watchdog before the zeroing of the array. > > Having a watchdog enabled by startup code is a bad idea, because it means > that glitches near startup (which in some cases may be the most likely time > to have glitches) could leave the system inoperable for an arbitrarily long > time. Agreed. It is also a PITA. Watchdogs in general are rarely a good idea. They make sense if you have flaky hardware, but it is best to get better hardware if possible. Otherwise they mostly just make bugs harder to trace. > > Having a user-code hook which would execute before C language initialization > is the best approach. Too bad there's no standard for such things. User-code hooks are a good approach. There is no need for a standard, as such things are inherently non-portable. Having a standard would reduce the learning curve slightly when starting work on a new target or new toolchain, but it is not a significant factor. > >>> On many platforms, various conditions may >>> cause or require the processor to be reset while RAM holds useful >>> information. >> >> Every embedded toolchain has a way to define areas of ram that is not >> cleared or initialised at reset. It is very rare that these are needed >> anyway. It is certainly not a justification for failing to clear bss data. > > The fact that an implementation that behaves a certain way may be more > useful for some purposes than one which doesn't is a perfectly fine > justification for implementations targeting those purposes to behave in > such fashion, or at least be configurable to do so. That would be true - except failing to clear the bss is not a helpful solution to any problem, it is unexpected, and it is a serious pain to portability. If it were a well documented, non-default option I could appreciate it - but that was not the case in the toolchains I have see it in. > > Having a standard way to distinguish objects that must be cleared, those > that must not, and those that may be cleared or not at the implementation's > convenience, would be helpful. All systems could accommodate at least the > first and third, and if a piece of code requires the second but an > implementation cannot support it, having compilation fail outright would be > better than generating code that won't work. > >>> Perhaps that could have been handled by having Standard >>> suggest that objects which are qualified "volatile" may be initialized >>> or not at the implementation's discretion since, an implementation would >>> be allowed to change them at will, and there would be no C-observable >>> difference between initializing them and then spontaneously setting them >>> back to their previous value, versus simply leaving them holding whatever >>> they held at the time the CPU was reset. >> >> No, it should not be connected to "volatile" in any way. Having some >> standardised way to say that a particular variable should not be >> initialised at startup might be nice, but I don't think the lack of >> standardisation is a problem to anyone. > > I think the Standard would *allow* an implementation to treat "volatile" in > such fashion. I think having a different standard way of indicating that > would probably be better, but what's important is that some means exists. > "Volatile" has a use. It is completely orthogonal to whether or not the memory is cleared at startup. Re-using it in this way would be a /bad/ idea.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-08 10:33 -0700 |
| Message-ID | <353278ce-c0ca-49f9-9a29-52a071f73ec7@googlegroups.com> |
| In reply to | #130351 |
On Tuesday, May 8, 2018 at 11:48:53 AM UTC-5, David Brown wrote: > On 08/05/18 18:31, supercat@casperkitty.com wrote: > Watchdogs in general are rarely a good idea. They make sense if you > have flaky hardware, but it is best to get better hardware if possible. > Otherwise they mostly just make bugs harder to trace. Many embedded systems have to operate under adverse conditions. Watchdogs are far from perfect, but they handle many situations where an unexpected environmental condition is severe enough to interfere with operation, but not so severe as to destroy the device. > > Having a user-code hook which would execute before C language initialization > > is the best approach. Too bad there's no standard for such things. > > User-code hooks are a good approach. There is no need for a standard, > as such things are inherently non-portable. Having a standard would > reduce the learning curve slightly when starting work on a new target or > new toolchain, but it is not a significant factor. The only reason such things are "non-portable" is that the Standard does not define them. > > The fact that an implementation that behaves a certain way may be more > > useful for some purposes than one which doesn't is a perfectly fine > > justification for implementations targeting those purposes to behave in > > such fashion, or at least be configurable to do so. > > That would be true - except failing to clear the bss is not a helpful > solution to any problem, it is unexpected, and it is a serious pain to > portability. If it were a well documented, non-default option I could > appreciate it - but that was not the case in the toolchains I have see > it in. I'll agree it should be a clearly-documented option. My point is that it is extremely common for freestanding implementations to target platforms where memory might hold values before code starts. While platforms would vary as to how those values might have come to be in memory, that doesn't mean the Standard couldn't provide a uniform way of handling them once user code starts.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-08 23:36 +0200 |
| Message-ID | <pct58i$lj9$1@dont-email.me> |
| In reply to | #130352 |
On 08/05/18 19:33, supercat@casperkitty.com wrote: > On Tuesday, May 8, 2018 at 11:48:53 AM UTC-5, David Brown wrote: >> On 08/05/18 18:31, supercat@casperkitty.com wrote: >> Watchdogs in general are rarely a good idea. They make sense if you >> have flaky hardware, but it is best to get better hardware if possible. >> Otherwise they mostly just make bugs harder to trace. > > Many embedded systems have to operate under adverse conditions. Watchdogs > are far from perfect, but they handle many situations where an unexpected > environmental condition is severe enough to interfere with operation, but > not so severe as to destroy the device. No, that sort of thing is very rare. A typical microcontroller will work fine at a very wide range of voltages and temperatures - far wider than you get if you make even a vaguely decent card design. And if you are going to be using it in a system where radiation single-event upsets are a realistic possibility, then you should be using components designed to handle that (ECC ram, lock-step dual cores, etc.). It is extremely rare that watchdogs are triggered by anything other than software bugs - and far, far rarer that they are tested properly. They are a cheap way of pretending that your system is "reliable". Sometimes - if you put the effort in - they can be an aid to debugging. More often, they are a hinder. (Think of the difference between a Windows BSOD giving information on a crash, and an automatic restart so you have no idea what happened. The difference is, with small embedded systems there might be someone interested in figuring out what went wrong and fixing it.) > >>> Having a user-code hook which would execute before C language initialization >>> is the best approach. Too bad there's no standard for such things. >> >> User-code hooks are a good approach. There is no need for a standard, >> as such things are inherently non-portable. Having a standard would >> reduce the learning curve slightly when starting work on a new target or >> new toolchain, but it is not a significant factor. > > The only reason such things are "non-portable" is that the Standard does > not define them. No, they are non-portable because there is no use of a pre-main hook that is not highly dependent on the target and the particular program. You use pre-main hooks for things like disabling watchdogs, configuring ram, setting up a microcontroller's clocking system, initialising cache and MMUs, etc. These are all inherently non-portable. It does not make any noticeable difference if the details of making that pre-main hook vary from compiler to compiler. (The traditional way to do these things is from assembly, which is even less portable.) > >>> The fact that an implementation that behaves a certain way may be more >>> useful for some purposes than one which doesn't is a perfectly fine >>> justification for implementations targeting those purposes to behave in >>> such fashion, or at least be configurable to do so. >> >> That would be true - except failing to clear the bss is not a helpful >> solution to any problem, it is unexpected, and it is a serious pain to >> portability. If it were a well documented, non-default option I could >> appreciate it - but that was not the case in the toolchains I have see >> it in. > > I'll agree it should be a clearly-documented option. > > My point is that it is extremely common for freestanding implementations > to target platforms where memory might hold values before code starts. No, it is not "extremely common". Usually when you start up, you want to start from a known state, not from some partial data that might be in the ram. (Storing data in non-volatile memory is a different matter.) > While platforms would vary as to how those values might have come to be > in memory, that doesn't mean the Standard couldn't provide a uniform way > of handling them once user code starts. > Certainly there /could/ be a way to standardise this. Far and away the most useful would be to be able to specify that an object was not initialised - that it had an unspecified value (a little like uninitialised local variables). Then the system would not have to spend time setting that data to zero if it does not make use of it. This could be useful on big systems as much as small ones. As a bonus, this would also mean that it would keep old data from the previous restart (for statically linked programs, such as on small microcontrollers) - but it would be a very minor point.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-08 15:08 -0700 |
| Message-ID | <f94b8b6e-2fde-43b2-b86a-df1a7cd2986d@googlegroups.com> |
| In reply to | #130359 |
On Tuesday, May 8, 2018 at 4:36:27 PM UTC-5, David Brown wrote:
> On 08/05/18 19:33, supercat@casperkitty.com wrote:
> > Many embedded systems have to operate under adverse conditions. Watchdogs
> > are far from perfect, but they handle many situations where an unexpected
> > environmental condition is severe enough to interfere with operation, but
> > not so severe as to destroy the device.
>
> No, that sort of thing is very rare. A typical microcontroller will
> work fine at a very wide range of voltages and temperatures - far wider
> than you get if you make even a vaguely decent card design. And if you
> are going to be using it in a system where radiation single-event upsets
> are a realistic possibility, then you should be using components
> designed to handle that (ECC ram, lock-step dual cores, etc.). It is
> extremely rare that watchdogs are triggered by anything other than
> software bugs - and far, far rarer that they are tested properly. They
> are a cheap way of pretending that your system is "reliable". Sometimes
> - if you put the effort in - they can be an aid to debugging. More
> often, they are a hinder. (Think of the difference between a Windows
> BSOD giving information on a crash, and an automatic restart so you have
> no idea what happened. The difference is, with small embedded systems
> there might be someone interested in figuring out what went wrong and
> fixing it.)
From what I've seen, if one takes a typical device and start hitting it
with an ESD zapper while cranking up the voltage, its operation may be
disrupted at a lower voltage than would be needed to destroy it. While
a watchdog isn't the most effective means of guarding against such
conditions, it's one of the cheapest. And in price-sensitive
applications, cheaper plus good enough equals better.
> > The only reason such things are "non-portable" is that the Standard does
> > not define them.
>
> No, they are non-portable because there is no use of a pre-main hook
> that is not highly dependent on the target and the particular program.
> You use pre-main hooks for things like disabling watchdogs, configuring
> ram, setting up a microcontroller's clocking system, initialising cache
> and MMUs, etc. These are all inherently non-portable. It does not make
> any noticeable difference if the details of making that pre-main hook
> vary from compiler to compiler. (The traditional way to do these things
> is from assembly, which is even less portable.)
On many platforms, those things would require no assistance from the
C implementation beyond:
1. Process int-to-pointer conversions and volatile reads/writes in
a fashion consistent with the underlying platform.
2. Provide a means of executing code at the proper time.
The requirement for the code is to perform reads and writes to certain
addresses early in the startup sequence. While it's true that the
Standard doesn't require that implementations provide a means of e.g.
requesting a 32-bit store to address 0x4000105C, most freestanding
compilers for 32-bit systems would allow that to be done the same way:
* ((uint32_t volatile*)0x4000105C) = 0x12345678;
Not "portable" as the Standard defines the term, but widely and usefully
supported on a majority of freestanding implementations for 32-bit
processors.
> > My point is that it is extremely common for freestanding implementations
> > to target platforms where memory might hold values before code starts.
>
> No, it is not "extremely common". Usually when you start up, you want
> to start from a known state, not from some partial data that might be in
> the ram. (Storing data in non-volatile memory is a different matter.)
Most individual microcontroller units are built into applications which
would not benefit from being able to keep memory contents across a restart,
but most types of microcontrollers can *also* be used in ways that would
benefit from keeping memory contents. About the only ones that can't are
those that lack any means of reset that does not clear or corrupt memory.
Such controllers exist, but are in a minority.
> > While platforms would vary as to how those values might have come to be
> > in memory, that doesn't mean the Standard couldn't provide a uniform way
> > of handling them once user code starts.
>
> Certainly there /could/ be a way to standardise this. Far and away the
> most useful would be to be able to specify that an object was not
> initialised - that it had an unspecified value (a little like
> uninitialised local variables). Then the system would not have to spend
> time setting that data to zero if it does not make use of it. This
> could be useful on big systems as much as small ones. As a bonus, this
> would also mean that it would keep old data from the previous restart
> (for statically linked programs, such as on small microcontrollers) -
> but it would be a very minor point.
Weren't you just complaining about an implementation that did precisely
that?
On the other hand, for such a thing to be useful, the Standard would have
to be more specific about how Indeterminate values behave. If the only
way to ensure compiler sanity is to explicitly initialize storage even in
cases where every possible bit pattern would be equally acceptable, then
any performance benefit gained by not requiring that compilers zero the
storage would be lost.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-09 00:56 +0200 |
| Message-ID | <pct9v8$hlh$1@dont-email.me> |
| In reply to | #130363 |
On 09/05/18 00:08, supercat@casperkitty.com wrote: > On Tuesday, May 8, 2018 at 4:36:27 PM UTC-5, David Brown wrote: >> On 08/05/18 19:33, supercat@casperkitty.com wrote: >>> Many embedded systems have to operate under adverse conditions. Watchdogs >>> are far from perfect, but they handle many situations where an unexpected >>> environmental condition is severe enough to interfere with operation, but >>> not so severe as to destroy the device. >> >> No, that sort of thing is very rare. A typical microcontroller will >> work fine at a very wide range of voltages and temperatures - far wider >> than you get if you make even a vaguely decent card design. And if you >> are going to be using it in a system where radiation single-event upsets >> are a realistic possibility, then you should be using components >> designed to handle that (ECC ram, lock-step dual cores, etc.). It is >> extremely rare that watchdogs are triggered by anything other than >> software bugs - and far, far rarer that they are tested properly. They >> are a cheap way of pretending that your system is "reliable". Sometimes >> - if you put the effort in - they can be an aid to debugging. More >> often, they are a hinder. (Think of the difference between a Windows >> BSOD giving information on a crash, and an automatic restart so you have >> no idea what happened. The difference is, with small embedded systems >> there might be someone interested in figuring out what went wrong and >> fixing it.) > > From what I've seen, if one takes a typical device and start hitting it > with an ESD zapper while cranking up the voltage, its operation may be > disrupted at a lower voltage than would be needed to destroy it. While > a watchdog isn't the most effective means of guarding against such > conditions, it's one of the cheapest. And in price-sensitive > applications, cheaper plus good enough equals better. No, watchdogs are not good for that. If your device does not work when zapped by ESD at appropriate test voltages, it is not ready for the market. And resets by watchdog is seldom "good enough". Cheap is not a substitute for work correctly, unless you have no interest in getting repeat custom. I realise that there /are/ people who make devices this way. I am simply saying it is wrong if you are trying to make at least half-decent products (regardless of the price). > >>> The only reason such things are "non-portable" is that the Standard does >>> not define them. >> >> No, they are non-portable because there is no use of a pre-main hook >> that is not highly dependent on the target and the particular program. >> You use pre-main hooks for things like disabling watchdogs, configuring >> ram, setting up a microcontroller's clocking system, initialising cache >> and MMUs, etc. These are all inherently non-portable. It does not make >> any noticeable difference if the details of making that pre-main hook >> vary from compiler to compiler. (The traditional way to do these things >> is from assembly, which is even less portable.) > > On many platforms, those things would require no assistance from the > C implementation beyond: > > 1. Process int-to-pointer conversions and volatile reads/writes in > a fashion consistent with the underlying platform. > > 2. Provide a means of executing code at the proper time. > You need a way to hook into executing code at appropriate parts of the startup sequence. And that is dependent on the startup sequence, as well as the toolchain, and the way you want to handle it. It can be done in /many/ different ways - some simpler, some more advanced but perhaps more efficient (for platforms where an unnecessary call and return should be avoided). > The requirement for the code is to perform reads and writes to certain > addresses early in the startup sequence. While it's true that the > Standard doesn't require that implementations provide a means of e.g. > requesting a 32-bit store to address 0x4000105C, most freestanding > compilers for 32-bit systems would allow that to be done the same way: > > * ((uint32_t volatile*)0x4000105C) = 0x12345678; > /All/ compilers (for targets where pointers can be made like this - there are odd ones that have much more complex pointers) handle this. It turns out that this every compiler known to anyone in the C standards committee handles accesses via a cast-to-pointer-to-volatile as a volatile access, even though the standards don't specify it. > Not "portable" as the Standard defines the term, but widely and usefully > supported on a majority of freestanding implementations for 32-bit > processors. > >>> My point is that it is extremely common for freestanding implementations >>> to target platforms where memory might hold values before code starts. >> >> No, it is not "extremely common". Usually when you start up, you want >> to start from a known state, not from some partial data that might be in >> the ram. (Storing data in non-volatile memory is a different matter.) > > Most individual microcontroller units are built into applications which > would not benefit from being able to keep memory contents across a restart, > but most types of microcontrollers can *also* be used in ways that would > benefit from keeping memory contents. About the only ones that can't are > those that lack any means of reset that does not clear or corrupt memory. > Such controllers exist, but are in a minority. Oh, I agree that the hardware supports it - I simply disagree that it is an "extremely common" requirement. It is not unknown, and I have done it myself, but it is not common practice. > >>> While platforms would vary as to how those values might have come to be >>> in memory, that doesn't mean the Standard couldn't provide a uniform way >>> of handling them once user code starts. >> >> Certainly there /could/ be a way to standardise this. Far and away the >> most useful would be to be able to specify that an object was not >> initialised - that it had an unspecified value (a little like >> uninitialised local variables). Then the system would not have to spend >> time setting that data to zero if it does not make use of it. This >> could be useful on big systems as much as small ones. As a bonus, this >> would also mean that it would keep old data from the previous restart >> (for statically linked programs, such as on small microcontrollers) - >> but it would be a very minor point. > > Weren't you just complaining about an implementation that did precisely > that? I was complaining about an implementation that did that for normal defined variables that are required by the standards to be cleared to zero. If there were a standardised way to define variables that are not initialised to 0 or specific values, such as "_Uninit int x;", then it is a feature that I think would be useful. As it is, you need to use toolchain-specific features (such as a gcc "section" attribute). It is a bit ugly and awkward, and thus only used when it makes a big difference. > > On the other hand, for such a thing to be useful, the Standard would have > to be more specific about how Indeterminate values behave. If the only > way to ensure compiler sanity is to explicitly initialize storage even in > cases where every possible bit pattern would be equally acceptable, then > any performance benefit gained by not requiring that compilers zero the > storage would be lost. > If you want to simply save time at startup, then there is no problem - you would never be reading these indeterminate values because you would have stored something in them first. If you want to be able to re-use values from before reset, then the implementation would have to allow reading the values.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-08 16:17 -0700 |
| Message-ID | <7da5aeb7-0e6a-40b7-b2a8-84b105a21d53@googlegroups.com> |
| In reply to | #130365 |
On Tuesday, May 8, 2018 at 5:56:49 PM UTC-5, David Brown wrote: > On 09/05/18 00:08, supercat@casperkitty.com wrote: > > From what I've seen, if one takes a typical device and start hitting it > > with an ESD zapper while cranking up the voltage, its operation may be > > disrupted at a lower voltage than would be needed to destroy it. While > > a watchdog isn't the most effective means of guarding against such > > conditions, it's one of the cheapest. And in price-sensitive > > applications, cheaper plus good enough equals better. > > No, watchdogs are not good for that. If your device does not work when > zapped by ESD at appropriate test voltages, it is not ready for the > market. And resets by watchdog is seldom "good enough". Cheap is not a > substitute for work correctly, unless you have no interest in getting > repeat custom. To be ready for market, a device needs to be able to operate smoothly through some size of ESD event. It needs to operate without a sustained outage for some size of ESD event. The size of ESD events involved in those two requirements may or may not be equal. > I realise that there /are/ people who make devices this way. I am > simply saying it is wrong if you are trying to make at least half-decent > products (regardless of the price). Different products require different trade-offs between cost and reliability. Trade-offs that are appropriate for some devices may be inappropriate for others, but the reverse is equally true. Devices that would be inappropriate for some devices may be entirely appropriate in others. > > On many platforms, those things would require no assistance from the > > C implementation beyond: > > > > 1. Process int-to-pointer conversions and volatile reads/writes in > > a fashion consistent with the underlying platform. > > > > 2. Provide a means of executing code at the proper time. > > You need a way to hook into executing code at appropriate parts of the > startup sequence. And that is dependent on the startup sequence, as > well as the toolchain, and the way you want to handle it. It can be > done in /many/ different ways - some simpler, some more advanced but > perhaps more efficient (for platforms where an unnecessary call and > return should be avoided). Most cases where such things are necessary could be handled very simply by specifying the names of two functions which, if defined, will be invoked at some time after the "initialization" of const-qualified objects with initializers (which in many cases won't require doing anything since such objects would be in ROM), then at some time after initialization of other static objects with initializers, and then at some time after the clearing of everything else. > > The requirement for the code is to perform reads and writes to certain > > addresses early in the startup sequence. While it's true that the > > Standard doesn't require that implementations provide a means of e.g. > > requesting a 32-bit store to address 0x4000105C, most freestanding > > compilers for 32-bit systems would allow that to be done the same way: > > > > * ((uint32_t volatile*)0x4000105C) = 0x12345678; > > > > /All/ compilers (for targets where pointers can be made like this - > there are odd ones that have much more complex pointers) handle this. > It turns out that this every compiler known to anyone in the C standards > committee handles accesses via a cast-to-pointer-to-volatile as a > volatile access, even though the standards don't specify it. From the Standard's point of view, it's "not portable", however; again, that's only because the Standard fails to define it. > > Most individual microcontroller units are built into applications which > > would not benefit from being able to keep memory contents across a restart, > > but most types of microcontrollers can *also* be used in ways that would > > benefit from keeping memory contents. About the only ones that can't are > > those that lack any means of reset that does not clear or corrupt memory. > > Such controllers exist, but are in a minority. > > Oh, I agree that the hardware supports it - I simply disagree that it is > an "extremely common" requirement. It is not unknown, and I have done > it myself, but it is not common practice. I didn't say it's a common application requirement, but rather that on most freestanding implementations such a directive would have a clear meaning that could be useful for at least some applications on those implementations. > >> Certainly there /could/ be a way to standardise this. Far and away the > >> most useful would be to be able to specify that an object was not > >> initialised - that it had an unspecified value (a little like > >> uninitialised local variables). Then the system would not have to spend > >> time setting that data to zero if it does not make use of it. This > >> could be useful on big systems as much as small ones. As a bonus, this > >> would also mean that it would keep old data from the previous restart > >> (for statically linked programs, such as on small microcontrollers) - > >> but it would be a very minor point. > > > > Weren't you just complaining about an implementation that did precisely > > that? > > I was complaining about an implementation that did that for normal > defined variables that are required by the standards to be cleared to zero. Okay, sorry I misread your intention. You were calling upon that for only selected objects. Beautiful. No disagreement there. > > On the other hand, for such a thing to be useful, the Standard would have > > to be more specific about how Indeterminate values behave. If the only > > way to ensure compiler sanity is to explicitly initialize storage even in > > cases where every possible bit pattern would be equally acceptable, then > > any performance benefit gained by not requiring that compilers zero the > > storage would be lost. > > If you want to simply save time at startup, then there is no problem - > you would never be reading these indeterminate values because you would > have stored something in them first. If you want to be able to re-use > values from before reset, then the implementation would have to allow > reading the values. Even when simply trying to save time, there could still be issues, since the Standard doesn't describe the behavior of code which initializes some members of an aggregate and copies the whole thing.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2018-05-08 11:09 -0700 |
| Message-ID | <85p3fd11leu4nso76rh9qqmb6utbffcssm@4ax.com> |
| In reply to | #130351 |
On Tue, 8 May 2018 18:48:41 +0200, David Brown <david.brown@hesbynett.no> wrote: >Agreed. It is also a PITA. > >Watchdogs in general are rarely a good idea. They make sense if you >have flaky hardware, but it is best to get better hardware if possible. >Otherwise they mostly just make bugs harder to trace. Every CNC control manufacturer on the planet disagrees with this. That being said, there are proper ways to implement watchdogs and CNC watchdogs only trip the emergency stop, they don't restart the system software. System restart is accomplished by complete power down and restart. The Apollo Guidance Computers in the CM and LM had watchdogs and were restarted several times due to faults (1201 and 1202 alarms), they resumed their active programs with the active data and successfully approached the landing zone. Neil Armstrong didn't take manual control of the landing until it was evident to him that the target landing spot selected by the computer had a large boulder and crater.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-08 23:43 +0200 |
| Message-ID | <pct5mc$o5l$1@dont-email.me> |
| In reply to | #130353 |
On 08/05/18 20:09, Geoff wrote: > On Tue, 8 May 2018 18:48:41 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> Agreed. It is also a PITA. >> >> Watchdogs in general are rarely a good idea. They make sense if you >> have flaky hardware, but it is best to get better hardware if possible. >> Otherwise they mostly just make bugs harder to trace. > > Every CNC control manufacturer on the planet disagrees with this. That > being said, there are proper ways to implement watchdogs and CNC > watchdogs only trip the emergency stop, they don't restart the system > software. System restart is accomplished by complete power down and > restart. Perhaps you are using the term "watchdog" in a slightly different way, specific to CNC systems you have worked with. A basic "watchdog" is a timer that counts down at a regular rate. You need to "kick" it to restart the counter at a high value again - if you don't kick it often enough and it reaches zero, it triggers the systems hardware reset line. The idea is that your main loop (typically a "while (true)" loop in main(), or perhaps part of an RTOS scheduler or idle thread) will kick the dog. If some part of your code hangs, you don't kick the dog in time and the system restarts. At this point, you have probably lost information about why it hung, and there's a good chance that the same software bug will catch you again, and again, and again. This is something completely independent of emergency stops. These (at least in the CNC machines I made, long ago) are electrically wired to break the power supply to moving parts - they must not rely on software. And you usually pass a copy of the signal into an input in the controller, so that you can print a nice "Emergency Stop!!" message on the screen. > > The Apollo Guidance Computers in the CM and LM had watchdogs and were > restarted several times due to faults (1201 and 1202 alarms), they > resumed their active programs with the active data and successfully > approached the landing zone. Neil Armstrong didn't take manual control > of the landing until it was evident to him that the target landing > spot selected by the computer had a large boulder and crater. >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-08 15:24 -0700 |
| Message-ID | <e33cbbab-86d4-43b3-a659-7d4957755b41@googlegroups.com> |
| In reply to | #130361 |
On Tuesday, May 8, 2018 at 4:43:47 PM UTC-5, David Brown wrote: > On 08/05/18 20:09, Geoff wrote: > > Every CNC control manufacturer on the planet disagrees with this. That > > being said, there are proper ways to implement watchdogs and CNC > > watchdogs only trip the emergency stop, they don't restart the system > > software. System restart is accomplished by complete power down and > > restart. > > Perhaps you are using the term "watchdog" in a slightly different way, > specific to CNC systems you have worked with. A basic "watchdog" is a > timer that counts down at a regular rate. You need to "kick" it to > restart the counter at a high value again - if you don't kick it often > enough and it reaches zero, it triggers the systems hardware reset line. > This is something completely independent of emergency stops. These (at > least in the CNC machines I made, long ago) are electrically wired to > break the power supply to moving parts - they must not rely on software. In some large-machine-control applications I've done, there was a watchdog which was hooked into the E-stop circuit. Same principle as a reset watchdog, except that failing to feed it in timely fashion would break the e-stop chain. In many cases, resetting the controller while also letting it know why it was reset will allow better handling of fault conditions than simply doing everything in hardware, but the latter approach will guard against some faults the former might not (such as a socketed ROM chip that comes loose).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-09 00:58 +0200 |
| Message-ID | <pcta3j$hlh$2@dont-email.me> |
| In reply to | #130364 |
On 09/05/18 00:24, supercat@casperkitty.com wrote: > On Tuesday, May 8, 2018 at 4:43:47 PM UTC-5, David Brown wrote: >> On 08/05/18 20:09, Geoff wrote: >>> Every CNC control manufacturer on the planet disagrees with this. That >>> being said, there are proper ways to implement watchdogs and CNC >>> watchdogs only trip the emergency stop, they don't restart the system >>> software. System restart is accomplished by complete power down and >>> restart. >> >> Perhaps you are using the term "watchdog" in a slightly different way, >> specific to CNC systems you have worked with. A basic "watchdog" is a >> timer that counts down at a regular rate. You need to "kick" it to >> restart the counter at a high value again - if you don't kick it often >> enough and it reaches zero, it triggers the systems hardware reset line. > >> This is something completely independent of emergency stops. These (at >> least in the CNC machines I made, long ago) are electrically wired to >> break the power supply to moving parts - they must not rely on software. > > In some large-machine-control applications I've done, there was a watchdog > which was hooked into the E-stop circuit. Same principle as a reset > watchdog, except that failing to feed it in timely fashion would break > the e-stop chain. Ah, I see - you have the watchdog triggering the emergency stop. That makes sense. I would still not want to release a system where there is a real chance of the software hanging and being so dangerous that you need an emergency stop. > > In many cases, resetting the controller while also letting it know why it > was reset will allow better handling of fault conditions than simply > doing everything in hardware, but the latter approach will guard against > some faults the former might not (such as a socketed ROM chip that > comes loose). >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-09 08:11 -0700 |
| Message-ID | <8c71546f-91fc-4184-83a8-bfc537c85d69@googlegroups.com> |
| In reply to | #130366 |
On Tuesday, May 8, 2018 at 5:59:05 PM UTC-5, David Brown wrote: > I would still not want to release a system where there is a real chance > of the software hanging and being so dangerous that you need an > emergency stop. There may be essentially zero chance of the software hanging from any kind of normal stimulus. On the other hand, it's not possible to predict every kind of abnormal stimulus a system might receive. One might design a system to survive a 50,000-volt ESD spike with no disruption but have it get hit with a 60,000-volt spike. Or one might design it to withstand a collision with a pallet mover but have it get hit by a fully-loaded fork truck. If an automatic guided vehicle gets rammed by a fork truck with enough force to knock something loose inside the memory system, I'd rather have a watchdog shut the thing down than have it start randomly piloting itself who knows where.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-09 08:51 -0700 |
| Message-ID | <e63bf1b9-58df-4bd4-b702-42a55a4ca4ee@googlegroups.com> |
| In reply to | #130375 |
On Wednesday, May 9, 2018 at 8:11:24 AM UTC-7, supe...@casperkitty.com wrote: > On Tuesday, May 8, 2018 at 5:59:05 PM UTC-5, David Brown wrote: > > I would still not want to release a system where there is a real chance > > of the software hanging and being so dangerous that you need an > > emergency stop. > > There may be essentially zero chance of the software hanging from any kind > of normal stimulus. On the other hand, it's not possible to predict every > kind of abnormal stimulus a system might receive. One might design a system > to survive a 50,000-volt ESD spike with no disruption but have it get hit > with a 60,000-volt spike. Or one might design it to withstand a collision > with a pallet mover but have it get hit by a fully-loaded fork truck. If > an automatic guided vehicle gets rammed by a fork truck with enough force to > knock something loose inside the memory system, I'd rather have a watchdog > shut the thing down than have it start randomly piloting itself who knows > where. -hh doesn't know if there is a no-cost open source solution. Thiago Adams created at least twenty virtual machines in the last year or so. Let us all have a moment of silence as we honor his accomplishments! I'm not going to pretend Thiago Adams did not help me with C++ and I appreciate his help. -hh has this thread to examine and might begin to act as if he has a clue because of this... of course he stepped on his own dick when it mattered. Do you have a MCSE certification? -- Best CMS Solution of 2017 https://youtu.be/u4xD43Khhkw https://youtu.be/GPPqvw8iEBs https://youtu.be/BUjnZhKk1Bg Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-09 11:45 -0700 |
| Message-ID | <bf4bb2a2-d295-47f7-aeb3-01ed4a7e9e27@googlegroups.com> |
| In reply to | #130375 |
On Wednesday, May 9, 2018 at 8:11:24 AM UTC-7, supe...@casperkitty.com wrote: > On Tuesday, May 8, 2018 at 5:59:05 PM UTC-5, David Brown wrote: > > I would still not want to release a system where there is a real chance > > of the software hanging and being so dangerous that you need an > > emergency stop. > > There may be essentially zero chance of the software hanging from any kind > of normal stimulus. On the other hand, it's not possible to predict every > kind of abnormal stimulus a system might receive. One might design a system > to survive a 50,000-volt ESD spike with no disruption but have it get hit > with a 60,000-volt spike. Or one might design it to withstand a collision > with a pallet mover but have it get hit by a fully-loaded fork truck. If > an automatic guided vehicle gets rammed by a fork truck with enough force to > knock something loose inside the memory system, I'd rather have a watchdog > shut the thing down than have it start randomly piloting itself who knows > where. Turns out Chris Ahlstrom's non-stop flooding comments of Steve Carroll met his own definition of trolling, so he accused Steve Carroll of making that up. What do you get out of lying? At times, a make believe world is more valuable than truth. -- E-commerce Simplified! http://www.5z8.info/titstitstitstits_j7t4bl_stalin Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-09 13:03 -0700 |
| Message-ID | <2a0e4681-4bab-4fed-93e4-07ee210c2413@googlegroups.com> |
| In reply to | #130375 |
On Wednesday, May 9, 2018 at 8:11:24 AM UTC-7, supe...@casperkitty.com wrote: > On Tuesday, May 8, 2018 at 5:59:05 PM UTC-5, David Brown wrote: > > I would still not want to release a system where there is a real chance > > of the software hanging and being so dangerous that you need an > > emergency stop. > > There may be essentially zero chance of the software hanging from any kind > of normal stimulus. On the other hand, it's not possible to predict every > kind of abnormal stimulus a system might receive. One might design a system > to survive a 50,000-volt ESD spike with no disruption but have it get hit > with a 60,000-volt spike. Or one might design it to withstand a collision > with a pallet mover but have it get hit by a fully-loaded fork truck. If > an automatic guided vehicle gets rammed by a fork truck with enough force to > knock something loose inside the memory system, I'd rather have a watchdog > shut the thing down than have it start randomly piloting itself who knows > where. Perhaps you use it wrong. Do you not understand the use of VPN? So Jeff Relf changed his story to The Underground Marshmallow Person responding to him. The Underground Marshmallow Person clearly has a ton of wisdom to show and he apparently wants to share it. Sadly this is maybe the least appropriate group for doing that because a large part of what he will get back is insulting, trickery and other poppycock. Does The Underground Marshmallow Person believe the bullshit Jeff Relf is pushing? Generally, I don't call a claim like Jeff Relf's claims a fantasy right up until you refute it (as you are here) and Jeff Relf responds with the gibberish ignoring what you said. You haven't been following him to figure out the depths of Jeff Relf's indecency. Jeff Relf is repeatedly seen insisting "GOOGLE HAS NOTHING" when it comes to data on the web where it is written with other words... but Jeff Relf is just too obtuse and/or too in over your head to grasp any advice he finds... or he does not recognize it *as* information when he does read it. -- One Smart Penny!! https://www.youtube.com/watch?v=AglvCo3dJ38&feature=youtu.be Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-09 23:40 +0200 |
| Message-ID | <pcvpsv$a29$1@dont-email.me> |
| In reply to | #130375 |
On 09/05/18 17:11, supercat@casperkitty.com wrote: > On Tuesday, May 8, 2018 at 5:59:05 PM UTC-5, David Brown wrote: >> I would still not want to release a system where there is a real chance >> of the software hanging and being so dangerous that you need an >> emergency stop. > > There may be essentially zero chance of the software hanging from any kind > of normal stimulus. On the other hand, it's not possible to predict every > kind of abnormal stimulus a system might receive. One might design a system > to survive a 50,000-volt ESD spike with no disruption but have it get hit > with a 60,000-volt spike. Or one might design it to withstand a collision > with a pallet mover but have it get hit by a fully-loaded fork truck. If > an automatic guided vehicle gets rammed by a fork truck with enough force to > knock something loose inside the memory system, I'd rather have a watchdog > shut the thing down than have it start randomly piloting itself who knows > where. > This is simply nonsense. If you want a system to survive 60 kV spikes, you design it and test it for the purpose. When specifying things like this, you usually add safety margins. If the end user is expecting a maximum of 30 kV spikes, then you might specify it should survive fine at 50 kV to give an error margin and longer lifetimes. So the design and testing is for 50 kV. Some experimental tests will also be done at higher levels, to make sure the design is clearly within specifications. But the end user has bought a device rated for 30 kV, and must ensure that it is used within those limits. You do not /ever/ specify "as safe as possible" if you are doing serious engineering and development. You never say "as cheap as possible", "as fast as possible" - these are all signs of amateurs who don't understand engineering. You /may/ specify your system to be as safe as reasonably possible within constraints for budget, size, time, etc., but you base your requirements on an analysis of what can go wrong, how likely it is, and what the consequences of the failure are. If there is no way for your system to be exposed to more than 30 kV other than a lightning strike that burns down the building, development to protect at higher levels (beyond a reasonable margin) is wasted time, money and effort - and it probably results in a /worse/ product. The reality of extra "safety" features, extra checks, etc., is that these are rarely tested - it is rarely /possible/ to test them properly. But it is certainly possible for failures or bugs in them to cause other problems. Unnecessary features is a safety and reliability problem - I have seen products recalled due to problems in pointless extra checks in code and in hardware.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-09 15:48 -0700 |
| Message-ID | <def828c7-d81a-44d6-9937-25b214695377@googlegroups.com> |
| In reply to | #130382 |
On Wednesday, May 9, 2018 at 4:40:59 PM UTC-5, David Brown wrote: > On 09/05/18 17:11, supercat@casperkitty.com wrote: > > There may be essentially zero chance of the software hanging from any kind > > of normal stimulus. On the other hand, it's not possible to predict every > > kind of abnormal stimulus a system might receive. One might design a system > > to survive a 50,000-volt ESD spike with no disruption but have it get hit > > with a 60,000-volt spike. Or one might design it to withstand a collision > > with a pallet mover but have it get hit by a fully-loaded fork truck. If > > an automatic guided vehicle gets rammed by a fork truck with enough force to > > knock something loose inside the memory system, I'd rather have a watchdog > > shut the thing down than have it start randomly piloting itself who knows > > where. > > > > This is simply nonsense. > > If you want a system to survive 60 kV spikes, you design it and test it > for the purpose. If one knows that 60kV spikes will appear, one should obviously design for 60kV spikes. One seldom knows the maximum size of spike a system is going to have to endure, however. The best one can do is figure that there's a certain probability that the system will have to endure a 10kV spike but nothing bigger than 15kV, a certain probability it will have to endure 15kV but not 20kV, etc. A decision to engineer for a maximum 50kV spike would not usually be predicated on knowledge that the system would actually receive such a spike, but rather based on a judgment that the probability of the system receiving a spike in the range 50kV to 60kV was too low to justify the cost of fully protecting the system against them. > When specifying things like this, you usually add safety margins. If > the end user is expecting a maximum of 30 kV spikes, then you might > specify it should survive fine at 50 kV to give an error margin and > longer lifetimes. So the design and testing is for 50 kV. Some > experimental tests will also be done at higher levels, to make sure the > design is clearly within specifications. But the end user has bought a > device rated for 30 kV, and must ensure that it is used within those limits. Do you expect users to install an ESD meter next to every device and refrain from touching the device without dissipating their static charge except when their potential is 30kV or less? > You /may/ specify your system to be as safe as reasonably possible > within constraints for budget, size, time, etc., but you base your > requirements on an analysis of what can go wrong, how likely it is, and > what the consequences of the failure are. If there is no way for your > system to be exposed to more than 30 kV other than a lightning strike > that burns down the building, development to protect at higher levels > (beyond a reasonable margin) is wasted time, money and effort - and it > probably results in a /worse/ product. Do commonplace clothes and shoes come with published specifications about their ESD characteristics? Is there any way of knowing the maximum amount of charge that a person's outfit might build up and store? > The reality of extra "safety" features, extra checks, etc., is that > these are rarely tested - it is rarely /possible/ to test them properly. > But it is certainly possible for failures or bugs in them to cause > other problems. Unnecessary features is a safety and reliability > problem - I have seen products recalled due to problems in pointless > extra checks in code and in hardware. I've also seen plenty of cases where extra checks reduced the harm that would have otherwise been caused by various kinds of failures.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-10 13:48 +0200 |
| Message-ID | <pd1bi6$kp9$1@dont-email.me> |
| In reply to | #130383 |
On 10/05/18 00:48, supercat@casperkitty.com wrote: > On Wednesday, May 9, 2018 at 4:40:59 PM UTC-5, David Brown wrote: >> On 09/05/18 17:11, supercat@casperkitty.com wrote: >>> There may be essentially zero chance of the software hanging from any kind >>> of normal stimulus. On the other hand, it's not possible to predict every >>> kind of abnormal stimulus a system might receive. One might design a system >>> to survive a 50,000-volt ESD spike with no disruption but have it get hit >>> with a 60,000-volt spike. Or one might design it to withstand a collision >>> with a pallet mover but have it get hit by a fully-loaded fork truck. If >>> an automatic guided vehicle gets rammed by a fork truck with enough force to >>> knock something loose inside the memory system, I'd rather have a watchdog >>> shut the thing down than have it start randomly piloting itself who knows >>> where. >>> >> >> This is simply nonsense. >> >> If you want a system to survive 60 kV spikes, you design it and test it >> for the purpose. > > If one knows that 60kV spikes will appear, one should obviously design for > 60kV spikes. One seldom knows the maximum size of spike a system is going > to have to endure, however. You know the maximum size of spike that your system /should/ endure. If not, you are not ready to start designing. Safety and reliability (and security, and lifetimes, and accuracy, and cost, and many other properties) are not absolutes. You aim for something reasonable, based on an analysis of likelihoods and consequences - you do /not/ aim for "as good as possible" because it is /always/ a balance. Increasing safety from ESD spikes means increasing costs, size, power requirements, and quite possibly decreasing reliability and lifetime. The same applies to increasing reliability, decreasing costs, etc. - there is /always/ a trade-off. So you make your system able to survive fine with ESD spikes that are likely to occur, such as from people in nylon clothes on a hot dry day. But you don't make it lightening proof - unless it is used in an area where lightening is commonplace. The same goes for all other features. And you don't use a watchdog unless the watchdog /adds/ to the safety and reliability of the system without unduly detracting from other aspects. In most systems, the use of a watchdog is highly questionable because the circumstances when it would be helpful are very rare, and the lack of testing and due consideration for the consequences mean it could easily cause more problems than it solves. Almost all uses of a watchdog are as a way of hiding from poor quality software development practices - the hope is that if there is a bug in the program, then the watchdog will "fix" it. In some cases, that may be true - but it does /not/ make the watchdog a good solution! If you don't understand that, there is no point in my repeating it again.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-10 08:28 -0700 |
| Message-ID | <6858b426-49ee-419a-b4f5-072fb118aecf@googlegroups.com> |
| In reply to | #130387 |
On Thursday, May 10, 2018 at 6:48:36 AM UTC-5, David Brown wrote:
> And you don't use a watchdog unless the watchdog /adds/ to the safety
> and reliability of the system without unduly detracting from other
> aspects. In most systems, the use of a watchdog is highly questionable
> because the circumstances when it would be helpful are very rare, and
> the lack of testing and due consideration for the consequences mean it
> could easily cause more problems than it solves. Almost all uses of a
> watchdog are as a way of hiding from poor quality software development
> practices - the hope is that if there is a bug in the program, then the
> watchdog will "fix" it. In some cases, that may be true - but it does
> /not/ make the watchdog a good solution!
Of course a system design that uses a watchdog needs to take care that it
does not create problems of its own. And I've encountered some incredibly
horribly designed ones.
I'm well aware that watchdogs are not a panacea, can easily mask problems
that would otherwise be found and fixed, but on some occasions can create
problems of their own. On the other hand, they can also provide a very
cost-effective way of reducing the probability of certain catastrophic
failures. If the cost of an otherwise-avoidable system restart is $1,
and the cost of having a system inoperable until someone visits it is
$100, a watchdog which can turn 95% of the latter into the former will
offer more benefit than reducing the likelihood of what would otherwise
be a catastrophic failure by 90%.
My original point, though, was that some of the issues you were complaining
about are what I would consider good characteristics for a watchdog. More
importantly, watchdogs are just one of the many things a processor may need
to do very early on in the startup sequence. The general notion that it
may be necessary to do *something* before static objects are initialized
is not system-specific even though the details of *what* would need to be
done would be.
Incidentally, were I in charge of the Standard, I would provide an explicit
intrinsic to perform static initialization, and also allow define optional
features to report the address of the start of static storage, the size of
static storage, and on some platforms treat all but one static object as
being members of a structure pointed to by that remaining object.
The former would be useful, even in hosted implementations, for applications
where a certain stimulus is supposed to behave as though it restarts the
entire application. Having a category of implementations that aren't
required to support static variables with "normal" semantics would make
conforming implementations possible in environments that could otherwise not
support them. Having a base pointer for statics would make it possible to
have a state-machine-based application that would fit the pattern:
init();
while(main_loop())
;
to behave as though it has multiple live instances.
int main(void)
{
void *static1 = __STATIC_BASE;
SHARED_INFO shared;
init();
void *static2 = malloc(__STATIC_SIZE);
if (!static2)
fatal_error();
__STATIC_BASE = static2;
__STATIC_INIT();
init(&shared);
while(1)
{
__STATIC_BASE = static1;
main_loop(&shared);
__STATIC_BASE = static2;
main_loop(&shared);
}
}
The practicality of supporting that construct would vary on different
systems. Some like classic Macintosh could naturally support it with
essentially no run-time cost (since a register is dedicated to holding
the base of static objects). Some like 8086 real mode could support
it at no extra cost, with some limitations, if the right kind of
allocation routine were used.
To be sure, if one were writing new code with the intention that it support
multiple application instances, it would be cleaner to pass around a
pointer to a state object. When trying to adapt existing code, however,
being able to treat static objects collectively *as* a state object would
be easier than having to manually add a state-object pointer as a parameter
to just about every function.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-11 10:06 +0200 |
| Message-ID | <pd3iv0$n3l$1@dont-email.me> |
| In reply to | #130393 |
On 10/05/18 17:28, supercat@casperkitty.com wrote: > On Thursday, May 10, 2018 at 6:48:36 AM UTC-5, David Brown wrote: >> And you don't use a watchdog unless the watchdog /adds/ to the safety >> and reliability of the system without unduly detracting from other >> aspects. In most systems, the use of a watchdog is highly questionable >> because the circumstances when it would be helpful are very rare, and >> the lack of testing and due consideration for the consequences mean it >> could easily cause more problems than it solves. Almost all uses of a >> watchdog are as a way of hiding from poor quality software development >> practices - the hope is that if there is a bug in the program, then the >> watchdog will "fix" it. In some cases, that may be true - but it does >> /not/ make the watchdog a good solution! > > Of course a system design that uses a watchdog needs to take care that it > does not create problems of its own. And I've encountered some incredibly > horribly designed ones. > > I'm well aware that watchdogs are not a panacea, can easily mask problems > that would otherwise be found and fixed, but on some occasions can create > problems of their own. On the other hand, they can also provide a very > cost-effective way of reducing the probability of certain catastrophic > failures. If the cost of an otherwise-avoidable system restart is $1, > and the cost of having a system inoperable until someone visits it is > $100, a watchdog which can turn 95% of the latter into the former will > offer more benefit than reducing the likelihood of what would otherwise > be a catastrophic failure by 90%. > Sometimes numbers like this work out - and a watchdog makes sense. More often, it looks like they are working out during early tests and roll-outs. Then you discover that the watchdog was merely covering up for a serious problem - because if a watchdog ever triggers, there is a /real/ problem underneath. And suddenly you find that instead of sending $100 visits to some of the 50 test customers, you are doing a recall and sending $100 visits plus $100 replacements plus $xxxx lost reputation to your 10,000 real customers. There /are/ occasions when you might want to push hardware past guaranteed limits (such as using it beyond its temperature limits) - there can even be occasions when you have good reason for deploying software that you know is not well enough developed and tested. A watchdog can sometimes be of some help in such cases - and as you note, it is very cheap. But in almost all cases, if you think a watchdog will help, you have done something wrong. However, I think this is perhaps enough about watchdog pros and cons for c.l.c. If you want to discuss it more, perhaps comp.arch.embedded is more appropriate. > My original point, though, was that some of the issues you were complaining > about are what I would consider good characteristics for a watchdog. I don't understand. My complaint was about toolchains not zeroing uninitialised statically allocated data. No characteristics of watchdogs (other than the most basic functionality of simple watchdogs) was discussed. I can't see a connection. > More > importantly, watchdogs are just one of the many things a processor may need > to do very early on in the startup sequence. The general notion that it > may be necessary to do *something* before static objects are initialized > is not system-specific even though the details of *what* would need to be > done would be. Agreed. However, the C startup code, and the types of initialisation or hardware setup needed, and the places they would be needed, varies enormously from system to system. This makes any kind of standardisation very difficult - it would quickly be extremely complicated, full of options and variations, and therefore pretty useless as standardisation. > > Incidentally, were I in charge of the Standard, I would provide an explicit > intrinsic to perform static initialization, and also allow define optional > features to report the address of the start of static storage, the size of > static storage, and on some platforms treat all but one static object as > being members of a structure pointed to by that remaining object. > I am glad you are not in charge of the standard. This sort of thing would either be too restrictive to be useful on many systems, or too flexible and optional to provide any portability.
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web