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. |