- Gpc - gnu.de

enumerations in units problem
by Sam B 11 Dec '98

11 Dec '98

Greetings, I am having a rather strange problem when using an enumerated type declared in a unit. If that type is used in a second unit, and also in a third that uses both the first and second, the type cannot be used as a parameter to a function. This probably isn't a very good description, so please just look at the example I have included at the end of this post, it is the smallest program I could produce to generate the problem. The output from gpc is: > gpc p.pas p.pas: In function `program_P': p.pas:23: incompatible type for argument 1 of `U_proc' I am running on Redhat Linux 5.0, and my gpc version is version 19980830, based on gcc-2.8.1. Does anyone know what might be causing this, and if there is a workaround or fix? Thanks in advance, Sam. --- begin example (p.pas) --- unit e; interface type t_e = ( e_a, e_b ); implementation begin end. unit u; interface uses e; procedure u_proc(e: t_e); implementation procedure u_proc; begin end; begin end. program p; uses e, u; begin u_proc(e_a); { error is generated on this line } end. --- end example --- ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Bug in gpc-cpp ?
by Ian Thurlbeck 08 Dec '98

08 Dec '98

Hello again, fellow Pascalers! After getting a bug fix for the set addition problem from Peter (thanks very much Peter!) within 24 hours I've decided to try my luck again. There is some strangeness with the gpc-cpp preprocessor; here is some code to trigger it: ------- main.h --------- #ifndef Funny #define Funny 1 #endif {**} {**} ------- end ------------ ------- main.p --------- program MxFiler; #include "main.h" BEGIN writeln('Hello '); END. ------- end ------------ If you do: ida % gpc -E main.p then gpc-cpp goes into a infinite loop. Now the strange bit. If you remove any of these lines/characters the preprocessing works as expected: 1) Change #ifndef to #ifdef in main.h 2) Remove the #ifndef and #endif lines in main.h 3) Remove either of the comment lines in main.h 4) Remove the trailing '}' from the first comment line in main.h 5) Remove #include from main.p and replace it with the contents of main.h I can easily work around this of course, but a fix would be better! Thanks for any help! Ian -- Ian Thurlbeck http://www.stams.strath.ac.uk/ Statistics and Modelling Science, University of Strathclyde Livingstone Tower, 26 Richmond Street, Glasgow, UK, G1 1XH Tel: +44 (0)141 548 3667 Fax: +44 (0)141 552 2079

2 1

GPC 19980830 Bug in SET handling ?
by Ian Thurlbeck 08 Dec '98

08 Dec '98

Dear Pascalers The following code core dumps during the set 'in' operation: ------ cut ---------- program setbug(input,output); CONST FirstChar = ['+','-','0'..'9']; #ifdef FIX GoodChar = ['+','-','0'..'9','.','e','E']; #else GoodChar = FirstChar+['.','e','E']; #endif VAR ch:CHAR; in_set:BOOLEAN; BEGIN ch:='0'; writeln('Here we go:'); in_set:= ch IN GoodChar; writeln('in_set is ', in_set); END. ------ cut ---------- ida % gpc -g -o tt tt.p ida % ./tt Here we go: Segmentation fault (core dumped) ida % gdb /usr/local/egcs-1.1b-obj/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.91.57/gpc1 core [ ... ] Core was generated by `./tt'. Program terminated with signal 11, Segmentation fault. #0 0x80491f5 in rindex () (gdb) backtrace #0 0x80491f5 in rindex () #1 0x4000a1f8 in ?? () #2 0x8049348 in ftell () (gdb) Note I can fix it by using the alternate code: ida % gpc -DFIX -g -o tt tt.p ida % ./tt Here we go: in_set is True ida % Compiler details: ida % gpc -v Reading specs from /usr/local/egcs-1.1b-obj/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.91.57/specs gpc version 19980830, based on egcs-2.91.57 19980901 (egcs-1.1 release) Any suggestions ? Of course I can always use the workaround. Many thanks Ian -- Ian Thurlbeck http://www.stams.strath.ac.uk/ Statistics and Modelling Science, University of Strathclyde Livingstone Tower, 26 Richmond Street, Glasgow, UK, G1 1XH Tel: +44 (0)141 548 3667 Fax: +44 (0)141 552 2079

2 1

Re: GPC 19980830 Bug in SET handling ?
by Frank Heckenbach 07 Dec '98

07 Dec '98

Ian Thurlbeck wrote: > #ifdef FIX > GoodChar = ['+','-','0'..'9','.','e','E']; > #else > GoodChar = FirstChar+['.','e','E']; > #endif > > [...] > > Any suggestions ? Of course I can always use the workaround. Unfortunately no other suggestion. GPC's set code is not very reliable, and esp. set addition is known to be buggy. :-( Since there don't seem to be many programmers using sets (besides you and me), this problem doesn't have very high priority on the to-do list... So, you'll probably have to live with workarounds for awhile -- unless you want to hack GPC itself and fix the bugs... Frank -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Patch for building gpc-19980830 with egcs-1.1.1.
by Niels Kristian Bech Jensen 06 Dec '98

06 Dec '98

Hi, I've built gpc-19980830 with egcs-1.1.1 using gcc-egcs-2.91.55.diff and the patch below. This patch ensures that -DEGCS is added to CFLAGS if gpc is built with egcs. diff -urN gpc.orig/p/Make-lang.in gpc/p/Make-lang.in --- gpc.orig/p/Make-lang.in Mon Aug 31 03:05:02 1998 +++ gpc/p/Make-lang.in Sun Dec 6 13:39:11 1998 @@ -45,6 +45,11 @@ gpc_version=$(gpc_release) rts_version=$(gpc_release) +is_egcs := $(shell if $(CC) --version | grep 'egcs' > /dev/null; then echo y; else echo n; fi) +ifeq ($(is_egcs),y) +GPC_EGCS_FLAG=-DEGCS +endif + # Extra flags to pass to recursive makes. GPC_FLAGS_TO_PASS = \ "CROSS=$(CROSS)" \ @@ -54,6 +59,7 @@ "BISONFLAGS=$(BISONFLAGS)" \ "CFLAGS=$(CFLAGS)" \ "X_CFLAGS=$(X_CFLAGS)" \ + "GPC_EGCS_FLAG=$(GPC_EGCS_FLAG)" \ "LDFLAGS=$(LDFLAGS)" \ "LEX=$(LEX)" \ "LEXFLAGS=$(LEXFLAGS)" \ @@ -219,7 +225,7 @@ $(srcdir)/p/doc/sets.texi p/gpc.o: $(srcdir)/p/gpc.c $(CONFIG_H) gansidecl.h multilib.h Makefile $(lang_specs_files) - $(CC) -DGPC $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ + $(CC) -DGPC $(GPC_EGCS_FLAG) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \ -DGPC_MAJOR="\"$(gpc_major)\"" \ -DGPC_MINOR="\"$(gpc_minor)\"" \ -DGPC_RELEASE="\"$(gpc_release)\"" \ diff -urN gpc.orig/p/Makefile.in gpc/p/Makefile.in --- gpc.orig/p/Makefile.in Thu Jul 30 14:11:35 1998 +++ gpc/p/Makefile.in Sun Dec 6 13:39:41 1998 @@ -126,7 +126,7 @@ all.indirect: Makefile ../gpc1$(exeext) ../gpc-cpp$(exeext) ../libgpc.a # IN_GCC tells obstack.h that we are using gcc's <stddef.h> file. -INTERNAL_CFLAGS = $(CROSS) -DIN_GCC -DGPC +INTERNAL_CFLAGS = $(CROSS) -DIN_GCC -DGPC $(GPC_EGCS_FLAG) # This is the variable actually used when we compile. ALL_CFLAGS = $(INTERNAL_CFLAGS) $(X_CFLAGS) $(T_CFLAGS) $(CFLAGS) $(XCFLAGS) \ -- Niels Kristian Bech Jensen - nkbj(a)image.dk - http://www.image.dk/~nkbj/ ---------->> Stop software piracy --- use free software! <<----------

2 1

gpc gets segfault
by Miguel Lobo 06 Dec '98

06 Dec '98

I have recently downloaded GPC and tried to convert some of my Borland Pascal 7.0 files to compile with it. One of them stopped compiling with a segfault. After a while I managed to make a small source file which reproduces the bug: unit bug interface type o = object procedure f1(s: string(255)); end; var a: integer; implementation procedure f2; begin end; procedure f1(s: string(255)); begin end; Later I realized that maybe I shouldn't be using string(255) as a parameter's type, and when I defined string255 = string(255) and used string255 as the type for 's', it worked fine. Anyway, I think that it can be still called a bug since gpc stops with a "Internal compiler error". GPC's output when I try to compile that file is: parse error before '(' missing semicolon parse error before 'Implementation' gpc: Internal compiler error: program gpc1 got fatal signal 11. I am using Kernel 2.0.35, glibc-2.0.7, and gcc 2.7.2-3. Keep up the good work.

2 1

Re:
by Pablo Bendersky 03 Dec '98

03 Dec '98

> hi there i have a problem, i just starting this pascal programming and i > can't do question 10 on page 158, chapter 4. in pascal programming and > problem solving, by sanford leestma and larry nyhoff. think you can help, > please respond, thank you. melissa Maybe if you tell us the question of the book. I personally, don't know it. BTW, where is the .tt address from ? --- Pablo Gabriel Bendersky bender(a)einstein.com.ar UIN : 1916679 Buenos Aires - Argentina

1 0

Problem with compiling a program.
by Andrew Cameron 29 Nov '98

29 Nov '98

Hi, I have a problem in that I need to compile a program where a function is declared as type string. Here is a sample program test(input,output); function getname: string; begin getname := 'somestring'; end; begin end. The compiler aborts with parse error before 'String' If I declare the function as char it compiles. How do I get this to compile? Please reply directly as I have just subscribed to the List. I am using gpc version 2.0 Thanks in Anticipation Andrew Cameron

2 1

Re: Append on untyped files?...
by Frank Heckenbach 29 Nov '98

29 Nov '98

Orlando Llanes wrote: > On Thu, 26 Nov 1998, Frank Heckenbach wrote: > > Yes, use `Reset' and then `Seek' to the `FileSize' (BP compatible) > > or use `SeekWrite' or `SeekUpdate' (Extended Pascal standard) > > instead. (I hope this all works correctly now -- there were some > > problems with these things earlier. If there still are problems, > > send me a test program.) > > I tried with both BP and GPC, I don't think using Reset is supposed to > work since it's read only (I don't think it should either, it'll make > Reset -a read only statement- into an ambiguos statement). Well, that's what BP does. It's funny -- when GPC behaves differently as BP does, we get requests to make GPC "compatible"; and when we do, people start to realize BP's strangenesses. ;-) In BP, Reset is read-only only for text files, and for typed and untyped files when the global variable FileMode is set to 0 (default 2). In GPC, it's the same now... > I even tried > with SeekWrite, didn't bother to write SeekUpdate since 2 out of 3 are not > good odds :P The program I wrote to test it is at the end of this e-mail. Well, I tried it with BP 7.0 and the current GPC, and it does work with both. Of course, foo.txt has to exist before starting the program, just like it has to with Append in BP. If this is the problem, you can check FileExists before opening or use I/O checking like in the following code fragment (again, works well with BP and GPC for me). If there are other problems, tell me which ones. Assign( f, 'foo.txt' ); {$I-} Reset( F, 1 ); {$I+} if IOResult = 0 then Seek( F, FileSize(F) ) else Rewrite (F, 1); BlockWrite( F, V, sizeof(V) ); Close( F ); > Rename the file > Create a new file with the old name > Copy the contents of the renamed file into the new one > Delete the renamed file > > This is prolly also the only way to do it. I hope not. Besides the fact that it's very inefficient as you pointed out, it also loses information about file ownership, permissions etc. (maybe not applicable under Dos). Kevin A. Foss wrote: > If you want (non-extended) standard Pascal, you'll have to do this on > any type of file -- because there is no choice other than to rewrite() > when doing file output. The file handling that is there is as simple > as possible, probably so > it would be portable, but it has always been a pain with Pascal. True, but I think we should really allow ourselves at least the luxury of Extended Pascal... ;-) > Anyways, here's a use of extend (based on Orlando's code) on an untyped > file: This code doesn't work with the current GPC any more because of too strict type checking, but I fixed it so it should work again with the next GPC version, except that you have to replace rewrite(out); [...] extend(out); by rewrite(out,1); [...] extend(out,1); (Another stupid BP legacy for untyped files...)-: So, this will be the best solution after the next release. Until then, Reset and Seek should work fine. -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

2 1

Re: Some questions
by Frank Heckenbach 29 Nov '98

29 Nov '98

Gerry Dubois wrote: > RE Translating C header files > > Contact Florian Klaempfl <ba2395(a)fen.baynet.de> > a C to P header conversion program does exist and is currently being > inproved as part > of the FPC Pascal development. Especially for the PalmPilot port which > requires the conversion of all the PALM O/S C header files. > > You can download a copy from > > ftp://tflily.fys.kuleuven.ac.be/pub/fpc/source/ > > It's in rtl.zip utils/convert/h2pas How well does it work now? Last time I checked (which was some weeks ago), it wasn't quite usable. It failed for stdio.h and other standard headers, and what it did translate was far from a verbatim translation -- ISTR that it got the types quite mixed up, and tried to translate preprocessor macros to Pascal functions -- which I think causes more problems than it solves -- and other things... -- Frank Heckenbach, frank(a)fjf.gnu.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0