Re: Pointers to "why C behaves like that ?"

Quinn Tyler Jackson <qjackson@shaw.ca> wrote:
[...]
+ Even if we were to have sharp eyes and catch a mistake like that,
+ human readers of the code would have to ask themselves "How large a
+ value can CurrentAmount hold?" If CurrentAmount + newAmount is greater
+ than that value, will CurrentAmount hold the new value?


Dynamic resizing of objects isn't rocket science.


+ We might say that "all undeclared variables are assumed to be of type
+ int" but then we have another problem: We have to look through the
+ headers to determine if CurrentAmount *has not* been declared, and
+ then, if we can't find it anywhere, assume it is an int. But what if
+ we couldn't find it because we didn't look hard enough, and it turns
+ out to be a char?
+
+ Forced declarations, besides allowing the compiler to catch typos,
+ allow human beings to track down the source of less obvious mistakes,
+ such as overflow.


Static analysis tools can annotate code for us.


+ Granted, some of the above *could* be automated. Something akin to
+ lint could catch the mispelling example above (but not all cases), as
+ a "dead assignment". Potential overflow can also sometimes be flagged.
+
+ But, even with a magically perfect form of lint that somehow managed
+ to beat the HP and could scan at the level of intent (parse what I
+ mean, not what I write), declarations serve as a form of code
+ documenation, for mere mortals.


Requiring programmers to provide compilers with information that can
be statically inferred is an unfortunate waste of human resources.
Where types can be inferred statically, they can be annotated into the
source code via static analysis tools. Where types cannot be
statically inferred, the programmer ought to get a warning but the
execution can proceed on the basis of dynamic typing. Let the
programmer decide how he/she wishes to proceed.


Tom Payne

Return to the comp.compilers page.
Search the comp.compilers archives again.