The above is a fundamental error - multiplication cannot be performed on a pointer. If you change it to "b += 100;" you have a point.
At any rate lint has a fundamentally different purpose than the compiler. lint should point out any questionable areas which may require review.
Last week :-) Certainly from sprintf it can be very valuable. Most lintlike tools can be configured to ignore those values. One convention I have adapted is to use a define:
#define Printf (void)printf
note that the only visible difference is the case of the first letter, so it is easy to get used to.
That is a poor ban, because it gives up some of the better and clearer C flow structures. For example, initializing space within a malloced space:
Not quite so, but true in practice. The overhead required to make C largely verifiable would simply overwhelm its good points.
Many will simply be annoyed by the necessity of thinking about what they are writing, which in turn is necessitated by languages with strong typing, and especially subranging. At the same time those features are what enables most checking to be performed at compile time, and minimizes the need for run time checks and their overhead.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
Excrement of a male bovine. There is no silver bullet.
[...]
Again, excrement -- well you get the idea. If you lint often, you learn to avoid constructs lint considers dangerous. If you lint early, you catch and eliminate the worst problems (which are often typos) before they become hidden in reams of code and other errors. You don't ever get "loads of (possibly irrelivant) warnings."
Again, there is no silver bullet -- or in words you seem to like better, there is no "100% complete solution."
If you have a language which does not allow you to "abuse" pointers (and other data types) in a useful manner, you have a language that is, at best, a toy. Toy languages must be extended to be useful. If you're luck, they extend the same way. Delphi, Turbo, GNU, and FreePascal all allow typecasts with a syntax similar to C++, e.g.
charptr := PointerToChar(intptr);
My, what a long nose you have...
I was merely answering one of the most-often-given objections to lint
-- yards and yards of useless warnings
You go ahead and believe that, if it gives you comfort.
[...]
If you're freezing to death, burning cow pats for heat is a far superior solution to wishing for a cord of seasoned firewood.
No so, it is more an explanation for point (1). Chip and tool vendors saw C as an "easy" HLL to implement, one which left a great deal of control with the programmer (to make the auld fartes more comfortable), but provided some abstraction from the bare wires. It's still better than raw assembly.
Let me tell you about my first experience with Pascal on a micro.
I learned programming in Pascal (after one semester of basic BASIC in High School and one quarter of introductory FORTRAN in College). I was a _BIG_ fan of the language.
The application was a graphic screen dump for the IBM PC. Winter
1982. Original PC, 64k RAM (Wow!), CGA, using edlin and the two-pass IBM Pascal compiler (one disk per pass).
TSR. Read the video memory, reformat for the printer binary output mode, use the BIOS to write to the printer port. It worked well enough (certainly faster than the printer. But I couldn't get it less than 25k.
No good.
Re-write in assembly. Less than 2k.
Never tried it in C, But I can tell you the "perceived"
*in*efficiencies of Pascal (pre-turbo) and similar languages were well-earned.
Actually yes. So is COBOL. Neither was ever popular for embedded work, though.
You've done more dumping on "super lints" than anyone here, which leads me to believe you know very little about C, lint, or embedded programming. When working on embedded systems, paranoia is a *good* thing.
I take it you've never heard of the halting problem.
Good idea: read the thread. You'll find the Mars lander was "felled" by an error that had as little to do with C as the error which "felled" Ariane 5 had to do with Ada. Summary: somebody called a function with the wrong value for an option parameter. The option used was legal, but it was wrong. The code could have been written in assembly, Pascal, Ada, Forth, MODULA-2, Z, or any other irrelevant language you wish to pull out of you hat. None of them could have caught the error.
Attributing magic properties to any language is worse than futile. When the language fails to live up to its billing, the critics come back and say, "See? You shoulda done it *my* way in the first place."
I'm not sure how to respond to this. That's sort of what I've been saying. Although I would call it serendipity (or "being in the right place at the right time") rather than "happenstance."
There are good reasons C is as popular as it is. There are good reasons it shouldn't be. But it is. And it will remain so. And there's nothing you or I can do to change that. There's too much intertia.
So what's wrong with trying to make lemonade from the lemons we've been given?
Lemonade is pretty tasty.
Prithee tell, what *do* you use, and for what platforms?
Now you're sounding like one of the auld fartes. Get thee behind me!
Regards,
-=Dave
--
Experience is the name everyone gives their mistakes.
-Oscar Wilde
A dream of competence, too closely confronted. iddw@my-deja.com
I guess there aren't any compilers worth a damn, then.
Here are some of the errors that you are expecting the compiler to handle: (a) lexical errors, detected by the scanner recognizing the lexical tokens of the language (b) syntax errors, detected by the parser building the parse tree for a program (c) static semantic errors (i.e., a contextual constraint) detected by semantic analysis of a program, (d) dynamic semantic errors, detected by code generated by the compiler (e) logic errors, in which the compiler does what the programmer specified, rather than what the programmer intended
What is wrong with this? p = malloc(sizeof *p); if (!p) return errnomem; else { p->cp = malloc(strlen(s) + 1); if (!p) { free(p); return errnomem; } else { /* all fields allocated */ strcpy(p->cp, s); dowhatever(); return noerr; } }
--
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 don't plan on dignifying your anal answer by repeating it. I am not going to fight in the same mud as a pig, so I guess we are done.
The main points (for other, civil readers) are:
o This is about reliable languages for billion dollar spacecraft and other critical technologies.
o The fact that there is no "perfect" safe language is hardly an excuse for giving up completely and using poorly thought out trash as your base language.
o Better and better band-aids is not the solution. "because we have always done it that way" is not a solution. Because "everyone else does it" is not a solution. The solution is to get it right.
o It is not a dry argument. There are plenty of type safe languages on the market. There were before C came about, and there has been a general return to type safe languages in recent years by dissatisfied C users, in the form of Java and C#, which themselves came about principly because C cannot be made type safe no matter how much silk you bolt on to the sows ear.
o Our billion dollar spacecraft makers, and anyone who deals in very expensive or life support applications, need to do the responsible thing and use type safe, "best practices" languages, and not copy the dismal state of reliability that is the majority of the software industry "just because everyone else is". Everyone else is not building a mars lander with public money.
o The software industry is experiencing a general recoil from the excess dependence on type unsafe, "party hearty" languages of the last century, and trying to move forward to better solutions. The C language era has led the software industry to yearly new lows in reliability and maintainability. We, as an industry, have completely lost the trust of the general public. We went from having, a perhaps undeserved, reputation of infaillability in the mainframe and mini era of the 1960s and 1970s, to an unfortunately very deserved reputation of constant unreliablity and bug-ridden undependability. This will be an almost impossible or even completely impossible, to remove reputation. The loss of confidence in the US automotive, steel and similar industries pales in comparision with the bad reputation that the US software industries have gained. Many of our software jobs are being exported overseas, especially to India, and there is every indication that India's software developers, far from being cheap knockoff shops, "get it", why the USA lost command of yet another important industry, and are emphasising quality over the standard USA values of quantity and cut rate, poorly thought out crap.
I'm not sure I understand you. The following code is type-safe but doesn't work:
float sqrt(float x) { return -1.0; }
There are certainly better, richer type systems out there, like dependent types and subtypes. An issue with that is once you make the type system rich enough to specify useful things, then it becomes difficult or impossible for the compiler to automatically decide if the types are right. In one environment I use that allows subtyping, you may have to provide proofs to the system to allow it to accept your code.
Personally, I'm a big fan of good type systems. But as long as users want the convenience of automatic type checking then the type systems will have to be sufficiently simple that they can't express much in terms of overall correctness.
which are leading to rightwards expansion. The "if/else if" keeps the tests in order and obvious. The worst is that the above is testing the wrong thing, which mistake is harder to make with the if/elseif construct. I am also unhappy with the vertical expansion.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
No, there are plenty of decent compilers around. It's the job of a compiler to determine whether or not a given source conforms to the formal definitions and constraints of the language in question and, if so, to translate said source into into another form - usually machine code or some intermediate language. If the source is in error, then the compiler should explain where and why. It is NOT the job of a compiler to try and work out whether the code actually does what the programmer meant it to - that's simply impossible, both in theory and practice.
Well.... sort of. Very few errors get caught by the lexer/tokeniser itself, and pretty well none in symbol table lookup. Nearly all typos are actually caught by the parser. For example:
int 3teve = 12 ;
No problem for the lexer, it tokenises the line as something like:
The error is only caught when the parser finds it can't locate any rule to reduce the sequence ...
It's rather academic though, since the lexer, dictionary, and parser are usually highly-integrated in recent compilers, and it's often hard to see exactly where one ends and the other begins. Such integration makes the job of error reporting and recovery much easier, somewhat ironically.
Not sure what you mean by that. The only real semantic analysis performed by compilers (for "main-stream" languages, anyway) is of data-flow, and that's really only there for optimisation purposes, if it exists at all.
Huh? That sounds like a compiler bug, to me. Could you give an example.
No, I simply do not expect a compiler to "handle" such errors. Nor do I expect it to handle the other major category of bug you missed - errors of omission, where the code does not handle unexpected events or input in a predictable way.
I don't really think any programmer who expects a compiler to fix his bugs for him is going to progress very far in his chosen profession, do you?
That is, of course a statement composed of an expression followed by the terminating semi-colon. Assignment operators can only be used within expressions, according to the language definition.
You've rather shot your own foot off here, by introducing a bug - your code doesn't do the same as Chuck's:
Whoops! I think that should read: if ( !p->cp ) {
You seem to have illustrated why it's a good idea to use a single expression rather than split it across two statements - there's less chance of making a simple error of that sort.
Hmmm, didn't seem that anal to me, but then looking at your web site I see you have an agendum to pursue. I wonder how many customers that comment's lost you?
Excuse my typo. I started with your code and converted. Normally I would be writing from scratch and not dealing with copying mistakes.
So the difference to you is a matter of style? I was taught differently, that it is preferred not to do assignments in tests for if or loop controls. It is not uncommon that things get fouled up because people don't understand the order of events, just like it is better to "clutter" things up with parens rather than to use the default precedence of operators. The next guy reading your code may not be as familiar with all the defaults and such.
Seems to come down to a matter of style.
--
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 believe that? I don't think a single typo is a valid statistical sampling.
Actually, if I were writing the code I would have used *my* style which helps *me* to avoid bugs such as this. Chuck uses a compressed style which makes the listing shorter, but crams more into each line. To me, this makes code more prone to misinterpretation or error. I prefer to write in an explicit style that makes the flow obvious (to me anyway).
BTW, it has been a couple of years since I have touched C code. VHDL is more my domain these days and I find the strong typing to be useful even if it is sometimes combersome.
--
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
Interesting assertion and may even be true, but from whence came the data to support it?
I seem to recall the same complaints in the 60s and 70s (and 80s and 90s and...). Programs weren't nearly as bloated in the earlier days which inherently improves reliability.
Seems to follow the rise of Microsoft into prominence...
Most of the work being "outsourced" to India seems to be done strictly for price.
That would seem to be true. The reason it is not is that complex types are built up from simple types. The compiler need only check the simple types.
Now a separate, but relivant idea is if it can be proven that a given set of types can be proven correct. This is the area of computer theory, not code. Just as mathemeticians can perform proofs, so can it be proven that types are safe even if used in unforseen combinations. In many ways, the mathematical basis for numeric systems is similar to the computer theory basis for types. In brief, mathematics has the concept of "fields" for number theory, and computer systems such as types, and even the Von Neuman computer archetecture we use obey field properties.
Again, not true. Any type of any complexity can be verified.
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.