Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!pilchuck!dataio!fnx!nazgul!bright
From: bright@nazgul.UUCP (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: TC++: "floating point formats not linked"
Message-ID: <285@nazgul.UUCP>
Date: 22 Mar 91 10:47:11 GMT
References: <1991Feb9.193059.14322@ucselx.sdsu.edu> <279@nazgul.UUCP> <15406@smoke.brl.mil>
Reply-To: bright@nazgul.UUCP (Walter Bright)
Organization: Zortech, Seattle
Lines: 41

In article <15406@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>In article <279@nazgul.UUCP>, bright@nazgul.UUCP (Walter Bright) writes:
>- In article <15316@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>- /You could of course also have the compiler pay special attention to the
>- /format strings for *scanf() and *printf(), although that is not foolproof.
>- I think this would be a bug in the compiler for these reasons:
>- 1. The format strings may not be available to the compiler, as they
>-    may be built dynamically or be in another module.
>- 2. The library is supposed to be independent of the compiler. Having the
>-    compiler recognize these things could make it very problematical if
>-    somebody rolled their own printf/scanf.
>
>1. When string literals WERE used, the compiler would be free to use
>that fact.

True. My only concern about this is a complexity issue, the more complicated
the rules are, the more confusing it is to understand why one piece of source
works and the other doesn't. I prefer simple rules that work 95% of the time
to complex rules that work 97% of the time... :-)

>2. A conforming hosted implementation includes library and language
>together; a strictly conforming program is NOT allowed to provide its
>own replacement for any of the standard library functions.

Also very true. But it is also true that we have a lot of customers who
are not particularly interested in writing strictly conforming programs.
You should see the number of requests we get for supporting // comments
in the C compiler! People know it's not standard C, but they want to use
it. (It will be in the next version!)
One of the great strengths of C is its ability to be bent to the
customer's needs.

I had a very bad experience with Pascal (many years ago, before I discovered
C). It seems most of my time spent debugging was trying to figure out how
to get the Pascal built-in I/O to do what I needed. It was always too clever,
doing things like converting all non-graphic characters into spaces before
output! So much for trying to write to an ANSI terminal control sequences.
Tabs were always converted to spaces... It wasn't a 'smart' system, it was
a 'smart-ass' system. When I found C, and the I/O was independent of the
compiler, I was sold. This experience causes me to view with a lot of
distrust any attempts at building I/O into the compiler.