October 2001 - Gpc

StringUtils, FileUtils
by Frank Heckenbach 31 May '02

31 May '02

Hi, in the current GPC version, I've included a StringUtils unit for general string handling routines (on a higher level than the built-in and RTS routines). Up to now, it only contains routines for a string hash table, but I'm planning to add some more routines. Perhaps some of you also have some routines to contribute (or features to request). Conditions for inclusion into this unit should be, IMHO: - Generally useful (not meant specifically for a certain program or something), - self-contained (not relying on an external library etc.), - new functionality compared to the existing routines (whereas the same or similar functionality under a different interface for compatibility purposes should go into other units, like GPCUtil for compatibility to `Turbo Power' units), - and, of course, compilable with the current GPC version, portable, bug-free, etc. ;-) The same goes for the FileUtils unit which has been there for some months already. Frank -- Frank Heckenbach, frank(a)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

2 10

Files
by berend＠beard.nest.nl 01 Feb '02

01 Feb '02

* Moved (from: gpc) by Berend de Boer using timEd 1.10.b3+. Peter Gerwinski wrote in a message to Berend de Boer: PG> I tried to use Extended Pascal "binding" to assign a file PG> variable to an external -- existing -- file. I just copied PG> the "Assign" pro- cedure by Berend as published in PG> borland2ep.doc. It does not always work: I often get a PG> runtime error saying that the file did not exist. If you can repeat it, compile with another Extended Pascal compiler, for example Prospero's one. If that fails too, there is really something wrong with the code. But I suspect gpc. You're using which OS? Groetjes, Berend (-: fido: 2:281/527.23 email: berend(a)beard.nest.nl

4 3

operators pow and **
by Maurice Lombardi 01 Feb '02

01 Feb '02

Hi all, It seems that operators pow and ** cannot be redefined in gpc. Is that expected ? I work with djgpp / w98 dos box (should be irrelevant I think) Thanks Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 51 45 44 mailto:Maurice.Lombardi@ujf-grenoble.fr

4 4

bug?
by Adam Naumowicz 23 Nov '01

23 Nov '01

Hello, Maybe that is a known bug but I encountered a strange problem and don't know what happens. I reduced the example to these three silly files: --------------------- program tester; uses tester1; begin ImpSgnList.Init(8); end. ---------------------- unit tester1; interface uses tester2; var ImpSgnList:MList; implementation end. ---------------------- unit tester2; interface type MList = object constructor Init(ALimit: Integer); end; implementation constructor MList.Init(aLimit: Integer); begin end; end. ---------------------- The result of execution is as follows: tester.dpr: In main program: tester.dpr:5: Internal compiler error in `call_method', at objects.c:137 Please submit a full bug report to the GPC mailing list <gpc(a)gnu.de>. See <URL:http://home.pages.de/~GNU-Pascal/todo.html> for details. I use the following compiler version: Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs gpc version 20010623, based on 2.95.3 20010315 (release) BTW: the same is with my another GPC version: Reading specs from /usr/local/lib/gcc-lib/i386-pc-solaris2.8/2.95.2/specs gpc version 20010121, based on 2.95.2 19991024 (release) I hope there is an explanation of this behavior, or if this is a new bug, there will be a way to correct it. Regards, Adam Naumowicz -------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------

3 4

Problems building GPC when host!=build
by Andris Pavenis 13 Nov '01

13 Nov '01

Configuring in p/rts fails when host!=build (for example when building native compiler for DJGPP or MINGW under Linux) as newly built xgcc and xgpc cannot be run on build system. In this case we should run corresponding cross-compiler instead. Included patch is tested only for --build=i686-pc-linux-gnu, --host=i586-mingw32msvc --target=i586-mingw32msvc Andris --- gpc-20010924/p/Make-lang.in~1 Mon Sep 24 19:59:48 2001 +++ gpc-20010924/p/Make-lang.in Tue Oct 30 17:57:24 2001 @@ -154,8 +154,12 @@ ADD_RTS_PARENT_DIR = sed -e 's,-B$[^/][^:]$,-B../../\1,g;s,^$[^/][^:]$,../../\1,' # The ' ' is there so, e.g., `-B.' will be replaced by ADD_RTS_PARENT_DIR -RTS_COMPILERS = CC="`echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" \ - PC="`echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR)`" +RTS_COMPILERS = CC="`if test \"$(build_canonical)\" = \"$(host_canonical)\" ; then \ + echo $(GCC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR); \ + else echo $(GCC_FOR_TARGET); fi`" \ + PC="`if test \"$(build_canonical)\" = \"$(host_canonical)\" ; then \ + echo $(GPC_FOR_TARGET)' ' | $(ADD_RTS_PARENT_DIR);\ + else echo $(GPC_FOR_TARGET); fi`" GPC_GENERATED_SRC = \ $(srcdir)/p/parse.c \

3 10

Re :Typecasting | record-field boundry
by Anuradha 01 Nov '01

01 Nov '01

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

4 3

not used or set
by toms＠ncifcrf.gov 01 Nov '01

01 Nov '01

Folks: I am compiling my programs with both GPC and Sun's compiler. A service that the Sun compiler provides is to check that a variable is actually used or set. For example, it will say: pc0: WorkShop Compilers 4.2 01/04/00 Pascal 4.2 patch 104632-11 Wed Oct 31 08:05:05 2001 numcode.p: In procedure checkcount: w 18260 variable f is neither used nor set This would be a very useful feature to have as it allows one to remove unused or leftover variables. In this case I was using a global (output) when I should have been using the locally defined file! Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/

2 1

Probs building gpc on sparc/solaris
by Stephan Eickschen 01 Nov '01

01 Nov '01

Dear List, May be it's an OT but I couldn't find anything matching in the archives or at google. I downloaded gpc-20010924.tar.gz gcc-core-2.95.2.tar.gz unpacked them, followed the instructions in INSTALL (...) configure --enable-languages=pascal (...) executed a gmake and get: > cd /home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/doc/en/info && makeinfo -I .. -I ../.. -I ../../generated -o gpc.info gpc.texi > Making info file `gpc.info' from `gpc.texi'. > ../install.texi:143: Unknown command `smallformat'. > ../install.texi:145: Unmatched `@end'. > ../install.texi:155: Unknown command `smallformat'. > ../install.texi:158: Unmatched `@end'. > ../reference.texi:8587: itemize requires an argument: the formatter for @item. > ../reference.texi:8599: itemize requires an argument: the formatter for @item. > makeinfo: Removing output file `gpc.info' due to errors; use --force to preserve. > gmake[1]: *** [/home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/doc/en/info/gpc.info] Error 2 > gmake[1]: Leaving directory `/home/AIDA301/eicksch/gpc/build/gcc' > gmake: *** [all-gcc] Error 2 uname -a SunOS aida3 5.8 Generic sun4u sparc SUNW,Ultra-5_10 Any suggestion / help??? Best regards, Stephan -- ---------------------------------------------------------------------- Stephan Eickschen Tel. : +49 (0)8153 28-1351 GeoForschungsZentrum Potsdam (GFZ) Fax. : +49 (0)8153 28-1207 Division 1, Section 1.2 c/o email: eicksch(a)gfz-potsdam.de DLR Oberpfaffenhofen www : http://op.gfz-potsdam.de Box 1116 82234 Wessling Germany ----------------------------------------------------------------------

2 1

Re: Typecasting
by da Silva, Joe 31 Oct '01

31 Oct '01

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

1 0

Re: Typecasting
by da Silva, Joe 31 Oct '01

31 Oct '01

What is the purpose of these two lines : ? word(p):=sizeof(mytype); p:=pchar(p)+2; Joe. > -----Original Message----- > From: Anuradha [SMTP:anuradha@adcc.alcatel.be] > Sent: Tuesday, October 30, 2001 8:54 AM > To: gpc > Subject: Re: Typecasting > > 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(a)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 > >

4 3