February 2005 - Gpc

Re: Bug in function parsing?
by Markus Gerwinski 08 Feb '05

08 Feb '05

Hi Folks! Frank Heckenbach wrote: > Markus Gerwinski wrote: > > This results in a 'Header does not match previous definition' for function Bar. > Yes, according to the standard (*), the result variable must be > present in the original declaration as well. GPC didn't check this > before, but does now. > > (*) This is only stated in the Object-Oriented Extensions, 6.7 (d): > > : [...] and if one function definition contains a result variable > : specification, then the other also has a result variable > : specification of the same spelling. What's the point in declaring a local result variable in the unit interface?!? I mean, the code Function bar = result: integer; begin (* bar *) ... end (* bar *); is, in fact, nothing but an abbreviated way to write: Function bar: integer; var result: integer; begin (* bar *) ... bar:= result; end (* bar *); So `result` is actually a local variable, and no module using the unit will ever be able to access it. Why put it into the interface? I'd definitely feel more comfortable if we could skip the standard here and permit the other syntax again... Regards, Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201

3 3

not 0
by Adriaan van Os 08 Feb '05

08 Feb '05

GPC accepts: var i: integer value not 0; but it doesn't accept: var w: word value not 0; not.pas:4: error: constant out of range not.pas:4: error: initial value is of wrong type so, the workaround is: var w: word value not word( 0); At first sight, this looks a bit clumsy (but at second sight it may not). It gives rise to general questions about the type of constants in Pascal, e.g. * is there a difference between $FF.. and $0FF.. ? * is $FF.. signed or not ? Any comments ? Regards, Adriaan van Os

5 18

Wanted: Maintainer for my Units and Documentation
by Eike Lange 08 Feb '05

08 Feb '05

Hi Folks! I cannot maintain my units and documentation due to some personal activities any longer. It would be nice, if someone could overtake my contributions, which are * unit for mysql version 4 * unit for mysql version 3 * unit which interfaces Xlib.h * unit for zlib * PostgreSQL unit * a simple SDL unit * Program, which extracts pascal-strings and writes a ".po"-file for the use of internationalization (pas2po). (See http://www.gnu-pascal.de/contrib/eike/ ) * German documentation about GNU-Pascal (See http://www.gnu-pascal.de/~eike/ ) Eike

1 0

Re: Bug in function parsing?
by Markus Gerwinski 08 Feb '05

08 Feb '05

CBFalconer wrote: > My own attitude is that the use of result is pointless in the first > place. It gains nothing that I can see over the standard method > "bar := ...". In fact I like to code many things as: > > FUNCTION foo : T > > VAR > anotherTvalue : T > > BEGIN > foo := someTvalue; (* default *) > .... > IF whatever THEN foo := anotherTvalue; > .... > END; > > Please show me something that the traditional method can't do. Function getIndexOf ( aData: tDataType ) = result: integer; var data: tDataType; begin (* getIndexOf *) result:= 0; data:= someFirstDataInForExampleALinkedList; while ( data <> aData ) and ( data <> nil ) do begin data:= getNextData ( data ); inc ( result ); (* ... and this is what you definitely need a result variable for. *) end (* while *); end (* getIndexOf *); Of course, you also can do so by explicitly declaring `result`as a local variable and assigning it to getIndexOf in the end, but personally, I find the above way far more elegant. Frank: Would it cause much effort/pain to make the old syntax possible again? ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

2 1

Bug in function parsing?
by Markus Gerwinski 07 Feb '05

07 Feb '05

Hi Folks! Seemingly the following code snippet cannot be compiled with the current GPC version: Unit Foo; Interface Function Bar: integer; Implementation Function Bar = result: integer; begin (* Bar *) result:= 2; end (* Bar *); end. This results in a 'Header does not match previous definition' for function Bar. Yours, Markus

2 1

segmentation fault
by willett 07 Feb '05

07 Feb '05

program file attached is a program missing a "}" which should get compilation error, but which compiles without errors and when run, gets a "Segmentation fault" and quits. tested on GNU Pascal version 20030830, based on gcc-3.3.2 Willett Kempton

7 19

64 bit GPC on AIX
by Peter Keenan 06 Feb '05

06 Feb '05

I have built GPC 20041218 on GCC 3.3.4 on AIX 5.2, and thought it might be useful to document my experiences. I wanted to have the capacity to build 64 bit programs, however only 32 bit libraries are installed for GPC. Following my earlier post http://www.gnu- pascal.de/crystal/gpc/en/mail11115.html Waldek suggested trying build a 64 bit version of GCC including GPC. However having tried various strategies I was not successful in building a 64 bit only version of any version of GCC, even without GPC. So I tried to just build a 64 bit libgpc.a. I eventually achieved this export OBJECT_MODE = 64 export CFLAGS=-maix64 then run ./configure in ...gcc3.3.4/gcc/p/rts directory edit Makefile add -maix64 to CFLAGS (CFLAGS=-O2) copy libgpc.a to ...lib/gcc-lib/power..../3.3.4/ppc64 This allowed me generate 64 bit programs. My program contained a reference to the memavail function in system.pas. I had earlier had some problems with this function in 32 bit mode when it gave an error http://www.gnu-pascal.de/crystal/gpc/en/mail11086.htm In 64 bit mode the use of this function did not report an error but partly disabled the operating system, which should have been quite impossible for a normal user without root privileges! The operator had to reset the machine following this error. Programs without this function call seem to work fine.

2 1

testsuite with gp
by Adriaan van Os 05 Feb '05

05 Feb '05

Built gp-0.57 on powerpc-apple-darwin. Tried to run the testsuite with PC=gp. [G5:gcc/p/test] adriaan% make EXTRA_PFLAGS=--longjmp-all-nonlocal-labels PC=gp rm -f *.dat *.o *.s *.i *.gpi *.gpd *.gpc core a.out stderr.out *.exe testmake.tmp dummy.c dummy.pas dummy.out diff_cr*.tmp fixcr fixcr.exe rm -f todo/a.out todo/*.exe todo/*.o todo/*.s todo/*.i todo/*.gpi todo/*.gpd todo/core PC="gp" PFLAGS=" --autobuild -g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " PFLAGS_NO_PATHS="-g -O3 -W -Wall -Wno-unused --longjmp-all-nonlocal-labels " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" "*.pas" | tee test_log | "./test_sum" -d ./test_run: fatal: `--print-needed-options' yields: gp: internal problem: unexpected additional output of `gp -dumpmachine' Nothing was run. gp -dumpmachine on the command line displays gp help lines. I don't know if running the testsuite with gp is something that can already be done. Just reporting the results. Regards, Adriaan van Os

2 3

Re: [GPC]: daily digest (#613)
by Tom Schneider 03 Feb '05

03 Feb '05

Maurice: > Strange. > doing the same on DJGPP (W98se DOS box) with gpc 20041218 based on gcc 3.2.3 > behaves as expected. Hmm. I don't understand why it would be an issue on a Sun! > All is done manually with suitable tools to binary visualize the > true content of files, no shell scripts or functions which could be > too intelligent (I have bash, no tcsh) and hide something > "unimportant", for example no linefeed or ^Z (a DOS nicety on text > files) added at the end. The script demonstrated in three ways that the files had zero length. > A side comment: to make it work I needed to compile with > gpc add the --transparent-file-name > option to gpc (otherwise the filenames are asked at the beginning of the execution) > Why did you not need it ? You are right. I use a script, gpcc, which uses that option. The files are definitely empty - there is no need for me to clear them inside the Pascal program. The script uses `echo -n ""` to make them and three different standard unix tools (ls, wc, file) say they contain zero bytes. The results were in the initial report. I have just discovered something else. Using the *same* code and the *same* input files: gpc 20040516, based on gcc-3.3.3 fails (says empty files are not eof after reset). but the older GNU Pascal version 2.1 (20020510), based on gcc-2.95.2 19991024 (release). works! (says empty files are eof after reset) Thus the behavior of GPC has changed between these two. >From my viewpoint this is an extremly serious bug because so many of my programs use the eof test. What's happening is that I'm slowly updating programs and so I didn't notice it until now. I spent all night the other day trying to figure a way to replace eof with something that worked (using eof but is still standard) but failed. If I have to use the p2c converter to work with my programs, I will be forced to abandon GPC, just as I was converting all programs to function smoothly with it ... :-( This is now true for one program. I hope that this can be solved! Regards, Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Molecular Information Theory Group Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

6 11

--mac-pascal
by Adriaan van Os 02 Feb '05

02 Feb '05

Included is a diff that improves the employability of the --mac-pascal dialect. Previously, several language constructs available in GNU Pascal and in Macintosh Pascal compilers were rejected by gpc in --mac-pascal mode. I hope that with this diff most of them have been catched now. The new gpc builds and passes the testsuite on powerpc-apple-darwin. A few places in the source of the gpc compiler are unclear to me. They include: 1. predef.c line 423 chk_dialect ("direct access to files without declared domain is", B_D_PASCAL); 2. predef.c line 713 flags = (co->pascal_dialect & (CLASSIC_PASCAL_LEVEL_0 | CLASSIC_PASCAL_LEVEL_1)) ? NEG_ZERO_WIDTH_ERROR_MASK : (co->pascal_dialect & E_O_PASCAL) ? NEG_WIDTH_ERROR_MASK : (co->pascal_dialect & B_D_PASCAL) ? 0 : NEG_WIDTH_LEFT_MASK; 3. expressions.c line 124 chk_dialect ("string concatenation without `Concat' or `+' is", B_D_PASCAL); Regards, Adriaan van Os

6 18