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

"Quinn Tyler Jackson" <qjackson@shaw.ca>
17 Nov 2002 23:17:12 -0500

          From comp.compilers

Related articles
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 ?" thp@cs.ucr.edu (2002-11-20)
Re: Pointers to "why C behaves like that ?" jacob@jacob.remcomp.fr (jacob navia) (2002-11-24)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-24)
Re: Pointers to "why C behaves like that ?" joachim_d@gmx.de (Joachim Durchholz) (2002-11-24)
Re: Pointers to "why C behaves like that ?" jacob@jacob.remcomp.fr (jacob navia) (2002-11-26)
Re: Pointers to "why C behaves like that ?" fjh@students.cs.mu.OZ.AU (Fergus Henderson) (2002-11-26)
[15 later articles]
| List of all articles for this month |

From: "Quinn Tyler Jackson" <qjackson@shaw.ca>
Newsgroups: comp.compilers
Date: 17 Nov 2002 23:17:12 -0500
Organization: Compilers Central
Keywords: design, C
Posted-Date: 17 Nov 2002 23:17:11 EST
In-reply-to: 02-11-087

> > Why the C lang behaves like that:
> > We need to delare variable in advance, in contrast to other
> > lang, the program simply use without declaring it.
> >
>
> suppose this code:
>
> void updateAccount(newAmount)
> {
> CurrentAmount = ReadCurrentAccount(database);
> CurrentAmunt =CurentAmount+newAmount;
> StoreDatabase(CurrentAmount);
> }
>
> You see the problem?
>
> A typo in the spelling of the variable "CurrentAmunt" in line 2
> creates a new variable "CurrentAmunt" that receives the
> result of the
> addition.


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?


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.


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. No amount of technology can do this:


int CurrentAmount1 = 0; /* current amount in the calculation of the
first account balance */
int CurrentAmount2 = 0; /* current amount in the calculation of the
second account balance */
int CurrentAmount3 = 0; /* current combined amount of accounts 1 and 2
*/
--
Quinn Tyler Jackson
http://members.shaw.ca/qjackson/


Post a followup to this message

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