CompuServe Messages

#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)