The company hasn't used VxWorks for a number of years and I wasn't part of the board support effort at the time - I was doing application work. I don't know if the archives go back that far, but you can search for posts by Mark Fisher (mfisher) re: dosFs - he was quite active in the VxWorks ngs for a while.
George ============================================== Send real email to GNEUNER2 at COMCAST dot NET
I am glad you have also had good experiences giving the source code to your clients. However, this should only be done within the context of a suitably trained client who is going to carry on using decent development practices for anything they are going to change. For the rest, keep the code away from them but be prepared to help them with the problem solving (I speak from the context of providing completed High Integrity Distributed Embedded Control Systems with no client written code).
Where you are proviing just the underlying OS or base-line software to which clients are adding the application code then I suppose the issue gets somewhat muddier.
-- ******************************************************************** Paul E. Bennett .................... Forth based HIDECS Consultancy ..... Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE...... Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details. Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
Superb! Thanks. Those are keepers ;).
Steve
The proof that intelligent life exists elsewhere in the universe is that it wants nothing to do with us.
I wouldn't be so quick to dismiss space research. If every medical procedure which came directly or indirectly from warfare, and every device or object which began as technology tranfer from the military, or came out of military or space research were suddenly taken away, you'd find yourself circa 1800 with a life expectancy of 50.
George
============================================== Send real email to GNEUNER2 at COMCAST dot NET
I would'nt neither, but
if all these trillions of Dollar all over the world would have been spent for medical research and renewable energy, the world would look much better (and maybe ET would give us a call :-)
-- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use @epost.de instead !
Lint, which nowdays is built into the better compilers (gcc, etc), is a band-aid. Certainly you can catch some problems, but others not. For example, the routine:
void a(int *b)
{b *= 100; *b = 5;
Cannot be caught because the compiler has no idea where b came from or what it points to. There is no underlying model of safety for lint to use.
Lets fast forward. There are a lot of tools that do "super lint", and even try to simulate limited runs of the C code to determine if problem areas exist. I unfortunately got the job of administering such a tool set for a large company. I say unfortunately, because I got the assignment due to the fact it was a sh*t job that nobody wanted, and all anyone remembered about me was that I seemed to complain about code quality a lot.
What occurs in real life is that you get massive amounts of warnings. If the code had not ever been compiled with something like
-wall (gcc for "warn all on"), this would be a massive clean up project which most companies would balk at. This company had been running -wall tho, and the warnings were considered manageable. However, there was a multimonth cleanup project that would have to occur. To give you an idea of it, the tools were complaining that "printf" returned a value that was ignored. When was the last time you saw the return value of printf used for anything ?
Anyways, the convertion project was in fact completed. THings like "=" used inside expressions were banned. Although everyone knew there was no way to catch every wrong pointer reference in C, the theory was that making the code as clean as possible would make it as stable as possible.
What you obtain with C in conjuction with such testing is C whose usage is fairly restricted. The toolset, I think properly, was complaining about initalizations that were not obvious, for instance, if the initalization was done in a remote function, or had a condition attached to it, it was flagged, even if the programmer knew that it would get initalized despite the conditional.
So you get C with a truckload of restrictions, and you still have the possibility of wild pointers. Any computer scientist worth his salt will tell you that C is not going to be %100 verifiable no matter what you do.
If you live with this, you will have better quality certainly. But my question is, if you live with all those restrictions, and give up the wild west style of C,
Why again is C a better idea than a language that had type safety built in from day one ?
of
class
Agreed. Trouble is that too many people let that same "beginning shop class" loose on projects of major importance. The only way to get decent software is to put the novices alongside great designers and programmers who have the wisdom to know what they can delegate and the patience to review the novices' code from time to time. Of course, they should also have their own code reviewed by the novices, so that both may learn something. Most people would use "better" languages if they could get close enough to the hardware - and the memory and performance requirements with them. That day is not yet here, for most projects.
-- Peter Bushell
[...] [...]
Lint is *not* built into gcc. Gcc is *far* better at reporting problems than any C compiler I used 20 years ago, but good lints are also much better at _their_ job.
It's more like water when you're running a marathon: necessary but not sufficient.
No need to make it so complicated (and make the same mistake you made earlier: any compiler that doesn't detect a problem in that code is
*broken*).Here's an actual example:
--- begin included file --- C:\Dave>type vtlint.c void set(int *b) { b[100] = 5; }
int array[100];
void test() { set(array); }
C:\Dave>lint-nt -u -passes(2) vtlint.c PC-lint for C/C++ (NT) Ver. 8.00n, Copyright Gimpel Software 1985-2003
--- Module: vtlint.c
/// Start of Pass 2 ///
--- Module: vtlint.c
During Specific Walk: File vtlint.c line 10: set([100]) vtlint.c 3 Warning 415: Likely access of out-of-bounds pointer (1 beyond end of data) by operator '[' [Reference: file vtlint.c: lines 3, 10] vtlint.c 3 Info 831: Reference cited in prior message vtlint.c 10 Info 831: Reference cited in prior message
C:\Dave>
--- end included file ---
Impressive, eh? PC-lint does try to find out where b comes from, and is usually quite successful.
Note: the "-u" option disables warnings like "test defined but not called," i.e., it does a "unit" lint rather than a "whole program" lint. The "-passes(2)" option tells lint to make a second pass to specifically look for errors like this. The "831" info messages are references for editors that automatically parse error messages and locate the cursor on the specified line.
Lint early. Lint often. Lint is your *friend*.
One (complete, buggy, never-before-linted) project I linted generated an error file three times the size of the source code.
PC-lint has a very flexible means of disabling unnecessary warnings. In the case of this specific example, the default configuration for all the supported compilers includes "-esym(534,printf)" which says "don't report error 534 for the symbol printf."
Flatly banning things replaces thinking with rules. Rules alone will never solve all your problems. There is no silver bullet.
It's better to allow such things, but require them to be justified.
Again, with PC-lint it's quite easy to suppress a specific message with a comment in the code. A code review can verify the justification in the maintenance phase.
True. But even languages to which formal proofs can be applied are vulnerable to bugs in specification. TANSTAAFL.
C never competed with Pascal or Ada or any other HLL (with or without type safety). C was competing (and in many cases is still competing) with assembly. It's popular because of:
1) Target platform support. The only microprocessor/microcontrollers I can name that don't have a supporting C compiler are 4-bitters. 2) Serendipity. C was becoming popular just about the time embedded microcontrollers were getting large enough to support HLLs and compiler technology was getting to the point where the generated code was nearly as good as hand-crafted assembly. 3) Perceived efficiency. C is a lower-level HLL. Especially for embedded work, the bitwise operators were a great boon. 4) Inertia. Most embedded programmers know C. Most embedded jobs involve programming in C. Each feeds of the other. Embedded programmers, as a rule, are a conservative bunch. They stick to what works. They are suspicious of abstraction.Summary: I'm not really arguing with you here. My points are 1) Lint is better than you think, 2) without C (or something like it) we (this
*is* comp.arch.embedded) would still be mired is assembly. Which is wilder and wester than C. ;-)Regards,
-=Dave
-- Change is inevitable, progress is not.
Well, with Ada (a "better" language) you can get as close or closer to the hardware as you can with any other language above "assembly". As for memory footprint, if you don't need the Ada runtime just leave all or part of it out. The main technical barrier to use of Ada in small embedded applications is the near total lack of Ada compilers for 8 and 16 bit targets. Some people have toyed with GNAT (Ada 95) ports that target Motorola 68HC11 and Atmel AVR but that's about as far as its gone.
Britt
There has been some interesting recent research on introducing type and memory safety into C, e.g. Cyclone:
-Dave
That is a silly argument. Instead of paying a large fortune to sent rockets and people into space, we could have spent *all* that money on pure research and come up with a *lot more* inventions and discoveries.
Same with maintaining a large army. I am not saying we don't need one, but if we could do without it we could spend the same money on research and have many times that left over.
-- 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
Do you really think so? My take is that pure research yields incomprehensible papers and absurd projects constructed to increase the job security and empire size of the researcher. Not that
*that* hasn't happened at NASA. nudge nudge, wink wink. To get useful *stuff* you have to have a profit motive in this day and time.Non-sequitur. If we didn't build roads, we could spend the money on research.
Researchers build the big groups and delve into strange areas as a way of making themselves seem attractive to those few agencies that can afford to sponsor research. Researchers that succeed in attracting the funding can get some modicum of job stability as long as they are willing to stay on the research money treadmill.
It would be a good experiment to put some number of researchers on 5 or 10 year stipends and see what they come up with without the money folks hounding them for progress all the time.
Maybe we could get those overdue flying cars into the marketplace. :)
Kelly
No, it cannot find this out all the time. It is not a %100 solution. Type safe languages are a %100 percent solution.
Again, all this accomplishes is loads of (possibly irrelivant) warnings that if you correct, you might have better code. No matter how good it is, it cannot be %100 complete, because the information to do that does not exist in the C language. Other languages do not have that restriction, and don't need to issue warnings for everything, and don't need to use words such as "likely" and "possible" in their output. If you have misused an array reference, that is known, its an error, not a warning. If you have misused a pointer, that is an error, not a warning.
I don't doubt that your lint program is very impressive to you. To me, its a very complex program that is completely unecessary in other, type safe, languages.
Every pasture has sh*t laying on it. That does not make same a good product.
This is the same as point (1), ie., "there seem to be more C compilers in the world". There is no particular efficiency advantage to C.
"perceived". Well put. The efficiency advantage of C lies between the programmers ears.
Fortran had this advantage as well. Is fortran popular now ?
Ive done more work with "super lints" than anyone here, and most likely you as well. Dumping lots of "possibles" and "likelys" on the programmer is not productive programming, it is programming by paranoia.
If the compiler is worth a damm, it can check absolutely if the program is right or wrong. C compilers cannot perform this act because the language does not let the compiler do it.
Now notice the subject of this thread. A $800 Million dollar Mars lander was sent across space to be felled by a 2 bit software error. C and "super lint" have no place in the scope of $800 Million of our tax dollars.
Not correct. The language used for most embedded is pure happenstance. I don't use C in my embedded work unless the customer requests it. It delivers a less reliable product for more work, and it is not the appropriate language for any serious work, IMHO.
It CERTAINLY is not appropriate for life support applications or serious money work. In fact, it is probally a worse choice than assembly language, which is at least transparent. C removes transparency from the code without removing assemblys bug potential, a disasterous combination.
No, you just don't get the point. Saying that the side benifits of research are a justification for having an army is a specious argument. The benifit could be gained by directly funding the research and saving all the money otherwise spent on the rest of the army (or NASA or any other budget item). It has nothing to do with the item being funded, roads, guns or butter!
-- 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 couldn't agree more.
Since when does any government "save all the money otherwise spent" You almost gave me a coffee spew. The system is the way it is because it rewards the entrenched power structure. Not because the government started out to *want* the army or even NASA to be a commercial or pure innovators. The army is supposed to deter and win wars. NASA is supposed to explore space. I think we can all agree that anything else is just fluff to justify more money from the public trough.
See my above comment about getting anything useful out of pure research.
Plato said "necessity is the mother of invention", and to a large extent I believe that. People just don't look for things unless they are needed. The engineering mantras "better is the enemy of good enough" and "if it works, leave it alone" are symptomatic of this approach to life.
It is probable that many of the inventions produced by war, military and space research would have been made anyway, but arguing that in hindsight is just wishful thinking. Without the competitive pressure of these environments, the observations which led to the discoveries may not have been made, or critical results may have been overlooked or not followed up on because there was no pressure to do so.
The competition that exists today between universities and private research today over prestige, funding and eventual profit is difficult to compare to the threats of war. A lot of research in the early space race was conducted in a war frame of mind - any gain in technology or practical experience by either side threatened the security of the other.
The only thing we have today that is remotely similar might be vaccine research to combat bioterrorism. This research might make some wonderful discovery about viruses that eventually cures the common cold. But keep in mind that the common cold is a minor annoyance at best and few researchers will ever study it directly. Any progress in fighting it inevitably will come out of other avenues of reseach.
George ============================================== Send real email to GNEUNER2 at COMCAST dot NET
Researchers often have a poor track record of "productizing" their results. Ie, the funding comes from coming up with new ideas, not with taking existing ideas and making them workable and practical.
On the opposing side though, funding that is intended to get actual results tends to stifle the creative aspect of research (ie, corporate funding that comes with unwritten strings attached). So there really needs to be a mix of both types of funding.
--
Darin Johnson
"Look here. There's a crop circle in my ficus!" -- The Tick
I think this conversation has gotten a bit absurd. Are you saying that the possibility that we might find a cure for the cold is a justification to fund anti-terrorism research? That would be the parallel to the research justification for funding NASA if I understand you correctly.
If you want to find a cure for the cold, then fund research to find a cure for the cold! If you want to send men to Mars, then fund NASA. But don't try to justify funding NASA because it might produce side benifits. Is that so hard to understand?
-- 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
... snip ...
I can't remember the name, but just such a foundation exists in the US, and has an impressive record. The people they fund are basically free to pursue any avenue of interest.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
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.