Hi all,
When looking to a redent discussion on the fpk-mailing list with this subject, I have tried to make the same tests on gpc. I have found a bug in gpc which has nothing to do with the subject of the discussion. Working on plain dos djgpp with gpc-980511. The program is:
program size_bug;
type Time = object h,m,s:byte; constructor init; destructor done; virtual; end;
var OT:Time;
constructor Time.init; begin end;
destructor Time.done; begin end;
begin OT.init; writeln(SizeOf(OT)); end.
when compiling it says Abort! with the message:
Reading specs from f:/djgpp/lib/gcc-lib/djgpp/2.81/specs gpc driver version 2.81 executing gpc version 2.8.1 f:/djgpp/lib/gcc-lib/djgpp/2.81/gpc-cpp.exe -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__DJGPP_MINOR__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 size_bug.pas G:/ccba5tpj GNU CPP version 2.81 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: f:/djgpp/contrib/grx23/include /usr/local/include JDIR/djgpp/include JDIR/lib/gcc-lib/djgpp/2.81/include $DJDIR/include End of search list. f:/djgpp/lib/gcc-lib/djgpp/2.81/gpc1.exe G:/ccba5tpj -quiet -dumpbase size_bug.pas -version -famtmpfile=size_bug.gpc -o G:/ccca5tpj GNU Pascal version 2.81 (djgpp) compiled by GNU C version 2.8.1. size_bug.pas: In function `Time_Init': size_bug.pas:13: `with' element is of wrong type Abort!
It is the identifier Time which causes the problem. All becomes correct if it is replaced everywhere by Tim. As far as I know time is not a reserved word, and anyway you have allowed to redefine nearly all identifiers. ??? (otherwise gpc has the correct behaviour with respect to the purpose of the test: it bangs under CWSDPMI for dereferencing uninitialized pointer if OT is not initialized before computing SizeOf(OT), and gives a nonsense result when working in a WIN 3.11 DOS box which does not catch this illegal memory addressing, but this behavior is different from BP)