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

thp@cs.ucr.edu
20 Nov 2002 15:16:43 -0500

          From comp.compilers

Related articles
[6 earlier articles]
Re: Pointers to "why C behaves like that ?" Gayev.D.G.=?iso-8859-1?Q?=3Cdg=E0ev=40mail=2Eru=3E (2002-11-17)
RE: Pointers to "why C behaves like that ?" qjackson@shaw.ca (Quinn Tyler Jackson) (2002-11-17)
Re: Pointers to "why C behaves like that ?" bobduff@shell01.TheWorld.com (Robert A Duff) (2002-11-17)
Re: Pointers to "why C behaves like that ?" jamesp_spam_me_not@silver-future.com (James Powell) (2002-11-17)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-17)
Re: Pointers to "why C behaves like that ?" mwotton@cse.unsw.edu.au (Mark Alexander Wolton) (2002-11-20)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-20)
Re: Pointers to "why C behaves like that ?" marcov@toad.stack.nl (Marco van de Voort) (2002-11-20)
Re: Pointers to "why C behaves like that ?" n368714668.ch@chch.demon.co.uk (Charles Bryant) (2002-11-20)
Re: Pointers to "why C behaves like that ?" peter_flass@yahoo.com (Peter Flass) (2002-11-20)
Re: Pointers to "why C behaves like that ?" peter_flass@yahoo.com (Peter Flass) (2002-11-20)
Re: Pointers to "why C behaves like that ?" er+cc@cs.brown.edu (Manos Renieris) (2002-11-20)
Re: Pointers to "why C behaves like that ?" md9slj@mdstud.chalmers.se (Stefan Ljungstrand) (2002-11-20)
[55 later articles]
| List of all articles for this month |

From: thp@cs.ucr.edu
Newsgroups: comp.compilers
Date: 20 Nov 2002 15:16:43 -0500
Organization: University of California, Riverside
References: 02-11-095
Keywords: C, design
Posted-Date: 20 Nov 2002 15:16:42 EST

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


Post a followup to this message

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