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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-11 02:22 -0700 |
| Message-ID | <d53f4086-7d87-4b05-b568-d441ed57e02a@googlegroups.com> |
| In reply to | #130404 |
On Friday, May 11, 2018 at 1:07:08 AM UTC-7, David Brown wrote: > 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. You wishing for something does not make it true. The herd members value conformity in all things. It was Dan 'The Flooder' Cross who forged me (and Richard Heathfield) and then tried to deny it. -- Do not click this link!! https://youtu.be/Z5wo5aE7MUk http://prescottcomputerguy.com/screenflow http://tinyurl.com/kmqe66h Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-11 05:29 -0700 |
| Message-ID | <4fab1d93-067f-4c67-bcbb-680c2de01e55@googlegroups.com> |
| In reply to | #130404 |
On Friday, May 11, 2018 at 1:07:08 AM UTC-7, David Brown wrote: > 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. I bet we have two different notions entirely. This is something you merely pretend to understand. Android, runs on the Pulseaudio kernel. So yeah, Pulseaudio is mobile. Pulseaudio is a super computer. Pulseaudio is a server. Pulseaudio is a desktop. Pulseaudio is growing in market share. Are people still debating this? You've proven only what a moron you are. That is the problem today and American teachers don't understand why older people are better; people from pre-tech generations (~50 yo) are the only ones who know better than to fall for liberalism. These posts are clearly NOT automated, they are made by a glue sniffing pervert with an axe to grind who has way too much time on his hands (and possibly has other shills helping him). What do you get out of lying? -- This Trick Gets Women Hot For You http://prescottcomputerguy.com http://www.5z8.info/freeanimalporn.com-start-download_s9j7do_dogporn Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-05-11 13:31 +0000 |
| Message-ID | <SWgJC.136927$br4.124994@fx34.iad> |
| In reply to | #130404 |
David Brown <david.brown@hesbynett.no> writes: >On 10/05/18 17:28, supercat@casperkitty.com wrote: > >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. > I'd point out that standard operating systems (Linux, Windows, MacOSX) also use watchdog timers (to catch deadlocks on SMP machines, for example). The watchdogs (we have 56 of them) on our chip will simply send an interrupt (MSI-X) when the watchdog times out the first time. The second time, it will send an NMI. The third time, reset. The ARM64 Base System Architecture (SBSA) specification requires that platforms include a minimum of two watchdog timers (one for the secure state and one for the non-secure state).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-11 15:47 +0200 |
| Message-ID | <pd46tu$j9e$1@dont-email.me> |
| In reply to | #130412 |
On 11/05/18 15:31, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 10/05/18 17:28, supercat@casperkitty.com wrote: > >> >> 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. >> > > I'd point out that standard operating systems (Linux, Windows, MacOSX) > also use watchdog timers (to catch deadlocks on SMP machines, for example). Typically such large systems are expected to have a higher chance of bugs than on small embedded systems. And you also have a lot more possibilities for how to react to problems. So on a big system, you might have a watchdog and a handler that will automatically send off an email to a support address if it trips. Or you might re-start that one service and not others. On small embedded systems, you rarely have that kind of handling. > > The watchdogs (we have 56 of them) on our chip will simply send an interrupt (MSI-X) when > the watchdog times out the first time. The second time, it will send > an NMI. The third time, reset. > > The ARM64 Base System Architecture (SBSA) specification requires that > platforms include a minimum of two watchdog timers (one for the secure > state and one for the non-secure state). >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-11 09:16 -0700 |
| Message-ID | <7543bdfc-7cac-4c4e-87ed-5e489c6092ef@googlegroups.com> |
| In reply to | #130404 |
On Friday, May 11, 2018 at 3:07:08 AM UTC-5, David Brown wrote: > On 10/05/18 17:28, supercat@casperkitty.com wrote: > > 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. If watchdog restarts are reported and recognized as suggesting issues that need to be addressed, the watchdog would be more likely to reveal problems than cover them up (e.g. if closing a switch will cause software to freeze until the switch is released, and if nothing requiring attention happens to occur when the switch is closed, the problem might go unnoticed in the absence of a watchdog, but if the watchdog fires while the switch is closed that could call attention to the issue). > 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. Was it not you who made a comment about how the need for pre-main() code was to handle annoying watchdog designs that get activated by hardware rather than software? > 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. What is difficult about having two functions before main()--one of them after the "initialization" of static const objects and one after the initialization of other objects that have initializers, with an implication that quality implementations should call those functions as early as possible subject to those constraints? For what usage scenarios would those be insufficient? > > 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. Making features optional would mean that they need not impair the design of systems that cannot practically support them. Code that relies upon such features would not be useful on systems that cannot practically support them, but that doesn't mean that such code shouldn't be portable among those systems that do. Code which can provide enhanced functionality when such features are available, but work without them, should be portable to both kinds of systems, but be able to benefit from the extra features on those systems where they exist.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-12 17:43 +0200 |
| Message-ID | <pd7229$6pp$1@dont-email.me> |
| In reply to | #130415 |
On 11/05/18 18:16, supercat@casperkitty.com wrote: > On Friday, May 11, 2018 at 3:07:08 AM UTC-5, David Brown wrote: >> On 10/05/18 17:28, supercat@casperkitty.com wrote: >>> 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. > > If watchdog restarts are reported and recognized as suggesting issues that > need to be addressed, the watchdog would be more likely to reveal problems > than cover them up (e.g. if closing a switch will cause software to freeze > until the switch is released, and if nothing requiring attention happens to > occur when the switch is closed, the problem might go unnoticed in the > absence of a watchdog, but if the watchdog fires while the switch is closed > that could call attention to the issue). > >> 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. > > Was it not you who made a comment about how the need for pre-main() code was > to handle annoying watchdog designs that get activated by hardware rather > than software? Ah, I see what you mean now. Yes, I made that comment. But it was from the other viewpoint - pre-main() code early in the C startup is one way to solve the problem with having overly enthusiastic watchdogs enabled from reset in the hardware. A better way is not to build devices like that in the first place, and a reasonable solution is that the toolchain already disables the watchdog without needing programmer effort. > >> 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. > > What is difficult about having two functions before main()--one of them > after the "initialization" of static const objects and one after the > initialization of other objects that have initializers, with an implication > that quality implementations should call those functions as early as > possible subject to those constraints? > > For what usage scenarios would those be insufficient? There can be more than one memory area in a device - some of which may need extra initialisation (like external dram). You may need extra initialisation before reading constants for initialising data segments. You might have separate boot rooms and main startup code. You might want caches enabled before startup routines - you might want them disabled until /after/ startup. The same goes for clocks or oscillators. You might want to control the order of certain startup code. You might want to start up additional cores early, you might want to keep running a single core for a while. I am sure there are many more possibilities. This would be far too much complication and overhead on a small and simple device - but a simple solution would not be sufficient on a more advanced device. I don't think there is a good general solution here. And of course it is many decades too late to try to standardise anything here - it would be different from the methods currently used, at least in some details, and therefore different from what toolchains currently provide and what existing code currently requires. > >>> 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. > > Making features optional would mean that they need not impair the design > of systems that cannot practically support them. Code that relies upon > such features would not be useful on systems that cannot practically > support them, but that doesn't mean that such code shouldn't be portable > among those systems that do. Code which can provide enhanced functionality > when such features are available, but work without them, should be portable > to both kinds of systems, but be able to benefit from the extra features > on those systems where they exist. >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-12 14:06 -0700 |
| Message-ID | <a812307d-7ba8-46e2-b58e-fb051df07642@googlegroups.com> |
| In reply to | #130452 |
On Saturday, May 12, 2018 at 10:43:13 AM UTC-5, David Brown wrote: > On 11/05/18 18:16, supercat@casperkitty.com wrote: > > What is difficult about having two functions before main()--one of them > > after the "initialization" of static const objects and one after the > > initialization of other objects that have initializers, with an implication > > that quality implementations should call those functions as early as > > possible subject to those constraints? > > > > For what usage scenarios would those be insufficient? > > There can be more than one memory area in a device - some of which may > need extra initialisation (like external dram). You may need extra > initialisation before reading constants for initialising data segments. > You might have separate boot rooms and main startup code. You might > want caches enabled before startup routines - you might want them > disabled until /after/ startup. The same goes for clocks or > oscillators. You might want to control the order of certain startup > code. You might want to start up additional cores early, you might want > to keep running a single core for a while. I am sure there are many > more possibilities. I'm not sure I see the issue. The C implementation's job is to let user code do things it needs to do when it needs to do them. It will have no need to know or care whether the user code is setting up oscillators, caches, etc. if it refrains from assuming it understands the behavior of functions that make volatile accesses. In some cases, it may be necessary for code to ensure that objects declared in certain compilation units get placed at certain addresses, but if user code ensures that it will do whatever is necessary to enable memory before anything else tries to use that memory, there's no need for the compiler to worry about such things. So I'm not seeing how the three-function model I described would not be adequate for nearly all applications. > This would be far too much complication and overhead on a small and > simple device - but a simple solution would not be sufficient on a more > advanced device. I don't think there is a good general solution here. What complication? If wait states need to be enabled before setting the oscillator speed, then user code needs to enable wait states before it sets oscillator speed. No need for the compiler to know or care. > And of course it is many decades too late to try to standardise anything > here - it would be different from the methods currently used, at least > in some details, and therefore different from what toolchains currently > provide and what existing code currently requires. If the Standard were to pick names that aren't presently in use by any existing implementations, all an implementation would need to do is generate calls to those functions if they exist. Not exactly a difficult problem.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-10 00:13 -0700 |
| Message-ID | <0ffc89ef-0821-4880-8495-8f7b0efb589c@googlegroups.com> |
| In reply to | #130382 |
On Wednesday, May 9, 2018 at 2:40:59 PM UTC-7, David Brown wrote: > 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. It was Pascal Hambourg who forged me and admitted to having done so. For crying out loud, just recently he was declaring himself the only "true Linux advocate", and claiming that "advocates" (in satire-quotes to try to paint them as the bad guys) are actively working against the success of desktop Linux. I just configured a KF and never see the idiot. Pascal Hambourg's flooding has made an absolute disaster of usenet via GG, so I don't make an attempt reading the group with my phone anymore. Only thing he has achieved with this trolling is that the Pascal Hambourg ban will never be lifted. You are ten seconds away from being in everyone's kill filter. Can you stop begging for my attention? - E-commerce Simplified https://goo.gl/Fho5Nq http://comp.os.linux.advocacy.narkive.com/711dskzA/steven-petruzzellis-admits-he-can-not-back-his-claims-about-snit Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-10 01:31 -0700 |
| Message-ID | <5800aafb-e12f-4f19-9f7b-6c40fabfd3fd@googlegroups.com> |
| In reply to | #130382 |
On Wednesday, May 9, 2018 at 2:40:59 PM UTC-7, David Brown wrote: > 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. Can you stop pleading for my attention? Nobody gets it, I don't get it. My uptime is almost forty-six days and I am ready to go see a doctor! Are you being stupid on purpose? Doc O'Leary is being controlled by RMS. I've worked in the computer repair industry for 15 years. I've worked with multibillion corporations working with NASA and green technology industries. Never, not even once, were we ever told to not install any version of Linux. We sold Linux, CP/M, Blackberry, among others with Microsoft OSs with no issues. This is what comes about when dangerously bad pride takes over Doc O'Leary's psyche. Only what Doc O'Leary wants matters to Doc O'Leary. There is nothing you or I can do to change that. It's a medical issue and it is what it is. -- Top Ten Ways Doc O'Leary Trolls http://www.5z8.info/facebook-of-sex_w4l4wg_bomb https://youtu.be/E3m_i-x92D0 http://www.5z8.info/myspace-of-sex_q7q7zl_instant-purchase Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-05-11 18:01 +0200 |
| Message-ID | <bcrgse-0k7.ln1@gangtai.grep.be> |
| In reply to | #130382 |
On 09-05-18 23:40, David Brown wrote: > 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. No. But there is something to be said for engineering a system such that if it fails, it doesn't go berserk and kill everything in sight; instead, if it fails because it was used out of its specifications, it should go "er, ugh, I'll die now, bye", and shut down in a safe way. You don't do that by saying "meh, you used the system outside of the specs we gave you, so your problem". Obviously the details depend on the specific situation of the system you're trying to build, but a watchdog can be a valid way of implementing that.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2018-05-10 08:30 -0700 |
| Message-ID | <70p8fdps22lqq8ghp7vkg4cde8ol1soga9@4ax.com> |
| In reply to | #130361 |
On Tue, 8 May 2018 23:43:40 +0200, David Brown <david.brown@hesbynett.no> wrote: >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. No, I see no difference between the concept I described and your description here. The CNC software kicks the hardware watchdog at regular intervals. If for some reason the CNC doesn't reset it the watchdog trips and E-stop occurs. The CNC may or may not still be operating but it will display an estop message if it's still operating. Otherwise E-stop indicators elsewhere on the control panel are pure hardware. The watchdog holds the CNC in estop against any attempt to clear it until the software is kicking it after ramp-up. All the major OEM's and all the major control manufacturers (e.g. Siemens, Fanuc) have been using and continue to use this method.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-05-09 09:29 +0200 |
| Message-ID | <ijkase-ff.ln1@gangtai.grep.be> |
| 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. > > The Apollo Guidance Computers in the CM and LM had watchdogs and were > restarted several times due to faults (1201 and 1202 alarms), That's a *very* inaccurate description of the 1201 and 1202 alarms. They did not have watchdogs (it would be insane to restart a life-critical system by watchdog at such a moment!) Instead, the LM guidance computer worked on a job queue system. Software subsystems would post jobs, and the computer would execute them one at a time. A particular switch was left in the "on" position that shouldn't have been, which meant that subsystem was posting jobs too. The computer found that it had more work than it could handle, and the queue was getting longer, so it was not throwing out low-priority jobs from the queue. The result was the 1201 and 1202 alarms. At no point in time did the LM computer restart.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2018-05-10 08:41 -0700 |
| Message-ID | <gtp8fdtc590bcuhdggdounfka9mp80ihp5@4ax.com> |
| In reply to | #130371 |
On Wed, 9 May 2018 09:29:22 +0200, Wouter Verhelst <w@uter.be> wrote: >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. >> >> The Apollo Guidance Computers in the CM and LM had watchdogs and were >> restarted several times due to faults (1201 and 1202 alarms), > >That's a *very* inaccurate description of the 1201 and 1202 alarms. > >They did not have watchdogs (it would be insane to restart a >life-critical system by watchdog at such a moment!) > >Instead, the LM guidance computer worked on a job queue system. Software >subsystems would post jobs, and the computer would execute them one at a >time. A particular switch was left in the "on" position that shouldn't >have been, which meant that subsystem was posting jobs too. The computer >found that it had more work than it could handle, and the queue was >getting longer, so it was not throwing out low-priority jobs from the >queue. The result was the 1201 and 1202 alarms. > >At no point in time did the LM computer restart. For brevity sake I post this reference: http://blogs.discovermagazine.com/vintagespace/2018/01/05/apollo-11s-1202-alarm-explained/#.WvRmS0xFyCg "Eventually the Executive found that there was no place to put new programs. This triggered the 1201 alarm signaling “Executive Overflow – No Core Sets” and the 1202 alarm signaling “Executive Overflow – No VAC Areas.” These in turn triggered a _software_reboot_. All jobs were cancelled regardless of priority then started again as per their table order, quickly enough that no guidance or navigation data was lost. But it didn't clear up the issue. The computer was still overloaded by the same spurious radar data, stopping new programs from running. In all, it triggered four 1202 alarms and one 1201 alarm."
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-11 04:43 -0700 |
| Message-ID | <dc13c8a9-fafb-4e95-a481-bead6f3d07d7@googlegroups.com> |
| In reply to | #130395 |
On Thursday, May 10, 2018 at 8:41:32 AM UTC-7, Geoff wrote: > On Wed, 9 May 2018 09:29:22 +0200, Wouter Verhelst <w@uter.be> wrote: > > >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. > >> > >> The Apollo Guidance Computers in the CM and LM had watchdogs and were > >> restarted several times due to faults (1201 and 1202 alarms), > > > >That's a *very* inaccurate description of the 1201 and 1202 alarms. > > > >They did not have watchdogs (it would be insane to restart a > >life-critical system by watchdog at such a moment!) > > > >Instead, the LM guidance computer worked on a job queue system. Software > >subsystems would post jobs, and the computer would execute them one at a > >time. A particular switch was left in the "on" position that shouldn't > >have been, which meant that subsystem was posting jobs too. The computer > >found that it had more work than it could handle, and the queue was > >getting longer, so it was not throwing out low-priority jobs from the > >queue. The result was the 1201 and 1202 alarms. > > > >At no point in time did the LM computer restart. > > For brevity sake I post this reference: > http://blogs.discovermagazine.com/vintagespace/2018/01/05/apollo-11s-1202-alarm-explained/#.WvRmS0xFyCg > > "Eventually the Executive found that there was no place to put new > programs. This triggered the 1201 alarm signaling “Executive Overflow > – No Core Sets” and the 1202 alarm signaling “Executive Overflow – No > VAC Areas.” These in turn triggered a _software_reboot_. All jobs were > cancelled regardless of priority then started again as per their table > order, quickly enough that no guidance or navigation data was lost. > But it didn't clear up the issue. The computer was still overloaded by > the same spurious radar data, stopping new programs from running. In > all, it triggered four 1202 alarms and one 1201 alarm." You used it and read multiple reviews and your "diagnostic abilities" lead you to that opinion, so what? Thanks to Dan Cross and his 'friends' you now need a go / no-go list. Do a Google Groups search, publicly (at least) I lately stopped giving him my worst (as of 2009). If Calum and others start up with him again I will jump in... as that is just my way. I'm referring to good people here, not idiots, who think for themselves. A shadow of false reason, projected quickly, at the wrong time. Don't look now, but I think Dan Cross has a serious woody for Calum. Calum just wiped the floor with Dan Cross. I thought showing someone I know where he lives might help the situation. It did not. Real posters will not be seen once the those of us here before the eternal September are outnumbered. That, and there will regularly be a conniption fit or two in an unmoderated news group (i.e. Dan Cross). The comedy of errors aside, we have all seen who regularly gets enraged when he does not get a response. -- Eight things to never feed your dog https://groups.google.com/forum/#!topic/comp.os.linux.advocacy/tzMH39QmAmU http://www.5z8.info/open.exe_f2s2ea_nazi http://www.5z8.info/nic_cage_naked_y8b5qk_torrentEverything Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-05-08 21:24 -0400 |
| Message-ID | <Z4sIC.66534$wG5.5981@fx02.iad> |
| In reply to | #130346 |
On 5/8/18 9:54 AM, supercat@casperkitty.com wrote: > On Tuesday, May 8, 2018 at 2:19:24 AM UTC-5, David Brown wrote: >> On 07/05/18 19:13, Robert Wessel wrote: >>> Not true for typical BSS segments as generated by C compilers, which >>> must have the area cleared. It can be cleared by either by the OS or >>> the runtime, depending on the implementation, but it does need to be >>> cleared from the perspective of the C program. >> >> Except for some embedded toolchains, which do /not/ clear the bss on the >> basis that this would take too long in startup, and that such clearing >> is often unnecessary. This is, of course, non-standard behaviour and >> the source of vast frustration and confusion until you have found the >> problem - and the tiny footnote somewhere in the middle of the 300 pages >> of reference manual. (Yes, I have been bitten by this. Twice, to my >> shame.) > > Speed isn't the only issue. On many platforms, various conditions may > cause or require the processor to be reset while RAM holds useful > information. 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. > That would be almost exactly the opposite of volatile. volatile means the IMPLEMENTATION must behave exactly as described by the abstract machine, and largely unable to fall back on the 'as if' clause, and things may happen 'behind its back', but the programmer may well fully know what to expect. Thus the implementation MUST (in conforming mode) set the values, and isn't allowed to then write the old values back. On the other hand, many embedded systems have an extension which allow a variable (or group of them) to be marked as 'not to be initialized' and it will retain its value through a reset. Yes, I have heard of some which just do this to bss, but those are non-conforming and surprising, but adding something like __attribute(noinit) to a variable, which causes it to be places in a non-initialized segment is useful.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-09 09:10 +0200 |
| Message-ID | <pcu6tg$6nv$1@dont-email.me> |
| In reply to | #130369 |
On 09/05/18 03:24, Richard Damon wrote: > On 5/8/18 9:54 AM, supercat@casperkitty.com wrote: >> Speed isn't the only issue. On many platforms, various conditions may >> cause or require the processor to be reset while RAM holds useful >> information. 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. >> > > That would be almost exactly the opposite of volatile. volatile means > the IMPLEMENTATION must behave exactly as described by the abstract > machine, and largely unable to fall back on the 'as if' clause, and > things may happen 'behind its back', but the programmer may well fully > know what to expect. Thus the implementation MUST (in conforming mode) > set the values, and isn't allowed to then write the old values back. > > On the other hand, many embedded systems have an extension which allow a > variable (or group of them) to be marked as 'not to be initialized' and > it will retain its value through a reset. > > Yes, I have heard of some which just do this to bss, but those are > non-conforming and surprising, but adding something like > __attribute(noinit) to a variable, which causes it to be places in a > non-initialized segment is useful. > As far as standardisation is concerned, I would be happy if gcc standardised things like its "noinit" attribute across targets. This particular attribute exists in the msp430 port - for other targets, you have to use a "section" attribute and make sure there is an appropriate section in the linker file.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-05-08 19:52 +0000 |
| Message-ID | <slrnpf3vv0.31ka.grahn+nntp@frailea.sa.invalid> |
| In reply to | #130340 |
On Tue, 2018-05-08, David Brown wrote: > On 07/05/18 19:13, Robert Wessel wrote: ... >> Not true for typical BSS segments as generated by C compilers, which >> must have the area cleared. It can be cleared by either by the OS or >> the runtime, depending on the implementation, but it does need to be >> cleared from the perspective of the C program. > > Except for some embedded toolchains, which do /not/ clear the bss on the > basis that this would take too long in startup, and that such clearing > is often unnecessary. This is, of course, non-standard behaviour and > the source of vast frustration and confusion until you have found the > problem - and the tiny footnote somewhere in the middle of the 300 pages > of reference manual. (Yes, I have been bitten by this. Twice, to my > shame.) They /still/ do this? I remember being bitten once -- in 1997. That time it was some Texas Instruments thing. "Being bitten" in that case mostly meant confusion within the team, when the language and the toolchain didn't agree; what other differences compared to C were there? /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-08 23:48 +0200 |
| Message-ID | <pct5vo$q2e$1@dont-email.me> |
| In reply to | #130354 |
On 08/05/18 21:52, Jorgen Grahn wrote: > On Tue, 2018-05-08, David Brown wrote: >> On 07/05/18 19:13, Robert Wessel wrote: > ... >>> Not true for typical BSS segments as generated by C compilers, which >>> must have the area cleared. It can be cleared by either by the OS or >>> the runtime, depending on the implementation, but it does need to be >>> cleared from the perspective of the C program. >> >> Except for some embedded toolchains, which do /not/ clear the bss on the >> basis that this would take too long in startup, and that such clearing >> is often unnecessary. This is, of course, non-standard behaviour and >> the source of vast frustration and confusion until you have found the >> problem - and the tiny footnote somewhere in the middle of the 300 pages >> of reference manual. (Yes, I have been bitten by this. Twice, to my >> shame.) > > They /still/ do this? I remember being bitten once -- in 1997. That > time it was some Texas Instruments thing. > It was probably around 1997 that I was first caught out by this. And perhaps 15 years later the second time. Both times it was - like for you - a Texas Instruments thing. "Code Composter", as their toolchain was affectionately known. The second time was for a different target and a far newer version of the tools - it hadn't occurred to me that they would have failed to fix this bug in the intervening time. I have heard of this same "fun feature" in other compilers, but haven't seen it in any I have used. > "Being bitten" in that case mostly meant confusion within the team, > when the language and the toolchain didn't agree; what other > differences compared to C were there? > I was bitten in that when trying to run the system from a debugger, sometimes it would work fine and sometimes not - it made no sense, and seemed to be trying to start from intermediary states.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-04-29 22:07 -0700 |
| Message-ID | <kfnbme1l1tt.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #129945 |
Real Troll <real.troll@trolls.com> writes: > Dr P.J Moylan has written a paper to argue a case against using C. > > <ftp://ftp.pmoylan.org/papers/78.The_Case_Against_C.pdf> > > He argues that: > >> The misplaced loyalty to C is, in my >> opinion, just as serious a problem among >> professionals as the BASIC problem is among >> amateurs. It's a weak paper. He likes Modula-2 better than C, and Modula-3 better than C++. His main point is that C has less structure than Modula-2. Undoubtely true, but not nearly as big a factor as he seems to think. His other comments don't have much substance - they range from strawman arguments to glossing over factors that weigh in C's favor but that he would like to dismiss. His comments about using printf() may simply reflect how dated (July 1992) the paper is, or they may result from having used C less than other languages he likes better. I agree that Modula-2 is better than C along some axes. But there are other axes where C is better, which he either dismisses as unimportant or ignores altogether. Summary: the paper might be interesting to read if you don't have anything better to do, but don't expect to find any real substance or deep insights. It's an op-ed, nothing more. (And yes I am aware of the irony in saying "if you don't have anything better to do", which I certainly do. :)
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-30 12:22 +0100 |
| Message-ID | <70DFC.255449$gE6.166602@fx06.am4> |
| In reply to | #129945 |
On 30/04/2018 03:10, Real Troll wrote: > Dr P.J Moylan has written a paper to argue a case against using C. > > <ftp://ftp.pmoylan.org/papers/78.The_Case_Against_C.pdf> > > He argues that: > >> The misplaced loyalty to C is, in my >> opinion, just as serious a problem among >> professionals as the BASIC problem is among >> amateurs. A rather mild 'diatribe' (as he describes it). Many of the points no longer apply, as of course everyone could have foreseen that 25 years later C compilers would solve some of the problems. Of more serious note these days is the domination of Unix-centric build systems, configuration schemes, makefiles, and the C compilers that go with that. Go outside that domain and nothing works. It makes mere problems with the language pale into insignificance. What's lacking is a name to be applied to that composite 'language' that projects created in such a system are effectively written in, because it's not 'C'. -- Bart C.
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web