Hello,
* Leave alone the const, even if i equate the pointer to 'nil' the problem occurs.{ofcourse i did remove the writeln statement that dereferences the pointer}. * Why such coding at all : The whole code is in a function 'getmemory' that 'getmem's the required number of bytes and stores the number of bytes in the previous 2 bytes. There is also a procedure 'freememory' that reads the previous 2 bytes and frees as many bytes as was allocated earlier by getmemory. what could be the problem ? ----------------------------- program typcast1; type Mytype=record i : integer; c:^char; end; var p:pointer; begin getmem(p,sizeof(mytype)+2); fillchar(p^,sizeof(mytype)+2,0); word(p^):=sizeof(mytype); p:=pchar(p)+2; mytype(p^).c:=nil; end. ---------------------- regards, Anuradha
"da Silva, Joe" wrote:
I hope when you say "change p:=pchar(p)+2; to p:=pchar(p)+4;", you also change "getmem(p,sizeof(mytype)+2);" to "getmem(p,sizeof(mytype)+4);"!
<g>
I'm sure we all agree that this is very ugly, dangerous coding, but that's not the point. You are trying to "stretch the boundaries" of the compiler, to see how it behaves and to find out if there are any areas which may in practice cause problems with porting other code, right?
Well, to be honest, I can't see what the problem is here, although it must have something to do with 32 bit alignment. As far as I can see, the two lines "fillchar(p^,sizeof(mytype)+2,0);" and "word(p^):=sizeof(mytype);" are irrelevant. All you are doing is allocating 2 extra bytes of memory than your record type ("Mytype") needs, then offsetting a pointer to this by 2 bytes, thereby forcing the compiler to address the record (and in particular, the pointer "c" within the record) on a 16 bit boundary.
That's as far as I can analyse the situation, based simply on the source code presented. Since I don't know the "inner workings" of the compiler myself, perhaps someone else can comment further about this apparent alignment issue.
Joe.
-----Original Message----- From: Anuradha [SMTP:anuradha@adcc.alcatel.be] Sent: Wednesday, October 31, 2001 10:19 AM To: gpc Subject: Re: Typecasting
Hello,
I am really sorry for having missed a ^ in the program but you see , the program really worked in BP and not in GPC.But i do know that it is stupid to manipulate some parts of the pointer.kindly delete the previous mail. It is this program that i have problems in.
program typcast1; const ct :char='h'; type Mytype=record i : integer; c:^char; end; var p:pointer; begin getmem(p,sizeof(mytype)+2); fillchar(p^,sizeof(mytype)+2,0); word(p^):=sizeof(mytype); p:=pchar(p)+2; mytype(p^).c:=@ct; writeln(mytype(p^).c^); end.
But if i change p:=pchar(p)+2; to p:=pchar(p)+4; then it works.Is it something to do with the word-boundaries?
Thanks and regards, Anuradha
Marco van de Voort wrote:
What is the purpose of these two lines : ? word(p):=sizeof(mytype);
In real mode TP it sets the offset of the segment:offset pair to 1.
Probably it originally was meant as a simple inc(p);
The problem it expects that the offset part of a newly allocated block
is
always zero, which is afaik not true. (real mode TP allocates per half segment).
p:=pchar(p)+2;inc(p,2); or p:=@p[2];
The overall effect therefore is inc(p,3); or p:=pchar(p)[3];
-- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123
Anuradha wrote:
- Leave alone the const, even if i equate the pointer to 'nil'
the problem occurs.{ofcourse i did remove the writeln statement that dereferences the pointer}.
- Why such coding at all :
The whole code is in a function 'getmemory' that 'getmem's the required number of bytes and stores the number of bytes in the previous 2 bytes. There is also a procedure 'freememory' that reads the previous 2 bytes and frees as many bytes as was allocated earlier by getmemory. what could be the problem ?
program typcast1; type Mytype=record i : integer; c:^char; end; var p:pointer; begin getmem(p,sizeof(mytype)+2); fillchar(p^,sizeof(mytype)+2,0); word(p^):=sizeof(mytype); p:=pchar(p)+2; mytype(p^).c:=nil; end.
Totally unneccessary. The system remembers the size allocated all by itself.
getmem(p, sizeneeded); operateon(p^); dispose(p); p := nil; (* safety measure *)
Pascal is a simple language. It doesn't have pointer arithmetic for very good reasons. Don't try to contort it into C.
(I believe. Certainly Pascalp operates this way, so does C, which supplies the underlying library for GPC. Frank can confirm or deny).
getmem(p,sizeof(mytype)+2); fillchar(p^,sizeof(mytype)+2,0); word(p^):=sizeof(mytype); p:=pchar(p)+2; mytype(p^).c:=nil; end.
Totally unneccessary. The system remembers the size allocated all by itself.
getmem(p, sizeneeded); operateon(p^); dispose(p); p := nil; (* safety measure *)
Pascal is a simple language. It doesn't have pointer arithmetic for very good reasons. Don't try to contort it into C.
(I believe. Certainly Pascalp operates this way, so does C, which supplies the underlying library for GPC. Frank can confirm or deny).
This is TP incompatible I think. new and dispose are a pair, and getmem and freemem.
CBFalconer wrote:
Anuradha wrote:
The whole code is in a function 'getmemory' that 'getmem's the required number of bytes and stores the number of bytes in the previous 2 bytes. There is also a procedure 'freememory' that reads the previous 2 bytes and frees as many bytes as was allocated earlier by getmemory. what could be the problem ?
program typcast1; type Mytype=record i : integer; c:^char; end; var p:pointer; begin getmem(p,sizeof(mytype)+2); fillchar(p^,sizeof(mytype)+2,0); word(p^):=sizeof(mytype); p:=pchar(p)+2; mytype(p^).c:=nil; end.
Totally unneccessary. The system remembers the size allocated all by itself.
getmem(p, sizeneeded); operateon(p^); dispose(p); p := nil; (* safety measure *)
Pascal is a simple language. It doesn't have pointer arithmetic for very good reasons. Don't try to contort it into C.
(I believe. Certainly Pascalp operates this way, so does C, which supplies the underlying library for GPC. Frank can confirm or deny).
Confirm. Dispose and FreeMem are completely equivalent in GPC, and you even can omit the second parameter to FreeMem. So if you only need the extra memory for this purpose, you can avoid it entirely with GPC and replace getmemory by a simple GetMem.
And, of course, the 2 vs. 4 bytes issue looks quite much like the size of Integer, sso SizeOf (Integer) should work with both compilers. (Think about it: GPC allows memory allocations greater than 64 KB, so storing the size in 2 bytes is not a good idea. ;-)
Frank
-
Anuradha -
CBFalconer -
Frank Heckenbach -
marcov＠stack.nl