printf, data presentation

[mcdonald at uxe.cso.uiuc.edu]

>In article <225800106 at uxe.cso.uiuc.edu> mcdonald at uxe.cso.uiuc.edu writes:
>[about inkey()]
>>The important point is that some such function should be a
>>STANDARD C (ANSI C) function, not an operating system dependent
>>kludge. It is obviously too late to get it done right this time
>>around, but next time .... PLEASE!

>It's kind of hard to make in OS independent when there are some operating
>systems that just *cannot* do the type of thing you want, or have so much
>overhead in doing it that it's not worth it.  For example, NOS on a CDC
>Cyber 170-state machine:  to do I/O, you normally tell a peripheral
>processor, which swaps you out of main memory until it has a line of TTY
>input, at which point it rolls you back into memory, with the line
>automagically put into your buffer.  To do what inkey$ in BASIC does, you
>would need single-character I/O, which "normal" users cannot get in NOS.

>And, yes, there are at least 2 C compilers for NOS, so it is an issue.

Things like NOS are why I WANT it IN THE STANDARD!!! If you only get
a line at a time YOU CAN'T, ABSOLUTELY CAN'T write decent software.
The impossibility of writing a decent editor is one reason we no
longer use CDC computers here. Why can't "normal" users on NOS do
what I would call "normal" io? If I were looking for a computer today,
I would not even CONSIDER one that can't do that. If a manufacturer
wants to make a computer that has severe IO problems like that, he
should have a multiprocessor system where directly connected users
CAN do it, offloading only the more compute bound parts of a task
on the more remote sections of hardware.

If your OS can't do single character IO ---- FIX IT!

Doug McDonald