Re: simple read char app return wrong value?
- From: naunetr <wildgoosechase@xxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 07 Dec 2007 19:53:57 +0530
Frank Kotler wrote:
naunetr wrote:
...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?
I guess you're right. It probably should... but it doesn't...
...okay. i thought that would happen only within a process, not across them also.
Now that you mention it, that *is* surprising.
but after reading the docs it is designed purposely. the man pages say that the child process normally inherits all the open file descriptors of the parent process after a fork and execv.
so bash can read input meant for us, but we could also read input meant for bash i suppose...
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.
I don't have much experience with C. There's open(), read(), write() - which I think is the same code as we'd get with the int 80h interface.
i think they are posix functions and found in libc. linux kernel also wants posic compliance so it also implements the same methods. where linux implements them, the posix functions in libc just immidiately call the linux syscalls. but some like sbrk are only in libc. very irritating that sbrk is not done in kernel. it is useful when doing dyn memory allocations. have to again link into libc for just one function.
Then there's fopen(), fread(), fwrite() which use a "*FILE" - these ones do internal buffering, and definitely do some flushing. For example, if we use printf to say "hit enter to continue" - *without* a newline - and then wait for "enter"... we don't see the prompt until *after* the program exits. A newline in the format string will flush the buffer and cause it to print right away.
yes. already got told about this in comp.lang.c :)
Another way we can see what the C library is doing for us... The way we're doing d2u and u3d - reading one character at a time - is slow as hell. A C program that reads a file one character at a time with fgetc() is much faster, because of this internal buffering. We can provide buffering, too, of course.
i guess so, but its beyond me now. :) i havent timed the readc app with a equivalence using fread and another using read. should do that sometime...
I'll have to try an experiment, comparing read() and fread(). I wouldn't be surprised to see read() show this same behavior, and fread() not. I'm not sure.
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.
Thanks for the info on that, Chuck! RTFM is a good idea... but there's so *much* of it! :)
yes. all the docs make the head swim. :) sometimes wonder if sofware is not creating more problems than solving...
...mov bl, [the_char]
wont some leftover value in rest of ebx corrupt the return code?
Good point! Could have used "movzx ebx, byte [buf]". I'm not worried about it for two reasons: One, I think only bl - the low byte of ebx - is "valid". "echo $?" only displays the low byte (mov ebx, 0FFFFFF00 and exit just displays 0).
okay, didnt know about that.
Also, we got here from reading stdin, so ebx should be zero anyway (this sort of assumption results in unmaintainable code!)
good spot! i didnt notice that.
...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?
I'm not sure what to make of this. There's some "translation" going on when we read a key (we gan get several degrees of "raw" input by teaking stdin with sys_ioctl). I assume that's what we're seeing - ctrl-d showing up as zero, ctrl-j and ctrl-m both showing 10, etc.
yes i think you are right. it is the difference betwen "cooked" and "raw" mode. but right now i dont think i know enough to mess with termios and stuff.
anyway thanks for that example Frank. slowly im progressing... :)
Your questions indicate that you're progressing at a pretty good rate, I'd say!
Best,
Frank
actaully i tend to do things in bursts. so i may be heading into a trough. lets hope not :)
thanks again!
.
- References:
- simple read char app return wrong value?
- From: naunetr
- Re: simple read char app return wrong value?
- From: Frank Kotler
- Re: 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: assembly language and reverse engineering
- Next by Date: Re: which book to start with...?
- 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
|
|
