Re: [Hla-stdlib-talk] non-buffered 'stdin.getc' function
Brought to you by:
evenbit
|
From: Nathan B. <eve...@ya...> - 2008-02-16 18:38:18
|
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. |