#C problems
12-Mar-91 19:33:52
Sb: #8241-#C problems
Fm: Robert Hayes 70431,1737
To: Greg Comeau@Comeau Cmptg 72331,3421
Vacation already over, some vacation. Well, as far as this input and
output stuff is concerned, bear in mind that an "input" is really an
"output", and vice versa. You are only guided by common sense, e.g. you
wouldn't want to open the printer and try to get "input" from it. The
input and output names attached to streams are purely to assist in the art
of programming them, IMHO. As I said before, if everybody programmed in
_assembly_ you wouldn't have these problems. You'd have better, *bigger*
problems (think of the challenge). It does not surprise me that most
compilers might handle things different. The reason Manx 3.6a seems to lack
setvbuf compared to Manx 5.0d is due to the ANSI compliance of Manx Aztec
C. K&R left C vague in places, to allow for flexibility ( I *hope* ), and
now some committee wants to standardize to Cobol or Pascal type
restrictions. Then you wouldn't be able to get away with a statement like
char is a type of int, in reality. IMHO, C grew so fast, comparatively
speaking, due to the enormous flexibility (and hence responsibilities) of
the syntax; and now some committee is going to kill this flexibility for
programmers that can only live in a nonflexible environment where exacting
rules have to be followed. I will suffer with it as long as I can, and
then revert back to pure assembly programming since the only reason I took
up C several years ago was because other technical friends insisted it
wasn't the same old syntax restructured/relabeled. I actually have
assembly printouts several years old that I can still follow (due to
comments and structure). I just *hope* the committee doesn't butcher C,
but sometimes these guys are worse than congress. BTW, that is not to say
they haven't done _some_ excellent work, I just don't remember any.
8) 8) 8)
Robert (back and mean as ever)