Of course. This allows you to study those areas closely for gnits and gnats, without discarding the assistance given in the majority of the code. You accept such limitations everywhere. For example, I fail to see a standard C method of accessing i/o ports. This is normally relegated to the ubiquitous "i/o library". The connection of the i/o port to the peripheral device is normally left to the hardware engineers.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
C++ is a superset of C, this is fact not belief. C++ is not isloated from the machine, it provides a clearer mechanism to talk to the machine. Java or C# would be examples of languages that are isloated from the machine except in the case of C#, it also has the ability to use "unsafe" code meaning the use of pointers which makes it a potentially superior language to Java in this regard when performance is regarded more highly than reliability.
What happened to the discussion of the Rover's OS priority inversion problem? Looks like the same thing happened in 1997.
Personally I don't like having my tax dollars wasted on sending devices to snap pictures of rocks on Mars when people are dying of Cancer and other diseases here. Even if fruit-bearing aliens are discovered there, unless they know something about fixing our problems on this planet. like priority-inversion or Cancer then what good are they?
Dilton
There has already been a decades long project to improve the reliability of C, participated in by thousands of programmers on real projects.
Its called C++. If you read Stroustrup, he states one of his goals to be to provide new, better mechanisims to address the security problems with C, so that programmers will slowly evolve towards the new constructs.
The result of the experiment so far is clear. If you add something to C, programmers will use it. In addition to using everything else in C, safe and unsafe.
Some committee can decide gravity does not exist, but that does not make it so. as long as:
void x(void)
{int a; int *b;
b = &a; b *= 10;
Works, then there are problems with the language. And the problem is fundamental to the language. Even if you simulate C, there is no way to find out what a programmer really wanted to do with that pointer.
This is what I read: "This problem was not caused by a mistake in the operating system, such as an incorrectly implemented semaphore, or in the application. Instead, the software exhibited behavior that is a known "feature" of semaphores and intertask communication.".
The article doesn't say that the workaround was not documented. It says, "In fact, the RTOS used on Pathfinder featured an optional priority-inversion workaround; the scientists at JPL simply hadn't been aware of that option.".
I've stated in this newsgroup exactly twice before that I and colleagues have written IVR software that ran stably on Windows NT (several years ago) for 1.5 years before rebooting, and then only for good measure. Many people whom I respect who have experience on both Windows and Linux agree that there are just as many if not more problems with stability on Linux. Open Source has its place but it is not the answer to reliability, though it's nice and helpful to have the source.
Dilton
I saw that to. And I thought they said at that time that the longest test of the system had been 8 days (if my memory serves me right).
A 90+ day mission to Mars and you never run a test for more than 8 days? That seems a bit short to me.
I believe he was referring to the belief (stated by Stroustrup himself), that C++'s better methods would replace the primitive methods in C. For example, Stroustrup is very anti-macro use, and proposed const to replace the need to use it to replace the most basic need for defines.
The problem is, in the real world, C++'s better methods have not replaced the old methods, most programmers I run into just see C++ as a bigger toybox, and thus C++ is not (effectively, defacto, whatever) both a complex AND insecure language.
BTW, I am a big fan of Stroustrup. His take on language security is very similar to my own. He wanted to improve C, instead of simply build a new language from scratch, because he wanted his project to be relivant to the real world, and hoped to improve C programming in general.
He didn't succeed in getting rid of C's bad practices. I don't think anyone ever could. Wirth said it best on this subject: If you include features in a language, they are going to get used, for good or bad.
I agree in general, my father died of cancer, and I have a friend who is dying of it. However, Nasas budget is a drop in the government bucket, and there will always be a reason not to advance space exploration, do basic science like cosmology, and the other esoteric things we have to do to become a higher level form of life and not just rats scurrying along on a single planet.
Our two biggest expenses in the USA right now are social engineering, and this odd, sad, and perhaps inevitable need to become the keeper of order for the entire planet. I would not personally mind scaling back either, but that is just me.
But the article *does* say that the priority inheritance option was intentionally left out by WindRiver to optimize performance.
">The Wind River folks, for many of their services, supply global
It seems pretty clear to me that WindRiver both knew about the potential problem and how to fix it without making that information available to the typical user of their products.
Whether or not this is an important issue is debatable, but the facts are clear.
-- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
I hope your not trying to spin up some UFO theory, it's obviously just a weather balloon. Right there in Death Valley, where the two rovers were recently deployed. ;-)
River.
the
rickman,
Please provide that quote from the article, my 40 yr old eyes must be failing me. :-)
What I got from the article was:
1) NASA determined that priority inversion was the cause of the 1997 probe failure. 2) NASA had since 1997 to figure out how to fix this. 3) NASA sent the latest probes to Mars on US Tax dollars with this known problem and it happened again.Dilton
C++ cannot compile valid C programs, therefore it is, ipso facto, not a superset. A trivial proof:
---------- cut here ----------- #include #include #define Puts (void)puts
static int new(void) {return 100;}
int main(void) { int *namespace; unsigned int cin = 2; const char notc[] = "Not a C compiler"; const char *maybe = "May be a C compiler";
if (sizeof('a') != sizeof(int)) Puts(notc); else Puts(maybe);
if (!!(namespace = malloc(5 * sizeof *namespace))) { namespace[0] = new(); free(namespace); namespace = NULL; } if (0 != (2 >> cin)) Puts(notc); return 0; }
---------- cut here --------
which should compile error and warning free on any C compiler. I doubt that it will on any C++ compiler whatsoever.
I took some pains to ensure the above triggered no warnings with splint.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
My 50 year old eyes found it :)
Did you follow the link titled, "Re: What Really Happened on Mars?"? In that one of the engineers on the project explained exactly what happened and why.
">3) The priority inversion option was deliberately left out by Wind River in
-- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
In stroustrup, he explains about a dozen "worst" practices of C that did not get carried on to C++. Some of them were deliberate omissions to get rid of bad C features, some were C features that were simply unsupportable. None of them were particularly essential.
Uuh.
We at our company (search this group if interesseted which one :-) wrote an RTOS which is very easy: 6 systemcalls are enough to handle most problems (no, not 100 parameters :-)
-- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use @epost.de instead !
Big statement. Our customers get the sources. But I doubt they will really understand it nor even want to understand it. (And our source code (though assembly) is shorter than the one from WindRiver,M$)
But: If something goes wrong, having the source is a plus.
-- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use @epost.de instead !
It would be pleasant to be able to read that article, but it apparently contains some evil HTML, at least as far as Netscape
4.75 is concerned. Without images it appeared to be missing most of the meat, so I told it to load images, and it never completes loading.Show me the code.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
Yes, I would expect aborting the program to lead to its termination, but I'd be surprised if it got any address exceptions after being aborted ;-)
Actually, we (or at least I) don't know that the Rover problems had anything to do with improperly handled out of memory conditions. I know you have a thing about C, but I really doubt that the problems had anything to do with failure to check the return from malloc. Even if the programmers aren't capable of remembering this simple rule, lint will pick it up.
Anyway, depending on the system design, aborting the program and letting the system-wide fail mechanism take over can indeed be the best way to handle a problem. (In general terms - I don't know about Mars Rovers.)
-- Al Balmer Balmer Consulting removebalmerconsultingthis@att.net
Reads alright in Konq but the article does *not* that priority inheritance option was intentionally left out. What is says is:
This problem was not caused by a mistake in the operating system, such as an incorrectly implemented semaphore, or in the application. Instead, the software exhibited behavior that is a known "feature" of semaphores and intertask communication. In fact, the RTOS used on Pathfinder featured an optional priority-inversion workaround; the scientists at JPL simply hadn't been aware of that option. Fortunately, they were able to recreate the problem on Earth, remotely enable the workaround, and complete the mission successfully.
HTH
Ian
Big statement :) If your customers have $400 million and their national pride flying 100 million miles away, and a software problem develops, they will damn well WANT to understand your sourcecode, and will put however many brains are required into that task. If the problem cannot be solved, then you better watch out for a scapegoat-crucifixion squad knocking on your door...
It's the only way to go. Look, even leaving issues like secrecy and disclosability aside, if I have a problem with my app on your OS, it is MUCH MORE EFFICIENT for you to give me the source for the OS than for me to give you the source to the app(*).
In theory, you have already given me all how-and-why documentation on your OS as part of the package (and if not - what the hell am I paying for?). In theory, I have already read and understood all this documentation. So I'm theoretically way ahead of you - I understand ALL of my app and ALL of your OS (that you disclosed to me). Whereas if I give you my app, I need to teach you all about my design priorities, how I did things, and why I did them that way.
(*) - This statement is hereby limited to the special case of realtime applications on RTOSes.
What code?
Try this link.
BTW, I had no trouble viewing either page using Netscape 4.73. I don't think your problem was either the browser or the page.
-- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
Follow the money... I mean links!
-- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.