Re: [Hla-stdlib-talk] non-buffered 'stdin.getc' function

[Nathan B. <eve...@ya...>]

Frank Kotler <fbk...@ve...> wrote: Nathan Baker wrote:

...
>      > w.ReadFile( hStdIn, &InputBuffer, 1, InputIndex, 0 );
> 
>     Who "InputIndex"? I'm thinking we want an address here (? remember I
>     don't do Windows). Perhaps that's what you've got...
> 
> I cribbed InputBuffer and InputIndex from the original getc() -- again, 
> I am guessing they are defined in "../include/stdinunit.hhf" -- probably 
> need to call stdin.read() { the original calls readln() but that won't 
> work here }.

Could that be a problem? Or an opportunity?
Well, I don't see a "si_read.hla" in SF's SVN Browse, so it looks like an opportunity to write one.  :)
...
>     "Leaking handles" is a pretty bad problem. Other than that, it looks
>     good to me!
> 
> I don't think so.  To my understanding, the 'standard I/O' handles are 
> created (by the OS) for each process when it starts, and are closed 
> automatically when it terminates.  The 'GetStdHandle' doesn't actually 
> create a new handle... it just asks the OS for the handle that was 
> already created when the process started.  I think closing it 
> prematurely might be a bad thing.  I'll check the book to make sure.

Yeah... or see what GetStdHandle(-10) returns on repeated calls.
"sitting in front of the laboritory"  :)

It always gives me the number 8 on Win98 and I get a 3 under WinXP.  Even opened multiple consoles and get the same number.

Anyway, I've looked a the included file and see that Randy has provided a macro to grab the handle if it hasn't already been gotten.
>     What I've got for Linux does a similar thing... we "get" a whole
>     bleedin' structure for "current mode" - but only clear two bits, and
>     "set" to that. It is not strictly "right". If the pesky user suspends
>     the program with control-z, and restarts it with "fg", we're back
>     reading one key... but waiting for "Enter" again! :( A similar problem
>     may occur if the window size is changed (in an Xterm). We could fix
>     that
>     by blocking control-c/control-z entirely - handling it ourselves,
>     perhaps. Or we can "catch" these signals and do the appropriate
>     cleanup/restoration of our "tweak". (I'm not sure how to do that one).
> 
> Could you post the code?  Or is it already at Linux-nasm-users?

Might be... in the form of "Beth's Game". Here's a "simplified" version 
- as-is, needs-work! And a C program (since you like C compilers these 
days) which does something a little more - kills more "processing" and 
checks for control-c. The way he does "check-for-key" doesn't impress 
me. Rather than make the handle non-blocking, we can use sys__newselect 
for that. There are several interesting points: size of termios is not 
what I'm using (!), different tweak for Ubuntu (!), and the different 
bits in termios that he tweaks and I leave alone...
Okay, thanks for these.  I'm starting to wonder if it would be best to allow a parameter to select the exact behaivour for this 'getc' function?  Like, choosing to ignore control-c, for instance.  The HLA programmer might appreciate the extra amount of control being exposed.

Nathan.


       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.