Where should the type information be 136
Where should the type information be 138
It wasn't that simple. The problem was that the status quo was badly places. In particular, many of the "PC" compilers (by which...
*THAT* is nonsense. Why do you think the C RTL requirements need to be imposed upon unrelated software?
That's a different issue. Supporting the C language on a platform is a much smaller issue than supporting the C environment model throughout a platform.
It is also a red herring.
target for a standard command from that platform. And in most cases won't even make sense.
Where should the type information be 137
Trevor, This is a public policy issue not yet wrung out in court or the legislature. Presently, the EULAs all contain...
operator precedence was: Where should the type information be Keywords
on changing the operator precedence in C The more cautious approach would be to first deprecate the old syntax; then make it non-standard, i.e., the standard syntax would be (a...
But any data set that conforms to the platform environment model would be a reasonable target for your C programs A and B because the requirement to support lines up to 254 characters in length (the number is 510 now I think) does not impose a requirement to use lines over 80 characters is length.
So any data set on the platform that is already in compliance with the 80-character limit can be processed by C programs on that platform. the only technical issue is making the simple case of 80-character lines available without extraneous formatting. I.e., the C RTL has to consider the platform file format as a degenerate case of the more general C file format.
That's if you want seamless integration of the C and platform environment models. That integration is not necessary to support C programs. Useful yes. Necessary no.
I understand tapes (wrote a 9-track driver once). And I stand by my comments. Are you suggesting that it is impossible to commit to tapes? Or that it is impossible to use scratch disk to buffer written but uncommitted data?
Note that tapes often have useful features that disks don't. Read reverse can be particularly useful, but it requires a sophisticated application to make use of it. Trying to write such a program using the C environment model would be a study in frustration. Better to write tape mmgt library (c.f., tprintf(), tscanf(), teof(), etc.) in C and then use it to write applications in C or any other language.