HLA StdLib2 criticism

allright, you finally released something, so i am gonna point out few
problems i spot


--------- in lowmost (os-dependant level)

1. stdin.read in case of linux:
bad checking for error. linux syscalls doesn't return -1 in case of
error. they return any value in range -4096 < eax < 0. This error is
pretty common in many places in your code. i consider it critical bug,
because you completely fail to catch errors returned by system.

2. memmap in case of linux:
checking for eax<0 isn't enough. linux user space covers 3gb, so
returned pointer can be >7FFFFFFFh. again, -4096 is the magic value.

3. os.system in linux
errors returned by linux.fork() goes completely uncatched.

4. stdin.read in case of win32
why do you check just AL for 0? manual says you need to check entire
return value, which is EAX. What if returned nonzero value is 100h?

-------- now let's get a level higher:

5. stdin.readln
- treating EOF like empty line typed doesn't seem as best solution to
me. usual behavior of input reading routines is to skip all empty space
(including empty lines) before reaching data it wants to read. This may
cause forever-looping.
- i think i have read that maximal linux input size is 4096 characters,
more than yours 1023.

-------- one more level higher:

6. _geti_
- your bad treating of EOF shows up here. altough i cannot test it, i
bet that trying to read number when we are on EOF causes infinite loop.
readln always returns empty string, which is considered as a delimiter
by _geti_. So it will be forever skipping delimiters. This is critical
*design* problem, coming from fact you decided to ignore EOF on input
and then hacked translating EOFs to empty lines.
- also, why do you allow only "delimiter" characters to end number?
it's pretty common to accept for example decimal number "134" from
input "134abc", and leave "abc" on input.
- your fixed input buffer shows up here as another design problem: what
if there is several thousands "0" characters on input, followed by "1"?
This is perfectly valid input, with value 1.
- behavior of your input functions in case of "input value out of
range" differs depending on size of input. If input for geti16 is for
example "123455663532423421412", then number is left on input, but if
it's "32769", then number is readen off the input. How do you await
such error to be handled by caller? Such error is completely not
handlable, and is only useful for displaying it to user.

you see, there are pretty many design problems with HLALib, i hoped you
will fix them for version 2, but you seem to keep ignoring them (I
already told you about some of them).

Looking forward for your answers / explainations

.

Relevant Pages

  • Re: [SLE] cant establish a dial-up conn with kinternet
    ... They are always empty from a fresh install. ... >How this would have anything to do with a non-responsive modem is ... As you said, without it, even though the modem ... Registered Linux user 231871 ...
    (SuSE)
  • Ext3 overhead question
    ... always formatted when installing or upgrading so this was a new for me. ... I partitioned it as one giant Linux ... of the drive is being used already but the drive should be empty. ... normal overhead what should I do to bring it down? ...
    (alt.os.linux)
  • Re: Opening a file for update with creation if necessary
    ... the one on Linux says "Open for writing. ... there's still a risk of race conditions; i can't lock the ... file until i've got it open, and opening with w+ will clobber it, so it ... now has a file that's supposed to be empty but isn't! ...
    (comp.unix.programmer)
  • Re: New Install Of SUSE 9.1
    ... > that new partition have to be FAT32 or can it be NTFS? ... Just keep it empty, if you're going to use Partition Magic. ... Linux 2.4.20-4GB-athlon ...
    (alt.os.linux.suse)
  • Re: Absolute path in argv[0]
    ... Rich Teer writes: ... the path is always empty. ... Not on my Linux. ... Måns Rullgård ...
    (comp.unix.programmer)