[comp.sys.ibm.pc] Re^2: Trouble compiling flip with TurboC 1.5

leonard@bucket.UUCP (Leonard Erickson) (07/27/89)

ked@garnet.berkeley.edu (Earl H. Kinmonth) writes:

>While I'm on the soapbox, let me note that before I bought TC, I bought
>a number of magazines and read a number of reviews of it.  NOT ONE REVIEW
>noted any of the BRAIN-DEAD FEATURES of TC 1.0/1.5 (I can say they were
>brain-dead with certainity because they were eliminated in TC 2.0), most
>of which were stupid, arbitrary deviations from **IX norms.

Sorry to burst your bubble, but in the MS-DOS world, **IX compatibility
is not going to be a review criterion. Very few of the magazines that
review MS-DOS software are likely to even be aware of these **IX "norms".

Compiler reviews generally assume that you are going to be *writing*
code, not *porting* it. 

BTW, I'm not a much of a C programmer, so I'm curious, how well does
ANSI C conform to these "norms"?
-- 
Leonard Erickson		...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I'm all in favor of keeping dangerous weapons out of the hands of fools.
Let's start with typewriters." -- Solomon Short

caromero@phoenix.Princeton.EDU (C. Antonio Romero) (07/28/89)

In article <1583@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes:
>ked@garnet.berkeley.edu (Earl H. Kinmonth) writes:

>>While I'm on the soapbox, let me note that before I bought TC, I bought
>>a number of magazines and read a number of reviews of it.  NOT ONE REVIEW
>>noted any of the BRAIN-DEAD FEATURES of TC 1.0/1.5 (I can say they were
>>brain-dead with certainity because they were eliminated in TC 2.0), most
>>of which were stupid, arbitrary deviations from **IX norms.

As a general rule, most reviews, especially early reviews, of software
should be taken with enormous quantities of salt.  (Not to defend
Borland's early bugs or arbitrary changes...)

>Sorry to burst your bubble, but in the MS-DOS world, **IX compatibility
>is not going to be a review criterion. Very few of the magazines that
>review MS-DOS software are likely to even be aware of these **IX "norms".
>Compiler reviews generally assume that you are going to be *writing*
>code, not *porting* it. 

Given that the largest arguement in favor of coding in C (apart from
efficiency) is portability across platforms, especially including Unix,
I think that this _is_ an issue.  If MS-DOS was looked at as a ghetto
of sorts, where little or no code travelled in or out, this attitude
might be reasonable; but with more different kinds of machines
interacting more closely every day (the recent new-line controversy
arose because a Sun was providing file service for PC's) both small
deviations from de facto standards like the Unix library and failures
to be flexible about things like end-of-line conventions in source code
(as I recall a programmer with Turbo 1.5, at least, could with a bit of
cleverness get the end-of-line, for example, to behave any way they
wanted) are inexcusable.

At any rate, the complaint was not about how Turbo's file I/O
works, but rather that the compiler itself can't compile a file with
line-feeds between lines.

>BTW, I'm not a much of a C programmer, so I'm curious, how well does
>ANSI C conform to these "norms"?

Well, given that ANSI C is an attempt to move from the de facto norms
established by the Unix community, and more or less closely followed by
those outside of it, to an official, formal standard... there's no
reason why it _should_ follow the old norms.  It won't change things
arbitrarily, though; and any compiler claiming ANSI compatibility should
be capable of handling the same files.

Has the ANSI considered including something in the standard
about end-of-line conventions?  If not, someone who knows how to get
input to them (if it's not too late) might pass it on...

-Antonio Romero    romero@confidence.princeton.edu