I just used Hi-Tech C to build a recoded version of John Hastwell-Batten's IZ program (originally in Pascal) and found a pretty savage bug in memset().  I have not yet rebuilt the library to fix the bug (I worked around the issue with a custom routine) but be aware that in the copy of 3.0.9 memset() should be avoided. It just does not produce the results you would expect.

Jon‚

Thanks for the warning about memset().  I haven't come across any problem as yet‚ but then I haven't used that function much.  It must have been a real pain to narrow down the problem you were having to memset().

memset(p‚ n‚ c)
register char * p;
register int    n;
char            c;
{
        while(n--)
                *p++ = c;
}

The bug here is the order of parameters. According to e.g. Linux man page for memset it should be memset(void *s‚ int c‚ size_t n). It should be possible to patch the libc.lib file‚ if you can find the code that reads the parameters from the stack.

I found the code of memset() in the libc.lib file by extracting memset.obj:
B> libr x libc.lib memset.obj
B> ddtz memset.obj
>l 11c
011C  LD   L‚(IX+06)   ; this is the first parameter
011F  LD   H‚(IX+07)
0122  PUSH HL
0123  POP  IY
0125  JR   012F       
0127  LD   A‚(IX+0A)   ; this is the third parameter (which should be 2nd)
012A  LD   (IY+00)‚A
012D  INC  IY
012F  LD   L‚(IX+08)   ; this is the second parameter (which should be 3rd)
0132  LD   H‚(IX+09)
0135  DEC  HL
0136  LD   (IX+08)‚L   ; 2nd parameter again
0139  LD   (IX+09)‚H
013C  INC  HL
013D  LD   A‚L
013E  OR   H
013F  JR   NZ‚0127    

So it's sufficient to swap the IX+0A and the IX+08/09 offsets. The patch addresses in the libc.lib file as found in the archive are:
B66E 0A => 08
B676 08 => 0A
B679 09 => 0B
B67D 08 => 0A
B680 09 => 0B

pullmoll‚

I have just had a quick look over the patch and it looks like that should fix the problem.  It really is incredible that this bug got into a production release.  We have to assume that when HI-TECH C was being developed‚ that they had virtually no testbed.  Something unthinkable in a compiler today.

Hello!

Thanks for memset patch‚ I used it in my CP/M program written in Hitech C.

BTW‚ are anybody has such problems with HTC too (and may be have a solution?) :
- compiler can not use long (32bit int) and char (8 bit int) together in the same arithmetic equation because char allways interpreting as 0 then. :)  It is needed to typecast char to short (16bit).  
- lowlevel IO (unixio.h: creat‚ open‚ close‚ write‚ read) is erroneous‚ while highlevel IO is working OK (stdio.h: fopen‚ fclose‚ fwrite‚ fread). 
- including of conio.h hangs compiler off

First feature (32bit int and 8 bit int operations) is very interesting and important because HTC is really single CP/M C-compiler natively operating with long (32bit int).