Frank Heckenbach wrote:
CBFalconer wrote:
Frank Heckenbach wrote:
CBFalconer wrote:
Frank Heckenbach wrote:
... snip ...
However, the main point is that warnings that are left in will be seen by everyone who compiles the software, not only by the one who wrote the code. In the end, this will lead to the situation we mostly have in C now, where everyone expects to see some warnings when compiling something and almost nobody cares about them. We could just as well turn them all off then.
To me, that is a sign of bug-ridden C code.
Sorry, what's your point? Last time you said: "Thus the Pascal programmer should be prepared to evaluate and accept warnings on compilation." Now you say "[getting lots of warnings is] a sign of bug-ridden C code." Do you want us to get to the same situation where C already is?
I was talking specifically about C there, not Pascal.
But I still can't see why getting lots of warnings should be more acceptable in Pascal.
First, there won't be many warnings. Secondly, things that generate C warnings because they are suspicious are normally just not allowed in Pascal. For example, you can't assign a char to an integer, or an integer to or from an enumeration, or a real to an integer, etc. Those things will generate Pascal errors, but at most a C warning, if that. Any attempts to play C style games with pointers will result in errors.
Thus warnings should usually be about things that harm portability, but are understandable to this implementation. This includes the use of extensions in Standard mode. Unused parameters would probably be an exception to this generality. Unused function return values should be handled by assignment to a specific junk variable, and should be very rare. Many C foulups are due to ignoring error returns from functions, so making this hard to do in Pascal is a GOOD THING.