Re: HLALib



are you considering case with line longer than that? or is it left
undefined?
Actually, one improvement that will happen sometime in the HLA v2.x
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'm
addressing in the current v2.0 rewrite.
allright

you should define it BEFORE doing ports.
I have to see what the OSes offer, before I can make such a design
decision.
here is how i do it in FASMLIB. Win32:
;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

If it reads lesser, it returns OF set. This gets funny with
reading from console, which always returns one line, even if it is less
than you requested.
Yes, this is typical stdin behavior. stdin.read in the stdlib does the
same thing.
I understand. And it is good behavior. But first of all,i needed some
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:

sorry, in your case it's right. In FASMLIB i use same routines to read
from any type of stream, so they never should access more than needed.
Again, the editing issue.
these two doesn't contradict. The stream reading routine reads entire
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.

.



Relevant Pages

  • Re: HTTP Object and Retrieving HTML Programatically
    ... I had to hardcode some query string and form post values, ... chunks defined by the buffer size ... //create a stream reader grabbing text we get over HTTP ... while (workingbuffersize> 0) ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Discovering variable types...
    ... >- but I suppose MS expect us to use wrappers ... memory allocations for your variables from disk as well. ... >They most certainly are of fixed size, changing the size of a String ... >>me to keep buffer size and current postion right in the memory block. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Secure C library
    ... I read much of the new "security TR", and gee, I don't know. ... the buffer from the buffer size. ... It is not hard to design a better form of buffer and string handling. ... but this is just one example of how thoughtful interface design can ...
    (comp.std.c)
  • Re: Secure C library
    ... >> string functions don't make much sense once you add bounds-checking ... >> designing an interface just for the purpose of reducing the frequency ... > make buffer size decisions more visible, ... Bstrlib is also very interoperable with char *'s, ...
    (comp.std.c)
  • Re: Problems reading network stream
    ... if the entire buffer wasn't filled (which was often the case ... for the last read of the stream) then it ended with CrLf.CrLf followed by ... Alex Clark ... appending it to a string. ...
    (microsoft.public.dotnet.languages.vb)