Hello,
Sorry for the wrong sample program and a silly doubt.The problem is we have large codes already written and we work in the support department that converts these sources to executables runnable on unix and i cannot change much of the code. This time i have analysed more and am attaching a code that works fine in BP and doesnot work in GPC.It is something to do with the pointers. Can you kindly tell me what the problem is? ---------------------------------- program typcast1; {type word=word(16);} type Mytype=record c:char; end; var p:pointer; begin getmem(p,sizeof(mytype)+2); word(p):=sizeof(mytype); p:=pchar(p)+2; mytype(p^).c:='h'; writeln(mytype(p^).c); end. ---------------------------------- thanks and regards, Anu
Frank Heckenbach wrote:
Anuradha wrote:
It is not a typecasting error.It's probably fillchar question.I find the following sample program ending in a "segmentation fault -core dump" , i think because of doing a fillchar of a record which has a member that's a pointer .
program a; type myrec=record x:^integer; end; var ptr :^myrec;
begin getmem(ptr,sizeof(myrec)); fillchar(ptr^,sizeof(myrec),0); ptr^.x^:=5; write(ptr^.x^); end.
Well, sure it crashes. You set ptr^.x to nil (by filling it with 0's), and then dereference it (ptr^.x^). Dereferencing nil pointers is one the most obvious bugs one can make with pointers, and it crashes on any Pascal compiler (except BP under Dos which will instead overwrite the system IRQ tables ;-).
Please don't take the following personal, but I'd really suggest people not to use such low-level features (like GetMem, FillChar, etc.) unless they really understand what they do. Pascal is a high-level language and has plenty of "clean" features to use instead -- e.g., a simple `New (ptr)' instead of the GetMem line, and instead of the FillChar, either `ptr^.x := nil' or `New (ptr^.x)' -- depending on what you really mean (the latter will work correctly in the program above, the former will at least make it quite clear why it crashes).
Rant over. ;-)
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html
-- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123
Sorry for the wrong sample program and a silly doubt.The problem is we have large codes already written and we work in the support department that converts these sources to executables runnable on unix and i cannot change much of the code. This time i have analysed more and am attaching a code that works fine in BP and doesnot work in GPC.It is something to do with the pointers. Can you kindly tell me what the problem is?
You do things with pointers that aren't allowed afiak.
program typcast1; {type word=word(16);} type Mytype=record c:char; end; var p:pointer; begin getmem(p,sizeof(mytype)+2);
Allocates a number of bytes,ok. (not necessarily 3 though, since the record may be padded)
word(p):=sizeof(mytype);
Here you cast a 32-bit pointer to a 16-bit Word, to set the lower word to one or two, which practically makes it a dangling pointer.
It seems that you try to exploit both the 16-bits seg:offset dos memory model, AND the fact that TP's default memory manager aligns on segment borders (which it afaik only does when in protected mode, in real mode it afaik aligns on 8 bytes)
It is something that might even fail if you use some unit that takes over the heapmanager in a TP program, let alone different 32-bit compilers that run on different operating systems.
p:=pchar(p)+2;
Should be possible. Doesn't deserve a beauty price though.
mytype(p^).c:='h'; writeln(mytype(p^).c); end.
-
Anuradha -
marcov＠stack.nl