Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tekcrl!tekgvs!toma
From: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.sys.ibm.pc
Subject: Re: scanf problem in TC v2.01
Message-ID: <6924@tekgvs.LABS.TEK.COM>
Date: 22 Feb 90 17:19:46 GMT
References: <90022202515808@masnet.uucp>
Reply-To: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 36

Well, there is a :-)/2, but I'll respond anyway.

In article <90022202515808@masnet.uucp> mark.freedman@canremote.uucp (MARK FREEDMAN) writes:
>tM>From: toma@tekgvs.LABS.TEK.COM (Tom Almy)
>tM>The "problem" is that C, in its infinite stupidity about data types,
>tM>assumes that all functions return ints, unless you declare otherwise.
>    Gosh, could you tell me which language you use which is capable of
>correctly guessing what you want it to do ???

In this case, any language with tagged data, for instance LISP, Smalltalk, APL.
Data types are checked at runtime.

>    It's pretty pathetic when a programmer has to explicitly tell the
>machine how to get the desired results.
>   :-)/2

Maybe so, but if you have to explicitly tell what you want there is less
chance for misunderstandings!  Languages where this problem would not
occur because of requirements for explicit declaration include Pascal, Modula-2,
and C++ (to a limited extent). Other languages which have this problem 
include Assembler and Fortran.

(I bet this is the first posting here which puts C in the same class as 
Fortran!)

A more intelligent linker could also solve the problem by matching function
prototypes (what the application assumes the function passes) with the
actual function definitions.

>    (3 zillion MIPS, and it STILL can't read my mind)

Maybe it's time to put those mips to work doing error checking!

Tom Almy
toma@tekgvs.labs.tek.com
Standard Disclaimers Apply