🚀 go-pugleaf

Jens Andreasen <jens-and@dsv.su.se> writes:

>So I thought It was easy and it was until I wanted my
>(supposedly) highly portable code to show_a_message(),
>and_halt_until_the_user_presses_a_key()

>Well, getchar() seems to be a bit on the implementation defined side
>and gets() can be considered playing russian roulette :-|

How about using fgets instead of gets? Of course for waiting for a
keypress both aren't the right thing as they both wait (at least) for a
whole line.

>And having to use implementation defined substitutes is like throwing
>std.c out the window.

If you want to do things which the standard doesn't address there is no
way around it. But you can isolate these things easily so that you only
have to change one routine when you port it instead of 100 places where
you want to wait for a keypress.

>Is there any convention for how many chars gets will actually read, or
>will it just keep on reading until the hardware ends

The latter.

>Seriously, why not make such a convention or standard? I'd suggest 256
>chars to be sufficient for my needs, others may prefer 1k or maybe
>16k...

>So IMHO a solution could be to introduce a systemvariable: MAX_GETS

With this name it should be a constant (Actually it should be GETS_MAX
to be consistent with other similar constants). But I think it is a
bad idea to introduce such a constant: It won't help old code and it
will encourage people to use gets for new code. IMHO we should get rid
of gets as soon as possible. And we should standardize a function for
reading lines of arbitrary length, like BSD 4.4 fgetln so that we can
get rid of fgets in the long run, too.

>On second thought, maybe that should just be a constant? ......
>
>Or do anybody know of a workaround using getchar that won't hang this
>or that odd system because of chars left in the buffer? (Remember, the
>cat *could* be part of the system).

I'm not even sure what you want to do if the cat lies on the keyboard.
If you want to wait until it stands up again you probably have to
wait until no key has been pressed for a second or so to get around
autorepeating keys. You would need nonblocking I/O for that.

Even if there is no cat, there is no 100% watertight scheme. The best I
can come up with is to ask the user to hit return and then read up to
the first '\n' that comes along. But on a screen-oriented terminal the
return key probably has only local meaning and the send key sends you
the contents of the whole screen (so you may have to swallow a number of
lines depending on the type of the terminal).

	hp
--
   _  | Peter Holzer | Systemadministrator WSR | hjp@wsr.ac.at
|_|_) |-------------------------------------------------------
| |   |  ...and it's finished!  It only has to be written.
__/   |         -- Karl Lehenbauer