Re: simple read char app return wrong value?
- From: naunetr <wildgoosechase@xxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 06 Dec 2007 17:46:50 +0530
Frank Kotler wrote:
naunetr wrote:
[snip code]is everything correct here?
Yeah... but maybe sys_read doesn't work quite as we'd prefer.
but when i run this everything is okay when i enter single character
Right... and "enter"...
or i press crtl-d for end of file,
??? Okay, I don't know about that one. "EOT" in ascii. In my modified program, ctrl-j or ctrl-m bails out, for me. crtl-d doesn't seem to do anything special - indicates "the char" is zero (???)
well the c people told me that ctrl-d signals end of file under unix systems and cause getc and getchar to return EOF. and ctrl-z is the windows equivalence. on my system ctrl-m seems to be same as enter key.
but when i enter several characters after my app exits bash somehow reads them and complains. here is some examples.
Annoying, but normal.
shouldn't it be considered "risky" to give one apps input to another app? shouldnt kernel remove all the pending input for readc before handing bash control?
...bash: kjalskj: command not found
#
what is happened here?
Extra characters the user types stay in the system's input buffer.
okay. i thought that would happen only within a process, not across them also.
how can avoid input to readc from being read by bash?
We'll have to flush the buffer!
this isnt needed in c programs. i guess the standerd library does this flushing before exiting.
also the exit code for example 1 is 1 and for example 2 is 0 but for example 3 it is 127. does anyone know what 127 means? 1 and 0 seem to be correct as said in man 2 read.
Well, I think 127 is what bash is returning after complaining, no longer the return code from your program. Damned if I know what it means! I would expect an "error" indication - a "negative" number, which "echo $?" should display as >128 (since it doesn't do "signed") I can confirm that it *does* return 127, but I don't know why.
also Duntemann's book mentions setting up "stack frame". is that only for c library or do i have to do that for above program also?
No, you don't need to do it here. PGU gets into it in the section about "functions". Too much to get into here...
So how do we flush the system's buffer? We know that sys_read doesn't return until the user hits "enter" (We would prefer, perhaps, that it did. This can be arranged. "sys_ioctl" can be used to modify the behavior of the "file"... but it isn't "simple". Another post.), so we can watch for that. In spite of only wanting one key, I've modified your program to read *two*. If the second one is the "enter" (10, although we might expect it to be 13), we're all set - the user entered just one key. If the second character *isn't* the "enter" key, we want to gobble up any excess. If the user hit *just* enter, it won't be in the second position, so we have to check for that, too. If we need to "flush" some, we read into a different buffer (so we don't overwrite the "good" buffer), one at a time, until we find the "enter" key. We ignore the "dummy" buffer, and the second byte of the "good" buffer - we're only interested in the one key. Rather than return the number of bytes read (which would include the "enter" if we read enough to include it), I've modified the program to return (as an exit code) the (first) character entered. We'll want to make this a subroutine, probably, and return the character in al, but "from the Ground Up", "Step by Step"... This attempts to solve just the one immediate problem.
Best,
Frank
; readc.asm - read a character from standard input and exit.
section .text
global _start
_start:
mov ebx, 0h ; standard input
mov ecx, the_char ; input array
mov edx, 02h ; 1 character to read (+ "enter")
mov eax, 03h ; system call number for read
int 080h
; user just hit "enter"?
cmp eax, 1
je done ; begone
; if user obediently hit just one key,
; and "enter", we're done
cmp byte [the_char + 1], 10
je done
; pesky user entered more than one key
; get rid of excess
mov ecx, dummy ; buffer
mov edx, 1 ; one at a time
flush:
mov eax, 3 ; __NR_read - as C calls it
int 80h
; finally got our "enter"?
cmp byte [dummy], 10
jne flush ; no, do more.
; yes, "fall through" to...
done:
; mov ebx, eax ; byte read
; rather than return number of bytes read, return the char
mov bl, [the_char]
wont some leftover value in rest of ebx corrupt the return code?
mov eax, 01h ; system call number for exit
int 080h
section .bss
the_char resb 02h ; array for input
dummy resb 1 ; extra buffer
okay when i run this program and press ctrl-d and then enter it return a value of 0. wikipedia says that ctrl-d is end of transmission and has a decimal value of 4 and it also used as end of file in unix. so why doesnt the app return 4 instead of 0?
anyway thanks for that example Frank. slowly im progressing... :)
.
- Follow-Ups:
- Re: simple read char app return wrong value?
- From: Frank Kotler
- Re: simple read char app return wrong value?
- References:
- simple read char app return wrong value?
- From: naunetr
- Re: simple read char app return wrong value?
- From: Frank Kotler
- simple read char app return wrong value?
- Prev by Date: Re: which book to start with...?
- Next by Date: Re: simple read char app return wrong value?
- Previous by thread: Re: simple read char app return wrong value?
- Next by thread: Re: simple read char app return wrong value?
- Index(es):
Relevant Pages
|
