Re: HLALib
- From: "vid512@xxxxxxxxx" <vid512@xxxxxxxxx>
- Date: 1 Dec 2006 05:40:12 -0800
are you considering case with line longer than that? or is it leftActually, one improvement that will happen sometime in the HLA v2.x
undefined?
stdlib series will be true dynamically allocated strings that
automatically resize as needed. When such a facility is available,
there is no reason the stdin.gets wouldn't allow an arbitrary size.
i thought you already have them :?
i am going to implement these too, but i will keep supporting classical
string buffers, and also "static dynamic strings", eg. static string
buffers, but with maximal buffer size and actual string length
prepended.
Nevertheless, limitations like this are exactly the kind of thing I'mallright
addressing in the current v2.0 rewrite.
here is how i do it in FASMLIB. Win32:you should define it BEFORE doing ports.I have to see what the OSes offer, before I can make such a design
decision.
;call ReadFile
;function returns after reading one line, which can be less than size
we want
push 0 ;reserved
lea eax,[readen]
push eax ;pointer to variable to hold number of chars readen
push ebx ;number of bytes to read
push edi ;pointer to buffer
push edx ;stdout handle
call [ReadFile]
or eax,eax
jz .error_ReadFile
;if return value is non-zero, and bytes readen is zero, then we are on
eof
cmp [readen], 0
je .done
Linux:
;call sys_read()
;function returns after reading one line, which can be less than size
we want
push ebx
mov edx, [count]
mov ecx, edi
mov ebx, 0 ;stdin
mov eax, 3 ;sys_read
int 80h
pop ebx
;check sys_read() error
cmp eax, -4096
ja .error_read
;eof if 0 bytes were readen
cmp eax, 0
je .done
I understand. And it is good behavior. But first of all,i needed someIf it reads lesser, it returns OF set. This gets funny withYes, this is typical stdin behavior. stdin.read in the stdlib does the
reading from console, which always returns one line, even if it is less
than you requested.
same thing.
solid interface. To read one line from input, i provide neat functions.
Altough their performace will suffer from abstraction, but on other
side, they can be used on any stream then.
Really, just matter of design. Caller of library probably won't see
much difference.
The problem with that approach is that while it works great for file
input redirected to the standard input, you run into problems with
interactive input. The reason stdin is typically buffered is to allow
the user to do intra-line editing and other nice things (like command
history) provided by the user interface. This can be accomplished by
the OS if you read whole lines at a time, it must be handled by the
application (ugh!) if you do character at a time I/O (i.e.,
non-buffered I/O).
and:
these two doesn't contradict. The stream reading routine reads entiresorry, in your case it's right. In FASMLIB i use same routines to readAgain, the editing issue.
from any type of stream, so they never should access more than needed.
line, stores it in buffer, and text parsing routine never reads more
than it needs from buffer.
This way, the text parsing routine can work on any type of stream.
.
- Follow-Ups:
- Re: HLALib
- From: randyhyde@xxxxxxxxxxxxx
- Re: HLALib
- References:
- HLALib
- From: vid512@xxxxxxxxx
- Re: HLALib
- From: rhyde
- HLALib
- Prev by Date: Re: ml.exe
- Next by Date: Re: ml.exe
- Previous by thread: Re: HLALib
- Next by thread: Re: HLALib
- Index(es):
Relevant Pages
|