Better explain that the loop waits for a keyboard input
despite there is no input.

And how do you propose to distinguish "slow input" from "no input"?
Where exactly there should be EOF in a *stream*?

Tx for asking me !

In case of the keyboard input, the state is well defined from the bios aka. the "waiting char status" of which all comp's have a (basic) BIOS to report tat.

In case of a file (stream) it is possible to detect an EOF - (WITHOUT having to read first) by using ftell()/fseek(). Ayway it may impose some overhead. Nevertheless the code below will allways report EOF without reading (ex. is with a zero len file). Try it urself ! 


$handle = fopen('test', 'w'); // create a zero length file
fclose($handle);

$handle = fopen('test', 'r'); // re-open
do {
  // start - EOF routine 
  $curpos = ftell($handle);
  fseek($handle, 0, SEEK_END);
  $endpos = ftell($handle);
  // test wether the current pos is the last pos (=eof)
  if ($endpos == $curpos) { echo " ..EOF"; break; }
  fseek($handle, $curpos); // not EOF - return to last file pos 
  // end - EOF routine 

  echo "\r\nRead at " . $curpos;
  $buffer = fgets($handle, 9);
  }
while(true);
echo " ..END";
fclose($handle);

I'm not talking about a file, no.
I'm talking about stdin stream.
Feel free to cook a patch and post it for use to review.

This is what has been valid BIOS INT on the x86 family IBM compatible
since it came in early 80' !

---------------------------
TEST FOR KEY (SINGLE CHAR)
---------------------------
return: ax=0=no char waiting or ax=1=yes
 
keyb_newchar_check proc far

    mov  ax,1
    int  16h   ; func=1
    xor  ax,ax
    jz   nochar
    inc  ax
nochar:
    ret
keyb_newchar_check endp

-----------------------------
GET WAITING KEY (SINGLE CHAR)
-----------------------------
return: ax (AL) = char (if func key like F1 then its scan code)
note: if no waiting key - then the bios will wait for one

keyb_newchar_get proc far

    xor  ax,ax
    int  16h    ; func=0
    or   al,al
    jnz  noscan
    mov  al,ah  ; scan code in ah
noscan:
    xor  ah,ah
    ret
keyb_newchar_get endp


SOURCE ========================================

Public Domain/Freeware/Shareware by Ralf Brown: INTER60.ZIP X86 family DOS/BIOS int's


--------B-1600-------------------------------
INT 16 - KEYBOARD - GET KEYSTROKE
	AH = 00h
Return: AH = BIOS scan code
	AL = ASCII character
Notes:	on extended keyboards, this function discards any extended keystrokes,
	  returning only when a non-extended keystroke is available
	the BIOS scan code is usually, but not always, the same as the hardware
	  scan code processed by INT 09.  It is the same for ASCII keystrokes
	  and most unshifted special keys (F-keys, arrow keys, etc.), but
	  differs for shifted special keys
	some (older) clone BIOSes do not discard extended keystrokes and manage
	  function AH=00h and AH=10h the same
	the K3PLUS v6.00+ INT 16 BIOS replacement doesn't discard extended
	  keystrokes (same as with functions 10h and 20h), but will always
	  translate prefix E0h to 00h. This allows old programs to use extended
	  keystrokes and should not cause compatibility problems
SeeAlso: AH=01h,AH=05h,AH=10h,AH=20h,AX=AF4Dh"K3PLUS",INT 18/AH=00h
SeeAlso: INT 09,INT 15/AH=4Fh
--------B-1601-------------------------------
INT 16 - KEYBOARD - CHECK FOR KEYSTROKE
	AH = 01h
Return: ZF set if no keystroke available
	ZF clear if keystroke available
	    AH = BIOS scan code
	    AL = ASCII character
Note:	if a keystroke is present, it is not removed from the keyboard buffer;
	  however, any extended keystrokes which are not compatible with 83/84-
	  key keyboards are removed by IBM and most fully-compatible BIOSes in
	  the process of checking whether a non-extended keystroke is available
	some (older) clone BIOSes do not discard extended keystrokes and manage
	  function AH=00h and AH=10h the same
	the K3PLUS v6.00+ INT 16 BIOS replacement doesn't discard extended
	  keystrokes (same as with functions 10h and 20h), but will always
	  translate prefix E0h to 00h. This allows old programs to use extended
	  keystrokes and should not cause compatibility problems
SeeAlso: AH=00h,AH=11h,AH=21h,INT 18/AH=01h,INT 09,INT 15/AH=4Fh

hotddam - error
can't destroy the zero flag with "xor ax,ax" must use "mov ax,0" - sry

keyb_newchar_check proc far

    mov  ax,1
    int  16h   ; func=1
    mov  ax,0
    jz   nochar
    inc  ax
nochar:
    ret
keyb_newchar_check endp