Some obscure errors with BP 7.0

Quote
> Hello,

> I would like to know whether these errors sound common to anyone on this list.

BTW: It's not a list, it's a news group...

Quote
> I checked the FAQ and some error lists but could not find much related info.

> 1.
>   I have a large windows program, which uses a lot of memory management. I
>   bumped into the situation where 2 consecutive Getmem's reserved overlapping
>   memory. I changed all code with MemAlloc's, which did not change the
>   problem. Finally, using MemAllocSeg, the problem disappeared. Of course, I
>   still do not sleep too wel :-(

I found such a problem, too, but it was a consequence of a wrong freemem
earlier in my program. (And actually it cost me a whole lot of work to track
this down, too!) Here's a simple program that shows this behaviour:

{$ifdef windows} uses wincrt; {$endif}
var p1,p2,p3:pointer;
begin
  getmem(p1,8);
  getmem(p2,16);
  getmem(p3,16);
  freemem(p1,16); {This is wrong, of course!}
  freemem(p2,16);
  getmem(p1,16);
  getmem(p2,16);
  writeln('p1=',seg(p1^),':',ofs(p1^));
  writeln('p2=',seg(p2^),':',ofs(p2^));
end.

This will not cause any runtime errors, but at the end, p1 and p2 differ by
only 8 bytes, so they're overlapping.

I made a patch to HEAP.ASM (real mode) and WMEM.ASM (protected mode and
Windoze) which are used by SYSTEM, so that a wrong freemem as above will cause
a runtime error 204. If you want to rebuild the RTL, which means that you must
have BP7.0, you can apply the following patch to WMEM.ASM:

Replace line 377 in \bp\rtl\sys\WMEM.ASM
< @@2:    MOV     ES:[BX].hbNext,SI

by

Quote
>         MOV     DX,BX
>         ADD     DX,AX
>         CMP     DX,SI
>         JA      @@5
> @@2:    MOV     DX,DI
>         ADD     DX,ES:[DI].hbSize
>         CMP     DX,BX
>         JA      @@5
>         MOV     ES:[BX].hbNext,SI

I'm not posting the patch to HEAP.ASM, since it's a bit more complicated (at
least the way I did it), and Windoze was what was asked for.

Anyway, this is something to watch out for, if somewhere in the program more
memory is freed than was allocated.

Quote
> 2.
>   This same applications uses longints for primary keys. If you do things like
>   li := li + 4, then everything tends to break in some situations. What
>   happens, is that the (stupid) compiler casts the 4 to a 2 byte value, does
>   the same with li, adds this 4 to the (low) integer li (which should be a
>   longint)  and re-casts the result to a longint for li.

I can't find this error. The following gives the correct result 65538:

var li:longint;
begin
  li:=65534;
  li:=li+4;
  writeln(li)
end.

And AFAIK the compiler is clever enough to recognize longints and treat them
as 4 byte values correctly (see also the thread "help on LongInt").
I guess something's wrong with your code here. You can try posting the
problematic procedure.

Hope this helps,
Frank