I think this is an impossible assignment...could you help?

[David Thompson]

Say what? If you're reading from the standard input stream, you won't
get *any* input until the user presses "Enter", will you?

No, both pedantically and seriously.

First, C's standard input need not be a keyboard and often isn't.

Second, keyboards (and keyboard processing) are not all the same.
If there is a key that generates input-end-of-line it isn't always
labelled Enter, and there may be (other) key combinations or sequences
that generate it also (or even instead).

Skipping over those to the serious question, can a C program receive
input from a keyboard before the user enters an end-of-line character?
Still yes.

The standard requires that stdin (and others) be not fully buffered
if the stream '[cannot] be determined not to refer to an interactive
device' and 'What constitutes an interactive device is
implementation-defined.' Even assuming the implementation can
correctly identify keyboard input as interactive -- which is not
always possible -- this does not specify whether it is then line
buffered or unbuffered. Unbuffered is 'intended' to receive (or
transmit) 'as soon as possible', which again can depend on the
implementation, but certainly can be without any end-of-line.

And there are real cases where this happens. In addition to special
modes on many systems, on Unix systems using a standard tty driver in
normal 'cooked' mode, the 'end of file' character, usually defaulted
to control-D, only does that function at the beginning of a line.
Partway into a line it causes the _partial_ line to be read.

What you can say is that for *most* users of *most* systems *most* of
the time, the program gets keyboard input only when the user presses
an end-of-line key. This happens often enough that it is frequently
useful to code programs to assume and process line-at-a-time input.
In particular in C you can force line-oriented input, portably and
even for 'non-interactive devices' like files, with fgets() (or
<horrible>gets()</>) and then process it accordingly.

 

[Bartc]

Which comes back to the real problem, which is how you signal errors
when all possible return values could be legit.

There are ways. For example, reserve one legit value for an 'escape' code.

If such a code is returned, it means the function should be interrogated
once more. If it returns the same code (or some other agreed value), then
the function wants to return the escape number as data. Otherwise it's an
error code (and this allows any number of error codes).

(The function does need to remember some state, and this method depends on
being able to do two successive, uninterrupted calls, and it depends on the
caller remembering to do so!)