- Gpc - gnu.de

Re: GPC problem with redhat 9 (Linker
by Hiekkalinna Tero 10 Aug '03

10 Aug '03

> > GPC variable: > > > > % echo $GPC_EXEC_PREFIX > > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/ > > What are the contents of that directory? Here: -rwxr-xr-x 1 root root 6691112 May 11 04:49 cc1 -rwxr-xr-x 1 root root 308920 May 11 04:49 collect2 -rwxr-xr-x 1 root root 344917 May 11 04:49 cpp0 -rw-r--r-- 1 root root 1952 May 11 04:49 crtbegin.o -rw-r--r-- 1 root root 2284 May 11 04:49 crtbeginS.o -rw-r--r-- 1 root root 1952 May 11 04:49 crtbeginT.o -rw-r--r-- 1 root root 1216 May 11 04:49 crtend.o -rw-r--r-- 1 root root 1284 May 11 04:49 crtendS.o -rwxr-xr-x 1 root root 6639642 May 11 04:49 gpc1 -rwxr-xr-x 1 root root 208091 May 11 04:49 gpcpp drwxrwxr-x 5 root root 4096 Aug 1 13:48 include -rw-r--r-- 1 root root 1745556 May 11 04:49 libgcc.a -rw-r--r-- 1 root root 206352 May 11 04:49 libgcc_eh.a -rw-r--r-- 1 root root 589278 May 11 04:49 libgpc.a -rwxr-xr-x 1 root root 6777 May 11 04:49 specs drwxrwxr-x 2 root root 4096 Aug 1 13:48 units > > /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:871: undefined > reference to > > `__ctype_toupper' > > I don't know of this problem. Does such a function exist in > some library (you might want to grep for it in /usr/lib/lib* > or so ...)? > > If so, does it help if you add this library explicitly on the > command-line? If I execute command "gpc hello.pas -L/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/" : % gpc hello.pas -L/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/ /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 465): In function `_p_UpCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:871: undefined reference to `__ctype_toupper' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 485): In function `_p_LoCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:879: undefined reference to `__ctype_tolower' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 4a4): In function `_p_IsUpCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:884: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 4c4): In function `_p_IsLoCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:889: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 4e4): In function `_p_IsAlpha': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:894: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 524): In function `_p_IsAlphaNum': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:899: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 594): In function `_p_IsSpace': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:909: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2//libgpc.a(rts.o)(.text+0x 5b4):/home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:914: more undefined references to `__ctype_b' follow collect2: ld returned 1 exit status % Thanks for help! Tero

4 4

Problem on solaris
by Mehdi Khaldi 09 Aug '03

09 Aug '03

Hi, I work on a Solaris 7 plateform. GPC features are gpc version 2.1 (20020510), based on 2.95.2 19991024 (release) I have one module called sun.p : ------------------------------ Module SUN INTERFACE; export SUN = all; procedure myproc; CONST Max = 32767; Min = -32768; End. Module SUN IMPLEMENTATION; Procedure myproc; Begin Writeln('allo'); End; End. ------------------------------ I have one main program : ------------------------------ program essai; import sun; begin end. ------------------------------ When I compile with gpc. I get an error : ./src/testpascal.p:3: parse error before `1' When I watch the temporaries files, actually testpascal.i, I see "import sun" was switched by "import 1". What's wrong? Thanks

2 1

License of the GNU Pascal documentation?
by Matthias Klose 09 Aug '03

09 Aug '03

On The debian-legal mailing list there currently is a major discussion about the "freeness" of the "GNU Free Documentation License". You may want to look at the archives yourself, one point to start is http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00307.html The problem are the "Invariant Sections" of the GFDL, which make the GFDL non-free from Debian's viewpoint. Looking at gpc's documentation, I see the GFDL-1.1 (with the short example GFDL license at the end), but in the man page I only find: COPYING Copyright (c) 1997-2003 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 version published by the Free Software Foundation. A copy of the GFDL comes as a texinfo document along with the GPC manual. In contrast with copying-fdl.texi, there is no mentioning of the "Invariant Sections": "If you have no Invariant Sections, write ``with no Invariant Sections'' instead of saying which ones are invariant. If you have no Front-Cover Texts, write ``no Front-Cover Texts'' instead of ``Front-Cover Texts being @var{list}''; likewise for Back-Cover Texts." Please clarify the copyright of the man page. I'll have to remove the info and html docs from the Debian main section (maybe somebody volunteers to repackage them to the non-free section), but to keep at least the manual pages in the package I'd like to see the license of the manual pages be clarified. Thanks, Matthias

6 16

cross-referencing types
by Toby Ewing 08 Aug '03

08 Aug '03

Hi, all I'm running into a problem that I've never seen before, and hope someone here can help. I have a square grid of circles connected by lines: o--o--o--o--o | | | | | o--o--o--o--o | | | | | o--o--o--o--o The circles have different attributes; so do the lines. The basic data type I'm using is an array of pointers; each pointer points to a record of information about its circle. So far, so good. Each circle's record includes an array of pointers that point to the record of the (up to) 4 lines emanating from that circle. Likewise, I want each line record to be able to point to its two circles. This way they are cross-referential: when I'm working with a line I want to be able to find the circles it connects to, and when I'm working with a circle I want to be able to identify its (up to) 4 lines. So the code says: --------------------- type PCircle = ^CircleRec; CircleRec = record radius : double; x, y : double; t : array[0..3] of Pline; <-- "unknown identifier 'Pline'" end; Pline = ^LineRec; LineRec = record node_end : PCircle; width, length, end; Pnodary = ^nodary; nodary(wx, wy : shortCard) = array[1..wx,1..wy] of PCircle; ------------------- Naturally the compiler complains about the unknown identifier "Pline". And of course, if I reverse the order of the two records, it then complains about the unknown identifier PCircle. Is there any way to "forward declare" a record? Or am I going to have to do a serious reworking of how I handle the data? I realize of course that I could just say, I just left circle [x,y] going left, so the circle at the end of this line should be circle [x+1,y]. This utterly simple method is unfortunately not open to me, due to what data my program has access to and what it's not allowed to see. many thanks, Toby

2 2

Gcc-3.3.1 is released
by David Kredba 07 Aug '03

07 Aug '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ftp://gcc.gnu.org/pub/gcc/releases/gcc-3.3.1/gcc-3.3.1.tar.bz2 Regards, David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Msdes1v4vQGNXk8RArKpAJ9xVVGvtkUZZYO3BZf5ZLkk/gJC3ACcDImI xJWE3FnlreZ2u27erc2Vvo4= =TQX1 -----END PGP SIGNATURE-----

1 0

Re: range check test programs
by Mirsad Todorovac 07 Aug '03

07 Aug '03

On Sat, 12 Jul 2003, Frank Heckenbach wrote: [...] > Perhaps you've missed Francois' previous mail where he quoted the > items I have thought of already (appended below). If you can think > of more (which Francois didn't already write), fine, but first we > need someone to write those tests. Sure. Here is the point when I think I've done what I could. Let's go step by step with this list (I'm sorry if I'm repepating something that has been said already, but the list archive appears to be out :-(: > > > What's missing is a test where the formal discriminants are of a > > > subrange type and the actual discriminants (in `New' or a variable > > > declaration) are out of range. TEST mir040a.pas: gpc1: warnings being treated as errors ./mir040a.pas: In main program: ./mir040a.pas:34: warning: tag value must be a constant of ordinal type failed (I think it could be the problem in GPC, since the code is precisely the same, as with integer subrange bounds conformant arrays.) Am I allowed to suppress this specific warning, is it possible to do suppress it, or have I done something wrong? (mir040a.pas is in attachment.) > > > Initialization of types, variables and typed constants. (I.e., > > > variables (or fields) or subrange type with an out-of-range > > > initializer; must be locally, otherwise GPC won't accept > > > non-constants initializers.) Done. mir041[ceil][ul].pas > > > The `FillChar' test (fsc20.pas) shouldn't (I think) work like this > > > since it takes an untyped parameter. (Some people (ab)use it for > > > strange purposes.) Instead, the 3rd parameter may also be an > > > integer, so it's an error if it's < 0 or > Ord (MaxChar). Done: mir042[ul].pas > > I've found some more missing cases: > > > > - `Return' (where the result type is a subrange and the `Return' > > value is out of range) Done. mir0{24c[ul],25[ei][ul],26l[ul].pas > > - `Pack', `Unpack' (the index parameter) Done. mir03[56]*.pas > > - `Include', `Exclude' Done. mir028*.pas > > - `Inc', `Dec' Done. mir027*.pas > > - 4th parameter of `BlockRead', `BlockWrite' (not obvious, but GPC > > allows a subrange here which may be too small for the actual > > result) Done. mir039*.pas > > - `Val' (2nd and 3rd parameter) Done 2nd parm. mir034[ab].pas Q: What is the legal range for 3rd parm of Val? > > - `and', `or', `xor', `shl', `shr' used as procedures, e.g., if a is > > of type 1 .. 10: a := 5; or (a, 8) (whereas normal use as > > operators will be covered by assignments or whatever is done with > > them) Done. mir03[0-3]*.pas > > - Conformant arrays (i.e., where the index type in the conformant > > array in the formal parameter list is a subrange, and the actual > > parameter's range is too big -- check both bounds) Integer subrange Done. Problems with Char and enumerated subranges. I can confirm that it gives me this error: TEST mir038ea.pas: ./mir038ea.pas: In main program: ./mir038ea.pas:29: invalid operands to binary `+' ./mir038ea.pas:29: incompatible type for argument 1 of `conformantArray' ./mir038ea.pas:11: routine declaration failed {$gnu-pascal} program mir038ea; {slice array write, what Francois has done for Integer here is for subrange} uses GPC; type TGrayScale = (Black, Gray10, Gray20, Gray30, Gray40, Gray50, Gray60, Gray70, Gray80, Gray90, White); TMidTones = Gray30..Gray70; var v : array[1..100] of Integer; i,j : TGrayScale; procedure conformantArray(a: array[l..u : TMidTones] of Integer); begin end; procedure ExpectError; begin if ExitCode = 0 then WriteLn ('failed') else begin WriteLn ('OK'); Halt (0) {!} end end; begin AtExit(ExpectError); i:=Gray30; j:=White; {j > upper} conformantArray(v[i..j]); end. > > - `New' with variant records (where the variant tag is of subrange > > type) See the generated warning in test above. > > - sets (e.g., assigning a set of a larger range to one of a smaller > > range where the former contains out of range elements) Done. mir029*.pas Conclusion: 1. variant record warning 2. Val's 3rd parameter 3. Possible bug with conformant arrays when bounds are of Char subrange, confirmed it occurs with enumerated subranges too 4. All tests WILL AND MUST give "failed" if you don't have range-checking compiler, with range-checking on, they should give OK The latest result is at http://www.alu.hr/~mtodorov/pascal/rngv0.03.tar.gz There is significantly more of them now than in v0.02, and some bugs are fixed. I think we're moving somewhere. Have a nice day, Mirsad -- "I have a dream!" -- Martin Luther King Jr.

4 21

GPC problem with redhat 9 (Linker problem?)
by Hiekkalinna Tero 06 Aug '03

06 Aug '03

Hi, I have problem with GPC under Redhat 9 (x86), I have installed GPC (version: gpc-20030507-with-gcc.i686-pc-linux-gnu.tar.gz) according to install instructions. And after that I run install-gpc-binary shell script (in /usr/local dir.) which told GPC install was OK, and told to add GPC_EXEC_PREFIX variable to enviroment. here is more info GPC version: % gpc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/specs Configured with: ../gcc-3.2.2/configure --enable-languages=pascal --prefix=/usr/local Thread model: posix gpc version 20030507, based on gcc-3.2.2 GPC variable: % echo $GPC_EXEC_PREFIX /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/ If I just compile example hello.pas, not link it: % gpc hello.pas -o hello It's fine and object file is created. BUT if I want to link it as well to binary I get lot's of errors: % gpc hello.pas -o hello /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x4 65): In function `_p_UpCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:871: undefined reference to `__ctype_toupper' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x4 85): In function `_p_LoCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:879: undefined reference to `__ctype_tolower' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x4 a4): In function `_p_IsUpCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:884: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x4 c4): In function `_p_IsLoCase': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:889: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x4 e4): In function `_p_IsAlpha': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:894: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x5 24): In function `_p_IsAlphaNum': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:899: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x5 94): In function `_p_IsSpace': /home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:909: undefined reference to `__ctype_b' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2.2/libgpc.a(rts.o)(.text+0x5 b4):/home/frank/gpc/gcc-3.2.2/gcc/p/rts/rts.c:914: more undefined references to `__ctype_b' follow collect2: ld returned 1 exit status % Have I missed something from installation or is there something I need to fix? THANKS FOR HELP!! Best Regards, Tero Hiekkalinna

3 2

Units and --uscd-pascal
by Adriaan van Os 05 Aug '03

05 Aug '03

[G4:~/gnu/testgpc/adriaan] adriaan% cat unita.pas unit A; interface end. [G4:~/gnu/testgpc/adriaan] adriaan% gpc -c unita.pas --ucsd-pascal unita.pas:2: error: units are an extension of Borland Pascal, traditional unita.pas:2: error: Macintosh Pascal UCSD Pascal certainly supports units. unita.pas:3: error: units without `implementation' part are an extension of unita.pas:3: error: traditional Macintosh Pascal UCSD Pascal also supports units without 'implementation part', or at least Apple UCSD Pascal does. Regards, Adriaan van Os

5 21

bug report
by John Ollason 04 Aug '03

04 Aug '03

Attempting to compile the following code ------------ program objtest(input,output); type obj=object a:integer; constructor initialize; end; procedure obj.initialize; begin a:=3; end; var a,b:obj; begin b.a:=0; a.initialize; b:=a; writeln(b.a); end. ------------------- I received the following error message: -------------- cd ~/pas/ gpc objtest.p objtest.p: In function `Obj_Initialize': objtest.p:10: Internal compiler error in `yyparse', at parse.y:3601 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. Compilation exited abnormally with code 1 at Sun Aug 3 16:57:52 ______________ and I am complying with the instruction to report the error, though when I went to the above URL I found that it was dealing with C++ so I thought that I ought to mention it here. Details Red Hat Linux release 7.3 (Valhalla) Kernel 2.4.18-3 on an i686 gpc --version gives 2.1 (200205), based on gcc-2.95.4 20010315 (release) (I realise that I should have written constructor obj.initialize; and when I do that the program compiles, but in view of the instruction in the error message I am writing to the mailling list.) (If this is the wrong thing to do, I'm sorry.) John O.

2 1

Undetected errors on multiply imported identifier with conflicting definitions
by Gale Paeper 03 Aug '03

03 Aug '03

Extended Pascal allows for importing an identifier of the same spelling in the same scope through multiple interfaces as long as all the imports "denote the same value, variable. procedure, function, schema, or type". If they do not denote the same thing then there is an error of multiple defining-points for the identifier being imported through multiple interfaces. (See ISO 10206 paragraphs 6.2.2.7 and 6.11.3 for the requirements language.) While GPC does allow for the import of an identier through multiple interfaces, GPC does not enforce the requirement that all the imports denote the same thing. Is this a known bug in GPC's support for Extended Pascal? A test program demonstrating the problem: {$extended-pascal} program grp1(input, output); {Undetected import error. Type identifer 't1' imported through grp1b does not denote the same type as type identifier 't1' imported through grp1a.} import grp1a; grp1b; begin writeln('FAIL'); end. {$extended-pascal} module grp1a; export grp1a = (t1); type t1 = char; end; end. {$extended-pascal} module grp1b; export grp1b = (t1); type t1 = integer; end; end. compiled with: gpc --automake -v grp1.pas -o grp1 Reading specs from /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d6/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d6 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3 /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/gpcpp -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -quiet -v -iprefix /usr/bin/../lib/gcc-lib/powerpc-apple-darwin/3.3/ -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__DYNAMIC__ grp1.pas -fautomake -famtmpfile=/var/tmp//ccgw5pLe.gpa /var/tmp//ccZXMYCf.i GNU Pascal Compiler PreProcessor version 20030507, based on gcc-3.3 (Darwin/PowerPC) /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/gpc1 /var/tmp//ccZXMYCf.i -fPIC -quiet -dumpbase grp1.pas -auxbase grp1 -version -fautomake -famtmpfile=/var/tmp//ccgw5pLe.gpa -o /var/tmp//cc3HAIMV.s GNU Pascal version is actually 20030507, based on gcc-3.3 GNU Pascal version 3.3 (powerpc-apple-darwin) compiled by GNU C version 3.3. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Reading specs from /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d6/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d6 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3 /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/gpcpp -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -quiet -v -iprefix /usr/bin/../lib/gcc-lib/powerpc-apple-darwin/3.3/ -M -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__DYNAMIC__ grp1a.pas -o /var/tmp//ccoq7D0z -fautomake -famtmpfile=/var/tmp//ccgw5pLe.gpa GNU Pascal Compiler PreProcessor version 20030507, based on gcc-3.3 (Darwin/PowerPC) Reading specs from /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d6/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d6 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3 /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/gpcpp -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -quiet -v -iprefix /usr/bin/../lib/gcc-lib/powerpc-apple-darwin/3.3/ -M -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__DYNAMIC__ grp1b.pas -o /var/tmp//ccEGg8MF -fautomake -famtmpfile=/var/tmp//ccgw5pLe.gpa GNU Pascal Compiler PreProcessor version 20030507, based on gcc-3.3 (Darwin/PowerPC) as -o /var/tmp//ccHb3AkK.o /var/tmp//cc3HAIMV.s /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/collect2 -dynamic -o grp1 -lcrt1.o -lcrt2.o -L/Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3 -L/Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/../../.. grp1b.o grp1a.o /var/tmp//ccHb3AkK.o -lgpc -lgcc -lSystem | c++filt3 Gale Paeper gpaeper(a)empirenet.com

2 1

Usage of commandline path-options ?
by Samoth 02 Aug '03

02 Aug '03

Hi ! I'm not very familar with unix-based systems and gcc, but I need to change from borland pascal to gnu-pascal on Windows (and later on other os', too). But as soon as I try to configure the system I got the first problems and the docs aren't very helpful at all. My problem is that most of my old projects need units from several paths on different drives, so I need to add more than one searchpath, but I don't know what is meant by dir[:dir...]. (The ':' follows after the drive-char in windows, so I wanted to now the usage of this seperator.) Perhabs someone could do an example with two unit-paths ( 'a:\Units1' and 'b:\Units2' ) ? Another problem is to use the cfg-file with gpcc.exe The lines with the paths seemed to be ignored, because the output of the arguments passed to gpc.exe does not include them. My config file looks like -U a:\unit1\;b:\Unit1\ -E g:\exe\ Many thanks for answering ... Thomas -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-QualitÃ¤tssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post

2 1

Dynamic Array Size
by Silvio a Beccara 29 Jul '03

29 Jul '03

Hi, how do I get the dimensions of a dynamic array? For instance, like the following: type PMatr2Dob10 = ^Tmatr2Dob10; Tmatr2Dob10 (Size1, Size2: Integer) = array [ 1 .. Size1, 0 .. Size2 ] of double; var kets: Pmatr2Dob10 Thanks very much Silvio a Beccara - Cornell University, USA

4 3

Conformant array problem
by Mirsad Todorovac 29 Jul '03

29 Jul '03

Hi, Here is the variant of Francois' test fsc28.pas: ----------------------- {$gnu-pascal} program mir037c; {slice array write, what Francois has done for Integer here is for Char} uses GPC; var v : array['A'..'Z'] of Integer; i,j : Char; procedure conformantArray(a: array[l..u : Char] of Integer); begin end; procedure ExpectError; begin if ExitCode = 0 then WriteLn ('failed') else begin WriteLn ('OK'); Halt (0) {!} end end; begin AtExit(ExpectError); i:='W'; j:=Succ('Z', 5); {j out of bounds so slice will be out of bounds too (write)} conformantArray(v[i..j]); { line 26 } end. ------------------------ here is what I get: bash-2.05b$ gpc mir037c.pas mir037c.pas: In main program: mir037c.pas:26: invalid operands to binary `+' mir037c.pas:26: incompatible type for argument 1 of `conformantArray' mir037c.pas:8: routine declaration bash-2.05b$ Now, what is done in fsc28.pas looks apparently the same: --------------------------- {$gnu-pascal} program fsc28; {slice array write} uses GPC; var v : array[1..100] of Integer; i,j : Integer; procedure conformantArray(a: array[l..u : Integer] of Integer); begin end; procedure ExpectError; begin if ExitCode = 0 then WriteLn ('failed') else begin WriteLn ('OK'); Halt (0) {!} end end; begin AtExit(ExpectError); i:=99; j:=110; {j out of bounds so slice will be out of bounds too (write)} conformantArray(v[i..j]); end. ----------------------------- And it passes. Thanks, Mirsad -- "I have a dream!" -- Martin Luther King Jr.

1 0

Bug report/feature request: overly aggressive warning on use of for-loop variable
by Joseph Oswald 29 Jul '03

29 Jul '03

The attached program demonstrates an issue with Gnu Pascal, version 20030507. The program cannot be compiled because of a non-existent "threat" on the global loop variable used in a subroutine. The main program has a loop which uses the variable, but calls no subroutines within the loop, and therefore is not vulnerable to any threat from use of that variable by other subroutines. Attempting to compile this program results in the message gpc -o forwarning forwarning.pas forwarning.pas: In main program: forwarning.pas:13: error: `for' loop counter is threatened in a subroutine This usage is present in Donald E. Knuth's WEB and TeX programs, and requires changing these loops to use unique loop variables. If there is a way to disable this check, I cannot find it in the documentation. gpc --version results in: Reading specs from /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d6/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d6 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3 Thank you for your help. --Joe Oswald

4 4

Range tests
by Mirsad Todorovac 29 Jul '03

29 Jul '03

I have been rather busy in all this rush before holidays. I've seen that some of those range tests had problem compiling within testsuite, mostly because of rather harmless problems such as capitalisation. I've fixed that (hopefully), and henceforth I'll take as a standard that I don't submit a test unless it's successfully passed (or in this case - successfully failed) in the testsuite, under testsuite's compile options. Please find what's been done so far at http://www.alu.hr/~mtodorov/pascal/rngv0.02.tar.gz At my side they are of course all "failed". It would be reassuring if I get a confirmation that on range-checking compiler they all pass "OK". Mirsad -- "I have a dream!" -- Martin Luther King Jr.

1 0

Redelaration problems.
by nick 28 Jul '03

28 Jul '03

Hi! As I told I have some problems in the last GPC version (20030507) with repeated declaration in implementation part. consider the following: module test1 interface; export test1=all; procedure mt1 (str:string); function mt2 (str:string):string; end. module test1 implementation; procedure mt1 (str:string); begin writeln (str); end; function mt2 (str:string):string; begin mt2:=str; end; end. this file doesn't compile. GPC tells that mt2 redeclaration doesn't match the first one. The funny thing is that if I add type mystr=string after the "export" line and then change the function to use mystr - everything compile. Nick

2 2

Get still an error under FreeBSD (for Mr. Heckenbach)
by Karim Forsthofer 27 Jul '03

27 Jul '03

Hello Sorry, for the delay.. I was in holiday. At the 15. of july, I wrote several Emails to the gpc mailing list, because I got same "make" error outputs, when I tried to compile gpc and gcc on my FreeBSD 5.1 OS. Frank Heckenback told me, to change a simple command in the ../gcc.3.2.1/gcc/intl/plural.y file. I changed it. But now , I get an other error msg from make (after running a long time). The last output is : gcc: No input files specified ***Error code 1 Stop in /usr/home/karim/gpc-build/gcc. etc. The msg is very short and I don`t know how to handle that or to fix it. Need some feedback Greetings __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und KlingeltÃ¶ne fÃ¼rs Handy bei http://sms.yahoo.de

2 2

Re: overly aggressive warning message
by Joseph Oswald 27 Jul '03

27 Jul '03

Frank & Gale-- Thanks for your quick response to my e-mail. Most of the errors you refer to are well-localized in Knuth's source, and are part of the program that is meant to be modified to suit the particular platform that is being ported to. Once the WEB system is bootstrapped, each of the issues except for the for-loop one is a one-line change in the original source. At least in this respect, Knuth had the foresight to allow his programs to survive for what is a very long time in computer terms! Knuth was not programming in dec-pascal; as I recall it was in Pascal-H on the SAIL system. So I am not surprised that compiler directives have changed. However, on the for loop issue, I can see no practical advantage to enforcing this point of the standard to the point of not compiling the program. Can this aggressive behavior possibly be restricted to a --pedantic mode? I.e., can the error be demoted to a warning unless a --pedantic mode is enabled? On a larger scale, I think it is more useful for GPC to allow existing Pascal programs, with all their flaws, to be ported to GNU and other modern systems than for it to act as an enforcement mechanism to ensure that any Pascal programs that have harmless violations of the standard get weeded out. gcc as a whole takes a similar approach, I think. Thanks again to all the GPC contributors for an excellent tool! --Joe Oswald >I tried to compile Web and TeX and noticed a few more problems, >though apparently all quite minor: >- a lot of warnings which all seem to be harmless, but point to > unniceties in the code > >Time for `--dec-pascal' ...? > > > In > > the area of for-statements, there are latent errors in quite a few > > programs since there are quite a few compilers around which don't > > enforce all the for-statement requirements. > >Seems quite so. (GPC does one or two more now, but still not all.) _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

BUG: GPC 20030507 on Mac OS X: does not recognize Macintosh line endings
by Joseph Oswald 27 Jul '03

27 Jul '03

The attached program and gzipped .txt files demonstrate a bug in GPC 20030507 compiled for Mac OS X. The EoLn(f) function does not recognize Macintosh line endings (character code decimal 13), only UNIX (decimal 10) line endings. Ideally, the EoLn behavior would recognize multiple possible line endings (including DOS CRLF), or at least be configurable at run-time. Running the macosx_eoln.pas on a Macintosh will result in the following output: file mac_eoln.txt had 0 lines. file unix_eoln.txt had 3 lines. Please be careful to preserve the line endings of the .txt.gz files in order to make the test a valid one. File transfer programs will often change the line endings of files believed to contain text, invalidating the test. gpc -v returns Reading specs from /Developer/Pascal/gpc33d6/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d6/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d6 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3 Thank you for your help. --Joe oswald

1 0

Re: implicit object pointer dereference
by Adriaan van Os 26 Jul '03

26 Jul '03

Prof A Olowofoyeku (The African Chief) wrote: > What you are describing is almost equal to the "new" style Delphi > Classes (actually, this is already over 7 years old, so it is not so > new - but I use "new" here to distinguish it from the original BP > object model). That type of Delphi compatibility, is, I believe, on the > to-do list - but perhaps not a high priority. There is also the "Object-Oriented Extensions to Pascal" proposal, of the Technical Committee X3J9, see <http://www.pascal-central.com/OOE-stds.html>. In passing, I have to mention that I personally prefer the BP object model, see section "E.6.5.1 The Object Model. ... The reference model has the following disadvantages: ...". Still, it is a given fact that traditional Macintosh Pascal compilers implemented the reference model. Regards, Adriaan van Os

7 16

Line numbers in error msgs
by Paul Davidson 26 Jul '03

26 Jul '03

Looked at GPC and GCC command line options for ability to give line number (when applicable) of error in source code. Currently am seeing messages like: lists.pas:1: error: parse error before `:' Is there way to get the actual line number in code where the offending syntax lives? Thank you

3 5

Linking the libgpc to be shared
by "Nick Ioffe 25 Jul '03

25 Jul '03

Hi! I've tried to make my libgpc be shared. I work on HP SuperDome - hppa2.0w-hp-hpux11.00 (or at least the configure calls it so). I've tried to install gpc based on gcc-2.95.X unsuccesfully so I've installed gpc-20030509 based on gcc-3.2.1. Everything worked OK. But libgpc installed as static despite WITH_SHARED=yes option. After checking p/rts/Makefile I've pointed out that in that file WITH_SHARED= i.e. is just empty. After fixing it and making inside the rts I've got the following: nm: libgpc.so.2.1.20030509 not found. It was because of -Wl,-soname=libgpc.`cat ...` option specified to xgcc on the linking step. Eliminating it didn't help, now I got another error: LD: DP relative code in file /var/tmp/xxx.o - shared library ... Adding the -fPIC option used in building the *.lo files to linking command helped. Now the question - why configure doesn't do all these things? Also before that I got some strange errors when configure erroneusly created rts-config.h file - it didn't found open64 and usleep functions in /usr/local/include/fcntl.h - it was discovered by compiler. Any ideas, why? Thank you in advance, Nick

3 5

uninitialized Output
by "Nick Ioffe 24 Jul '03

24 Jul '03

Hi! I'm trying to run some pascal with java. After Markus Gerwinsky help and some hard work getting libgpc to be shared library it is possible. The problem that the first example I tried was printing something from Pascal with writeln. Then I got a runtime error that Output variable is uninitialized. Shouldn't gpc work with standard descriptors or the StdOut, StdErr and the rest should be initialized somehow? also how should I initialize them? To what device/descriptor etc? opening file and writing into it works. Nick

2 1

Shared libraries using GPC and JNI
by nick 23 Jul '03

23 Jul '03

Hi! I'm trying to use some old Pascal modules in Java through JNI. 1. Is there any way of using Pascal directly or should I use it through C? 2. How should I create the mixed shared library (i.e. library containing C and Pascal objects) 3. What version of GPC and GCC is it prefferable to use? Thank you in advance, Nick

3 3

-Wpacked
by Adriaan van Os 22 Jul '03

22 Jul '03

The warning argument -Wpacked issues the following warning while compiling any source (program or unit): [G4:~/gnu/testgpc/adriaan] adriaan% gpc hello.pas -Wpacked hello.pas:0: warning: packed attribute is unnecessary for `Datevalid' 'Datevalid' is the first field of the GPC internal variable GPC_TimeStamp (in p/rts/time.pas). It should be noted that -Wpacked issues warnings per field, not per record. This suggests that in the compiler back-end packing is a field-attribute, not a record attribute. This would also explain that "Datevalid' does not need a packed attribute (because it is the first field in the record) although GPC_TimeStamp is densely packed. I don't know whether this is target-platform dependent or not. Reading specs from /Developer/Pascal/gpc33d7/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d7/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d7 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3 Regards, Adriaan van Os

1 0

CRT unit help
by Francisco Javier F. 22 Jul '03

22 Jul '03

I need to use the crt unit, but the compiler says that crt unit is not found: module/unit interface `Crt' could not be imported. Â¿Where is is supposed to be? thanx -- Now proudly running Debian Sid+ kernel 2.4.21 + XFS

2 1

Range check tests
by Mirsad Todorovac 21 Jul '03

21 Jul '03

Progress report would say that so far this has been done: - procedure parameter range - function `Return' value range - `Include', `Exclude' - `Inc', `Dec' - `and', `or', `xor', `shl', `shr' as procedure - sets (assignment to a set when expression contains elements out of set's range) - Val (2nd parm) It can be seen here: http://www.alu.hr/~mtodorov/pascal/rngv0.02.tar.gz (updated) Comments welcome, if you have time. Remaining is: - `Pack', `Unpack' - `BlockRead', `BlockWrite' 4th parameter - `Val' (3rd parm) (-- must dig legal errorcodes out of source to get something out of range) - conformant arrays (index type in conformant array's formal parameter list is a subrange) - `New' with variant records - initialization of types, variables and typed constants If we can think of more cases where range checking occurs, even better. Yet, frankly, I'm not that deep into internals. Cheers, Mirsad -- "Experience is a harsh teacher: first comes the test, and then the lesson."

1 0

warning: unused variable line number
by Peter N Lewis 21 Jul '03

21 Jul '03

It seems there is an off by one error with the "warning: unused variable" warning. Probably the line number is not saved when the variable identifier token is read, but instead the line following the entire variable declaration is used. Yep, declaring a typeless record supports this theory. program testpas11; procedure test; var a: Integer; b: record x,y: Integer; end; c: Integer; begin WriteLn( 'Hello' ); end; begin end. % gpc -Wall -c testpas11.pas testpas11.pas: In procedure `test': testpas11.pas:10: warning: unused variable `c' testpas11.pas:9: warning: unused variable `b' testpas11.pas:6: warning: unused variable `a' 1 program testpas11; 2 3 procedure test; 4 var 5 a: Integer; 6 b: record 7 x,y: Integer; 8 end; 9 c: Integer; 10 begin 11 WriteLn( 'Hello' ); 12 end; 13 14 begin 15 end. It would be nicer if it recorded the identifier's line number when the token was first read - I'm not sure how hard this might be though (might be easy too). Normally GPC is pretty good with line numbers... Enjoy, Peter. -- <http://www.interarchy.com/> <http://documentation.interarchy.com/>

5 9

--assert
by Adriaan van Os 21 Jul '03

21 Jul '03

Either the implementation of the --assert flag is incorrect, or I don't understand it's use, e.g. [G4:~/gnu/testgpc/adriaan] adriaan% gpc --assert hello.pas gpc: no input files [G4:~/gnu/testgpc/adriaan] adriaan% gpc --assert --stack-checking hello.pas gpcpp: invalid option `--stack-checking' Reading specs from /Developer/Pascal/gpc33d7/lib/gcc-lib/powerpc-apple-darwin/3.3/specs Configured with: ../gpc-3.3d7/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc33d7 --target=powerpc-apple-darwin Thread model: posix gpc version 20030507, based on gcc-3.3 Regards, Adriaan van Os

2 1

Option defaults
by Adriaan van Os 16 Jul '03

16 Jul '03

The graphical user interface of an IDE option panel for the GNU Pascal compiler, could have checkboxes for options iike "short-circuit", "extended-syntax" and many other. Now, if the user e.g. checks the "short-circuit" checkbox and unchecks the "extended-syntax" checkbox, the IDE plug-in could choose (1) to pass no command line arguments to GPC for these options, because both are set to their default (2) to pass command line arguments for both options, whatever their default. The disadvantage of (1) is that it breaks if the default changes or if the documentation is wrong, of (2) that it cumulates into a very long list of arguments. Any advice on what is the lesser evil ? Things become more difficult if the default for an option depends on the Pascal dialect, as with "ignore-packed" and other options. Here, a three-state user interface element "default, yes, no" may be the alternative. Regards, Adriaan van Os

3 3

(3. try) Make error with gpc under FreeBSD
by Karim Forsthofer 16 Jul '03

16 Jul '03

Hello I tried once again to compile gpc and gcc on my FreeBSD 5.1 system, but couldn`t made it. I explain each step to you that I did : 1. I am SU in my homedir /usr/home/karim (this is FreeBSD) and I unzip the files gpc-20030507.tar.gz and gcc-core-3.2.1.tar.gz "gzip -c -d gcc-core-3.2.1.tar.gz | tar xf -" "gzip -c -d gpc-20030507.tar.gz | tar xf -" 2. "mv /usr/home/karim/gpc-20030507/p /usr/home/karim/gcc-3.2.1/gcc/" 3. "mkdir /usr/home/karim/gpc-build" 4. "cd /usr/home/karim/gpc-build" 5. "/usr/home/karim/gcc-3.2.1/configure --enable-languages=pascal" 6. Hit enter when script ask me to patch gpc. 7. Configure worked fine and creating ./config.status creating Makefile creating intl/Makefile creating fixinc/Makefile creating gccbug creating mklibgcc creating auto-host.h 8. "make" make begins to compile but puts out a lot of warnings of the type: warning: ISO C89 does not support 'long long' Then make stops with an error at the line "bison -y -d --name-prefix__gettext --output plural.c /usr/home/karim/gcc-3.2.1/gcc-3.2.1/gcc/ intl/plural.y " "conflicts: 7 shift/reduce /usr/home/karim/gcc.3.2.1/gcc/intl/plural.y: expected 10 shift/reduce conflicts *** Error code 1 Stop in /usr/home/karim/gpc-build/gcc/intl. *** Error code 1 Stop in /usr/home/karim/gpc-build/gcc. *** Error code 1 Stop in /usr/home/karim/gpc-build. ehh ??? I also checked all requierd programs: bash I use sh sed o.k awk o.k m4 o.k bison o.k flex o.k autoconf o.k help2man o.k makeinfo o.k I got also the same error, when I tried to compile only gcc without gpc. I will also post this error msg on an gcc mailinglist, but it would be nice if some gpc people can give also some feedback to fix it. Have a nice day Karim __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und KlingeltÃ¶ne fÃ¼rs Handy bei http://sms.yahoo.de

5 7

Re: implicit object pointer dereference
by Prof. A Olowofoyeku (The African Chief) 16 Jul '03

16 Jul '03

Peter N Lewis <peter(a)stairways.com.au> wrote: [...] > Could you describe the differences between Delphi "Classes" and GPC > objects? Hmmm - where does one start? I am not sure that this is the place to embark on a full discussion of this - but I will mention a few highlights. There are many similarities, since both are Borland's Pascal extensions. The main differences - with Delphi classes, 1. objects are implicitly pointers 2. fields are implicitly dereferenced 3. you must always have at least one constructor (you can have as many as you want) and you must call a constructor before doing anything with the object, 4. the constructor call automatically allocates memory for the object (via compiler and/or RTL magic - don't know which), and then does whatever else you actually do in the constructor - so a constructor is a special type of method, which returns a pointer to the object 5. the constructor call is made by assigning the instance to the constructor - e.g., objvar := myobject.myconstructor; 6. you must always call a destructor if you wish to free memory used by the object (else you will get memory leaks) 7. the destructor call automatically frees memory for the object (via compiler and/or RTL magic - don't know which), after doing anything else that you tell it to do - so a destructor is a special kind of method, which (inter alia) frees the object's memory 8. virtual methods are overridden with the "override" directive, else you just get a duplicate method (or a compiler error? - don't remember which) 9. Because we are dealing with pointers, all descendants of the object are type-compatible with the ancestors (I can't recollect whether this is actually a difference or not) - e.g., type obj1 = class ... ... end; obj2 = class (obj1) end; obj3 = class (obj2) end; procedure foo (parm : obj1); ... var inst3 : obj3; ... foo (inst3); { legal } ... This is all I can think of at the moment ... Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/

1 0

Ports to 3.2.x, 3.3.x ...
by Mirsad Todorovac 15 Jul '03

15 Jul '03

Hi, all! Is there anybody to tell me what is the status of 3.2.x and 3.3.x ports of GPC? Are there any big issues like conversion from obstacks to garbage collector was in 3.x, and when it could be hoped for. I was interested because it could help GPC being officially supported in main GCC package of our country's University network. The packager is insisting on new shiny versions (relativelly fresh 3.3), yet I'm trying to negotiate inspite his official support. Thanks, Mirsad -- "I have a dream!" -- Martin Luther King Jr.

2 2

Changed behavior in 20030507
by J. David Bryan 15 Jul '03

15 Jul '03

I am working with gpc-20030507 (with gcc-3.2.3, i486-pc-mingw), and I have noted two changes in compiler behavior from gpc-20021128. I don't know whether these are bugs or intentionally revised features. 1. The "addr" function no longer observes the --no-typed-address command line switch. The GPC manual says: --no-typed-address Make the result of the address operator an untyped pointer (same as {$T-}). ...and: Addr returns the address of its argument. It is equivalent to the address operator.... ...so I would expect that "addr" and "@" would behave the same. They did under gpc-20021128. However, this now fails to compile with "--no-typed-address": program addrtest; var i : integer; a, b : ^ byte; begin a := @ i; { ok if --no-typed-address, fails otherwise } b := addr (i); { fails always, "incompatible pointer type" } end. 2. Using an interface-only module to declare routines in an exernal library no longer works. The importing program declares an external to "_init_<module-name>", but no entry point is provided by the module, so the program won't link. The GPC manual says: To use a function written in another language, you need to provide an external declaration for it - either in the program, or in the interface part of a unit, or an interface module. So I would think that the following would work: [ifmod.pas] module ifmod interface; export ifmod = (proc); procedure proc; end. [iftest.pas] program ifbug; import ifmod (proc); begin proc end. They both compile but fail during linking (presuming a library is supplied that declares "_Proc" as an entry point) with an undefined reference to "init_Ifmod". This worked in gpc-20021128 because "iftest.o" did not reference the "_init_Ifmod" entry point. -- Dave

2 5

Segfault with --enable-keyword
by J. David Bryan 14 Jul '03

14 Jul '03

Running gpc-20030507 with gcc-3.2.3 (i486-pc-mingw32), I wish to compile in Extended Pascal mode but also allow the "external" keyword. With "ifmod.pas" containing: module ifmod; export ifmod = (proc); procedure proc; external; end; end. ...and compiling this with: gpc --extended-pascal --enable-keyword=external -c ifmod.pas ...I get: gpc1.exe: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. In fact, I can produce the same error with just: gpc1 -fenable-keyword=x ...from the i486-pc-mingw32/3.2.3 subdirectory. I have reproduced this on the Chief's distribution as well. -- Dave

3 3

(2. try) Make error with gpc under FreeBSD
by Karim Forsthofer 14 Jul '03

14 Jul '03

Hello I also tried to compile the newer version of gcc and gpc. I downloadet gpc-20030507 and gcc-3.2.1 from the gnu-pascal page. The configure script worked also fine. But make puts errors on the screen. Here is the msg: conflicts: 7 shift/reduce /usr/home/name/gcc-3.2.1/gcc/intl/plural.y : expected 10 shift/reduce ***Error code 1 Stop in /usr/home/name/gpc-build2/gcc/intl/ etc. I made a new dir with the name gpc-build2 (because of the old version). Can anybody help me with this ? __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und KlingeltÃ¶ne fÃ¼rs Handy bei http://sms.yahoo.de

1 0

Make error when I compile gpc under FreeBSD
by Karim Forsthofer 14 Jul '03

14 Jul '03

Hello I have FreeBSD 5.1 beta, and I downloaded the gpc version gpc-20020510 and gcc-core version 2.95.2 form the gnu pascal main page. I made each step exactly like written in the "compiling gpc" Howto from the page. The configure script worked fine, but "make" puts an error on the screen : /usr/home/name/gcc-2.95.2/libiberty/sterror.c:465: conflicting for 'sys_nerr' /usr/include/stdio.h:350: previous decleration of 'sys_nerr' ***Error code 1 (note: Under FreeBSD the home dir is in /usr/home/name) Can anybody help me to fix this error ? __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und KlingeltÃ¶ne fÃ¼rs Handy bei http://sms.yahoo.de

2 1

gpc --help --v
by Adriaan van Os 13 Jul '03

13 Jul '03

gpc --help -v displays a list of available compiler options. Pascal specific options, however, are truncated to the first 23 characters, e.g. -fobject-destination-pa Path where to create ... Back-end options don't seem to be truncated, e.g. -fguess-branch-probability Enables guessing of ... The list of options is quite useful, even better in untruncated form. Regards, Adriaan van Os

5 10

Unit dependencies
by Adriaan van Os 13 Jul '03

13 Jul '03

Chapter 12.10 of the GPC docs "GPC’s Automake Mechanism – How it Works" reads as follows: "When a program/module/unit imports (uses) an interface, GPC searches for the GPI file (see Section 12.9 [GPI files], page 476) derived from the name of the interface. Case 1: A GPI file was found. Each GPI file contains the name of the primary source file (normally a ‘.pas’ or ‘.p’ file) of the module/unit, and the names of all interfaces imported. GPC reads this information and invokes itself with a command like gpc foo.pas -M -o foo.d This means: preprocess the file, and write down the name of the object file and those of all its source files in ‘foo.d’. GPC reads ‘foo.d’ and looks if the object file exists and if the source was modified since the creation of the object file and the gpi file. If so, GPC calls itself again to compile the primary source file. When everything is done, the ‘.d’ file is removed. If there was no need to recompile, all interfaces imported by the module/unit are processed in the same way as this one." I may be doing something wrong but "gpc foo.pas -M -o foo.d" doesn't give the primary source file nor the names of all interfaces imported, instead the '.d' file is always empty .... Any clues or hints ? Full information on all unit dependencies is crucial in the project I am working on (an IDE plugin for GPC). Regards, Adriaan van Os

5 15

range check test programs
by Francois Schoubben 12 Jul '03

12 Jul '03

For the main tests, i hope it's the end... Up to you to correct my tests... http://www.info.fundp.ac.be/~fsc/dvpt/fsc.tar.gz or, "online" http://www.info.fundp.ac.be/~fsc/dvpt/ fsc01-05 : array R/W fsc06-10 : packed array R/W fsc11 : array in a record (just one, i dont think it's usefull :) ) fsc12 : enum fsc13-14 : string (R/W) fsc15-16 : range write (integer and char) fsc 17-18 : functions and range fsc 19-25 : predefined functions (chr, fillchar, ...) fsc26-27 : conformant array R/W fsc28-30 : slice array fsc31-35 : actual schema discriminant fsc36-37 : "for loops", i'm not sure it's what you expect... For asm target, i have a problem... The only "assembler language" i know is MIX (thanks D. Knuth :-) )... And i haven't really got time to learn it before... long time i'm afraid... Can anybody help here??? For the remaining... What's missing? wrong? misunderstood? I've never played with delphi extensions, the OO language i used was java. And i'm teaching the very basics of programming so, i never used slice array and other schema discriminant before, it's possible i missed a lot of thing... Just explain me (or point me to a relatively short tutorial), i only ask to learn :) -- Francois Schoubben

3 7

ncurses
by Paul Davidson 11 Jul '03

11 Jul '03

Morning Have been trying to get CRT unit working with Terminal but received no success. The crtdemo.pas (http://www.gnu-pascal.de/demos/crtdemo.pas) example partially works. Colours, character sets and other parts do not. In code tests here, even a Write( c ) to screen does not always work. Are there DETAILED instructions on how to get this to work? Mac OS X 10.2.6 Thank you p davidson http://coraxnetworks.com

2 1

object bug report
by Russell Whitaker 10 Jul '03

10 Jul '03

Hi: Took the Chief's sample, added one line, calling file obj1.pas; then: gpc -o obj obj1.pas program obj1; type a = object procedure p; end; b = object (a) procedure p; virtual; end; procedure a.p; begin writeln ('a'); end; procedure b.p; begin writeln ('b'); end; var foo : a; bar : b; begin foo.p; bar.p; end. Got this: obj1.pas:10: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. Using this: Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/3.2.2/specs Configured with: ../gcc-3.2.2/configure --enable-languages=pascal : (reconfigured) ../gcc-3.2.2/configure --enable-languages=pascal : (reconfigured) ../gcc-3.2.2/configure --enable-languages=pascal Thread model: posix gpc version 20030209, based on gcc-3.2.2 Russ

6 39

gpc-20030507/gcc-3.2.3 test results
by J. David Bryan 09 Jul '03

09 Jul '03

The following test results were obtained with gpc version 20030507, based on gcc-3.2.3 (mingw special 20030504-1), configured for i486-pc-mingw32: ------------------ TEST agettext2test.pas: SKIPPED: libintl not installed TEST crttest.pas: SKIPPED: no curses library found TEST dialec3.pas: ./../units/dos.pas: In procedure `GetCBreak': ./../units/dos.pas:704: warning: suggest parentheses around `and' in operand of `<>' OK TEST dialec6.pas: ./../units/dos.pas: In procedure `GetCBreak': ./../units/dos.pas:704: warning: suggest parentheses around `and' in operand of `<>' OK TEST dostest.pas: gpc1.exe: warnings being treated as errors ./../units/dos.pas: In procedure `GetCBreak': ./../units/dos.pas:704: warning: suggest parentheses around `and' in operand of `<>' gpc1.exe: F:\Programming\GNU\root\usr\local\gpc-mingw\bin\gpc.exe exited with status 1 failed TEST dostest2.pas: gpc1.exe: warnings being treated as errors ./../units/dos.pas: In procedure `GetCBreak': ./../units/dos.pas:704: warning: suggest parentheses around `and' in operand of `<>' gpc1.exe: F:\Programming\GNU\root\usr\local\gpc-mingw\bin\gpc.exe exited with status 1 failed TEST environo.pas: SKIPPED: setenv not present in libc TEST fjf480a.pas: SKIPPED: librx not installed TEST fjf480b.pas: SKIPPED: librx not installed TEST fjf663.pas: SKIPPED: IOSelectRead not supported on this system TEST gettexttest.pas: SKIPPED: libintl not installed TEST gmptest.pas: SKIPPED: libgmp not installed TEST pipetes2.pas: Unexpected output `Unexpected output `Unexpected output `Unexpected output `Unexpected output [...] TEST pipetest.pas: SKIPPED: IOSelect not yet implemented for mingw TEST regextest.pas: SKIPPED: librx not installed TEST windtes2.pas: gpc1.exe: warnings being treated as errors ./../units/dos.pas: In procedure `GetCBreak': ./../units/dos.pas:704: warning: suggest parentheses around `and' in operand of `<>' gpc1.exe: F:\Programming\GNU\root\usr\local\gpc-mingw\bin\gpc.exe exited with status 1 gpc1.exe: F:\Programming\GNU\root\usr\local\gpc-mingw\bin\gpc.exe exited with status 1 failed TEST windtest.pas: gpc1.exe: warnings being treated as errors ./../units/dos.pas: In procedure `GetCBreak': ./../units/dos.pas:704: warning: suggest parentheses around `and' in operand of `<>' gpc1.exe: F:\Programming\GNU\root\usr\local\gpc-mingw\bin\gpc.exe exited with status 1 failed TEST y2k.pas: gpc1.exe: warnings being treated as errors ./../units/dos.pas: In procedure `GetCBreak': ./../units/dos.pas:704: warning: suggest parentheses around `and' in operand of `<>' gpc1.exe: F:\Programming\GNU\root\usr\local\gpc-mingw\bin\gpc.exe exited with status 1 failed # of GPC tests 3594 # of GPC tests passed 3576 # of GPC tests skipped 10 # of GPC tests failed 8 ------------------ Suppression of the warning suggesting parentheses or repair of the associated source file would eliminate 7 of the 8 failing tests (note that "dialec3.pas" and "dialec6.pas" report "OK" but apparently are counted as failing tests). The "pipetes2.pas" test outputs "`Unexpected output " repeatedly until 2048 characters are printed. I have trimmed the text for this report. To compile gpc using gcc-3.2.3, the change described by Russ Whitaker in his message of 7th June 2003 (to line 42 of p/config-lang.in) was needed. -- Dave

2 2

gpc20030507 with gcc-3.3 on Mac OS X
by Adriaan van Os 08 Jul '03

08 Jul '03

Peter N Lewis wrote, > #### > #### FDE 0x2aea4 (OB 0x13fd60, fde_end 0x2affc) has zero > length!Aborting. > #### > Abort Fixed with gcc-3.3. Geoff Keating wrote: > > Adriaan van Os writes: >> (4) compiling any .c source with -ggdb or -gdwarf-2 (instead of >> -gstabs or -g) produces the following output: >> Internal compiler error in default_no_named_section, at varasm.c:5305 > > Darwin doesn't really support dwarf2 at present. Fixed with gcc-3.3, there is now a message "unknown or unsupported -g option". Geoff Keating wrote: > > Adriaan van Os writes: > >> Does anyone know what the status is of the following problems, >> encountered with gcc-3.2.1/3.2.2 on Darwin/Mac OS X ? >> >> (1) trampolines crash (I have a patch to fix it) >> >> (2) longjumps crash (I have a patch to fix it also) >> >> (3) non-local goto's don't work, e.g. > > These are all fixed in GCC 3.3. Well, not quite. Longjump crashes and non-local goto crashes have been fixed, but trampoline crashes not. The gcc-3.2.x trampoline patch can be applied to gcc-3.3 and it fixes most trampoline crashes, but ..... ./test_run: line 193: 766 Segmentation fault "$DIFF" testmake.tmp "$xo" TEST fproc.pas: failed ... running the testuite for fproc.pas takes a long time and fails. After a while the hardddisk starts to spin continuously, which might indicate that the system is allocating lots virtual memory (on a 1.25 GB Mac). After this, gpc1 crashes when compiling ANY .pas file, until a reboot. The typical backtrace looks like this: Date/Time: 2003-05-18 03:11:07 +0200 OS Version: 10.2.4 (Build 6I32) Host: G4.local. Command: gpc1 PID: 27979 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0 Crashed: #0 0x0014ec68 in find_reloads (reload.c:4000) #1 0x0011bbe8 in reload_as_needed (reload1.c:3893) #2 0x00115388 in reload (reload1.c:1107) #3 0x001dca60 in global_alloc (global.c:583) #4 0x000991ec in rest_of_compilation (toplev.c:3304) #5 0x00007b58 in finish_routine (declarations.c:2436) #6 0x0002d27c in main_yyparse (parse.c:1739) #7 0x00097ce0 in compile_file (toplev.c:2134) #8 0x0009ce94 in do_compile (toplev.c:5370) #9 0x0009cf60 in toplev_main (toplev.c:5400) #10 0x00002700 in _start (crt.c:267) #11 0x00002580 in start Maybe, virtual memory is corrupt after the fproc.pas testrun ?? Running the testsuite for fproc.pas with --longjmp-all-nonlocal-labels, results in a compiler error message: TEST fproc.pas: /var/tmp//ccMu9pMb.s:unknown:Can't emit reloc {- symbol "LSJR11"} @ file address 800. /var/tmp//ccMu9pMb.s:unknown:Can't emit reloc {- symbol "LSJR11"} @ file address 796. /var/tmp//ccMu9pMb.s:unknown:Undefined local symbol L3$pb failed Regards, Adriaan van Os

3 8

Real with attributes (...)
by Mirsad Todorovac 08 Jul '03

08 Jul '03

Please read without prejudice! What would you think of the following: we all know about various bitsizes Integer and Cardinal types. What I've seen was a "customized" real type. Imagine you have to store lots of data for GSM-encoding, or some similar measurement purpose. Lots of bits are wasted, as they don't correspond to accurate digits of measurement. I.e. on a weather station that has only an occassional link to a satellite. For example, let's suppose we have lots of data that that we could express as reals in 16-bit precision, and all fit between -0.5 and 0.5 (for example, but standard can be defined in different way): type MyReal = Real attribute (Exponent = 0, Mantissa = 16); GSMReal = Real attribute (Exponent = 8, Mantissa = 8); The latter could represent a number with same range like IEEE single precision float, just with only 2 accurate digits. or even TEMPReal = Real attribute (ExponentRange = 0..15, Mantisa = 4); for keeping the temperature in one byte from range of 0.0625 K to 30720 K (where precision is not that much important as the value on the logarithmic scale ...) The compiler could use hardware floating point when it's faster than emulation with less bits of precision, then round/truncate when storing back into memory/variable. This is just a tip, not a real syntax or semantics proposal. Mirsad -- "I have a dream!" -- Martin Luther King Jr.

11 31

[Bug] Compiler error when accessing packed array element
by J. David Bryan 07 Jul '03

07 Jul '03

The following program: program bug; type r = packed record a : char; b : array [1..4] of char end; var v : r; i : integer; c : char; begin c := v.a; { line 13: succeeds } c := v.b [1]; { line 14: succeeds } c := v.b [i]; { line 15: fails } end. ...gives this improper compile-time error: bug.pas: In main program: bug.pas:15: cannot take address of packed record field `b' This is with gpc version 20030507, based on gcc-3.2.3 (mingw special 20030504-1), configured for i486-pc-mingw32. I also reproduced this with the Chief's gpc-20030507-gcc-3.2.3-i386-pc-mingw32.tar.gz. -- Dave

2 2

Round() problem (64-bit version)
by Cserzo Miklos 04 Jul '03

04 Jul '03

Hi Folks, the tests with the 64-bit version binaries are in progress. The following code demonstrates a bug related to the round() function: program bugtest; var i,j,k:integer; r:real; begin for i:= 1 to 100 do begin r:=random; j:=trunc(r*100); k:=round(r*100); writeln(j:4,k:4,r*100:4:0,r:8:4); end; end. In 32-bit the code generates the correct output but in 64-bit the value of "k" is always zero. The other columns of the result is correct. Any idea why, any suggestion for further tests? Cheers, miklos

2 1

Installation instructions
by Frank Heckenbach 02 Jul '03

02 Jul '03

The installation instructions in the manual are somewhat outdated (and have always been, at least for some years now). There are probably a number of things which are not quite accurate, missing or unnecessary (perhaps kludges that were once necessary). Also, the structure of the chapter is probably not optimal. Furthermore, there's information (partly overlapping, but also containing things not mentioned in the manual) that was once in the FAQ, but was taken out since it should be merged with the install instructions (because having two parallel, but not quite identical instructions would only add to the confusion). This merging hasn't been done, so the old FAQ information has rotted since then (probably all URLs in it are wrong now etc.), so it must be carefully updated and then merged with the install chapter. Obviously, I'm looking for people to do that. (I'm not going to, since my perspective, especially here, is a bit different from the average user's ...) Ideally, perhaps for each "essentially" different platform (i.e., DJGPP, Cygwin, Mingw, Mac OS, Unix and perhaps GNU/Linux as a special case of Unix where some things are easier, so it might be worth making it a separate section which doesn't confuse the user with details necessary for other Unices) one user should write one compact section. It should describe both compiling from sources and installing binaries. (Of course, this doesn't mean completely rewriting it -- the existing material can be used and rearranged, of course.) There should be some coordination (by one of them or someone else), so the sections will not look more different from each other than necessary, and common things need to be described only once. I'd like to not have to do this myself, but instead get the collected material from the coordinator in a new install.texi when it's ready. (I'm sending this mail to both gpc and gpc-doc, since it concerns the documentation, but also "regular" GPC users, and since the archives currently don't work, please reply to both lists. Once the volunteers have found, they can coordinate via gpc-doc only or private mail, of course ...) I've put the install chapter from the current sources as well as the old information from the FAQ at http://fjf.gnu.de/gpc-install.tar.gz Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

5 6

gdb
by Peter N Lewis 30 Jun '03

30 Jun '03

Hi, So what is the status of gdb? It seems to work with Pascal, but it does not seem to be able to display String()'s and I could not figure out how to use "call" to call CFShow (Apple says: call (void)CFShow(cf) but that just gives a syntax error). (CFShow is a debugging routine that prints out the decoded value of the input parameter). And print S gives: $1 = (&$$1 = record ) @$bffff7c0: <incomplete type> Thanks, Peter. -- <http://www.interarchy.com/> <http://documentation.interarchy.com/>

3 3

Archives working again
by Frank Heckenbach 29 Jun '03

29 Jun '03

The archives of this mailing list and the (experimental) search function on the GPC site <http://www.gnu-pascal.de/search.html> should now be working again. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

Archives working again
by Frank Heckenbach 29 Jun '03

29 Jun '03

The archives of this mailing list and the (experimental) search function on the GPC site <http://www.gnu-pascal.de/search.html> should now be working again. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

Re: Compile error during bootstrap
by Frank Heckenbach 28 Jun '03

28 Jun '03

Peter N Lewis wrote: > I downloaded the GPC build from Adriaan, applied [...] > gpc.diff-gale1 > > and did a configure, make bootstrap and got the following error: > > /Users/peter/unix/gpc/gpc-3.3d6-sources/gpc-20030507/gcc/p/rts/filename.pas:159: > error: cannot evaluate this expression from a global declaration > /Users/peter/unix/gpc/gpc-3.3d6-sources/gpc-20030507/gcc/p/rts/filename.pas:159: > error: cannot call routine from a global declaration > make[3]: *** [filename.o] Error 1 > make[2]: *** [pascal.rts] Error 2 > make[1]: *** [stage2_build] Error 2 > make: *** [bootstrap] Error 2 Oh yeah, this "set different in a constant" problem again, in another form. Until we can fix it better, just undo the changes in expressions.c and declarations.c in the gale1 patch. (They would be useful checks, but are too aggressive here, and leaving them out shouldn't make things worse than they were before, and the actual fix for gale1.pas still works.) Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

4 3

Segmentation fault with GPC/GCC 3.3
by Andreas Jaeger 26 Jun '03

26 Jun '03

Trying to bootstrap gpc-20030507.tar.gz with GCC 3.3 (actually the gcc-3.3-hammer-branch but that shouldn't make a difference here) on an AMD64 system, the bootstrap fails with: $ ../.././xgpc -B../.././ -c -g -I. -W -Wall -Wpointer-ar ith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/usr/src/aj/cvs/gcc-hammer-pascal/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /usr/src/aj/cvs/gcc-hammer-pascal/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.3-hammer'" /usr/src/aj/cvs/gcc-hammer-pascal/gcc/p/rts/rtsc.pas -v -save-temps Reading specs from ../.././specs Configured with: /usr/src/aj/cvs/gcc-hammer-pascal/configure --prefix=/opt/gcc/3.3-pascal --disable-nls --enable-threads=posix --enable-clocale=gnu --enable-__cxa_atexit --enable-shared --enable-languages=c,c++,f77,objc,ada,treelang,java,f77,pascal --with-system-zlib x86_64-suse-linux-gnu Thread model: posix gpc version 20030507, based on gcc-3.3-hammer ../.././gpcpp -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -quiet -v -I. -iprefix ../.././../lib/gcc-lib/x86_64-suse-linux-gnu/3.3-hammer/ -isystem ../.././include -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -DRTS_RELEASE_STRING='20030507' -DGCC_VERSION='3.3-hammer' /usr/src/aj/cvs/gcc-hammer-pascal/gcc/p/rts/rtsc.pas -funit-path=/usr/src/aj/cvs/gcc-hammer-pascal/gcc/p/rts -fautomake -famtmpfile=/tmp/cc6ax0Gt.gpa -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations rtsc.i GNU Pascal Compiler PreProcessor version 20030507, based on gcc-3.3-hammer (x86-64 Linux/ELF) {$include "..."} search starts here: {$include <...>} search starts here: . End of search list. ../.././gpc1 rtsc.i -quiet -dumpbase rtsc.pas -auxbase rtsc -g -g -O2 -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -version -funit-path=/usr/src/aj/cvs/gcc-hammer-pascal/gcc/p/rts -fautomake -famtmpfile=/tmp/cc6ax0Gt.gpa -o rtsc.s GNU Pascal version is actually 20030507, based on gcc-3.3-hammer GNU Pascal version 3.3-hammer (x86_64-suse-linux-gnu) compiled by GNU C version 3.3-hammer. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 <implicit code>: In procedure `RunFinalizers': <implicit code>:14: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. Running gdb shows the following backtrace: Starting program: /abuild/aj/builds/gcc/misc/gcc/gpc1 rtsc.i -quiet -dumpbase rtsc.pas -auxbase rtsc -g -g -O2 -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -version -funit-path=/usr/src/aj/cvs/gcc-hammer-pascal/gcc/p/rts -o rtsc.s GNU Pascal version is actually 20030507, based on gcc-3.3-hammer GNU Pascal version 3.3-hammer (x86_64-suse-linux-gnu) compiled by GNU C version 3.3-hammer. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Program received signal SIGSEGV, Segmentation fault. 0x0000002a956db314 in free () from /lib64/libc.so.6 (gdb) bt #0 0x0000002a956db314 in free () from /lib64/libc.so.6 #1 0x00000000004025e9 in poplevel (keep=0, reverse=0, routinebody=0) at /usr/src/aj/cvs/gcc-hammer-pascal/gcc/p/declarations.c:407 #2 0x0000000000427b99 in main_yyparse () at parse.y:2838 #3 0x0000000000494bf2 in compile_file () at /usr/src/aj/cvs/gcc-hammer-pascal/gcc/toplev.c:2185 #4 0x00000000004999fb in do_compile () at /usr/src/aj/cvs/gcc-hammer-pascal/gcc/toplev.c:5558 #5 0x0000000000499a6a in toplev_main (argc=-1789304384, argv=0x0) at /usr/src/aj/cvs/gcc-hammer-pascal/gcc/toplev.c:5588 #6 0x0000002a9568d017 in __libc_start_main () from /lib64/libc.so.6 #7 0x000000000040221a in _start () (gdb) up #1 0x00000000004025e9 in poplevel (keep=0, reverse=0, routinebody=0) at /usr/src/aj/cvs/gcc-hammer-pascal/gcc/p/declarations.c:407 407 free (level); (gdb) b poplevel Breakpoint 2 at 0x4024a0: file /usr/src/aj/cvs/gcc-hammer-pascal/gcc/p/declarations.c, line 316. (gdb) r The program being debugged has been started already. Start it from the beginning? (y or n) y Keeping /abuild/aj/builds/gcc/misc/gcc/gpc1... Removing /lib64/libc.so.6... Removing /lib64/ld-linux-x86-64.so.2... Starting program: /abuild/aj/builds/gcc/misc/gcc/gpc1 rtsc.i -quiet -dumpbase rtsc.pas -auxbase rtsc -g -g -O2 -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -version -funit-path=/usr/src/aj/cvs/gcc-hammer-pascal/gcc/p/rts -o rtsc.s GNU Pascal version is actually 20030507, based on gcc-3.3-hammer GNU Pascal version 3.3-hammer (x86_64-suse-linux-gnu) compiled by GNU C version 3.3-hammer. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Breakpoint 2, poplevel (keep=-1073747992, reverse=778, routinebody=482) at /usr/src/aj/cvs/gcc-hammer-pascal/gcc/p/declarations.c:316 316 { (gdb) n 320 check_forward_decls (1); (gdb) 316 { (gdb) 319 struct binding_level *level = current_binding_level; (gdb) 320 check_forward_decls (1); (gdb) p level $2 = (struct binding_level *) 0x2a955961c0 (gdb) n 321 current_binding_level = current_binding_level->level_chain; (gdb) 326 if (reverse) (gdb) 325 decls = level->names; (gdb) 321 current_binding_level = current_binding_level->level_chain; (gdb) 326 if (reverse) (gdb) 327 decls = nreverse (decls); (gdb) 330 for (t = decls; t; t = TREE_CHAIN (t)) (gdb) 367 restore_identifiers (level->shadowed); (gdb) 371 if (level->this_block) (gdb) 376 block = NULL_TREE; (gdb) 377 if (block) (gdb) 389 for (t = level->blocks; t; t = TREE_CHAIN (t)) (gdb) 392 if (routinebody) (gdb) bt #0 poplevel (keep=0, reverse=0, routinebody=0) at /usr/src/aj/cvs/gcc-hammer-pascal/gcc/p/declarations.c:392 #1 0x0000000000427b99 in main_yyparse () at parse.y:2838 #2 0x0000000000494bf2 in compile_file () at /usr/src/aj/cvs/gcc-hammer-pascal/gcc/toplev.c:2185 #3 0x00000000004999fb in do_compile () at /usr/src/aj/cvs/gcc-hammer-pascal/gcc/toplev.c:5558 #4 0x0000000000499a6a in toplev_main (argc=-1789304384, argv=0x0) at /usr/src/aj/cvs/gcc-hammer-pascal/gcc/toplev.c:5588 #5 0x0000002a9568d017 in __libc_start_main () from /lib64/libc.so.6 #6 0x000000000040221a in _start () (gdb) n 394 else if (block) (gdb) 402 else if (level->blocks) (gdb) 404 if (block) (gdb) 407 free (level); the problem is here that the address of level is wrong, it seems to be in the address space of the dynamic linker. Any ideas or fixes for this problem? Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.inka.de http://www.suse.de/~aj

8 33

Qt libraries
by Silvio a Beccara 25 Jun '03

25 Jun '03

Hello, would it be possible to develop applications for KDE using the Qt 3.0/3.1 libraries, as it is commonly done with C++? Would it be difficult, or are there structural difficulties? Thanks a lot Silvio

2 1

Server upgrade
by Frank Heckenbach 23 Jun '03

23 Jun '03

Due to a hardware upgrade, the GPC server will be out of service tomorrow (Friday) probably for an hour. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

6 13

Re: Server upgrade
by Eike Lange 23 Jun '03

23 Jun '03

On Sat, Jun 21, 2003 at 12:09:49PM +0200, Mirsad Todorovac wrote: > There is an option in httpd.conf ... I think it's named AddDefaultCharset. Yes, I see. Now it really works. (never mentioned this option before) Eike

2 1

Re: Server upgrade, bad news
by Frank Heckenbach 22 Jun '03

22 Jun '03

The problems on the server seem to be bigger than thought before. Don't expect anything to work until further notice. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

World's worst Pascal progammer
by Paul Davidson 20 Jun '03

20 Jun '03

Morning Looking for thread units for Gnu Pascal. Do any exits? (Next on wish list are: ncurses that actually works on Mac OS X and some MySQL units as well). thank you http://coraxnetworks.com/Snaps

4 3

GPC preformance kludge with local initialized arrays
by Mirsad Todorovac 19 Jun '03

19 Jun '03

Note the following lsiting, and resulting assembly code (i686, Linux): You might think that the function is very optimized, since it requires only two comparisons and a lookup in table per character checked? Alas, GPC does a proper call to the real memcpy() function of complete ``v'' array on each call of function DigitValue() !!! This makes the run twice as slow as when ``v'' array is made global (edited): ----------------------------------------------------- make test arr a=8 116.290u 0.400s 1:59.62 97.5% 0+0k 0+0io 10385pf+0w time a.out arr a=8 114.190u 0.280s 1:58.53 96.5% 0+0k 0+0io 120pf+0w 114.500u 0.210s 2:03.95 92.5% 0+0k 0+0io 120pf+0w 114.650u 0.040s 1:57.13 97.9% 0+0k 0+0io 121pf+0w 114.840u 0.020s 1:57.00 98.1% 0+0k 0+0io 120pf+0w 115.180u 0.040s 2:05.03 92.1% 0+0k 0+0io 120pf+0w 106.200u 1.390s 2:07.25 84.5% 0+0k 0+0io 120pf+0w 111.700u 0.080s 2:04.02 90.1% 0+0k 0+0io 120pf+0w make test arr a=8 glob 65.840u 0.160s 1:07.62 97.6% 0+0k 0+0io 10385pf+0w time a.out arr a=8 glob 63.610u 0.060s 1:06.63 95.5% 0+0k 0+0io 120pf+0w 63.710u 0.030s 1:05.21 97.7% 0+0k 0+0io 120pf+0w 63.620u 0.040s 1:06.02 96.4% 0+0k 0+0io 120pf+0w 63.610u 0.030s 1:05.41 97.2% 0+0k 0+0io 120pf+0w 63.840u 0.000s 1:05.15 97.9% 0+0k 0+0io 120pf+0w 63.980u 0.010s 1:05.29 98.0% 0+0k 0+0io 120pf+0w 64.000u 0.020s 1:05.19 98.2% 0+0k 0+0io 120pf+0w ----------------------------------------------------- Just FYI, making ``v'' array [0..255] of Integer (for aligned access) made it even 10s slower (probably problems with FSB and cache), instead of what is commonly said, and complete code is not a bit faster from this variant: function DigitValue (Dig: Char): Integer; attribute (inline, const); var d : Integer; attribute (register); begin if (Dig >= '0') and (Dig <= '9' ) then DigitValue := Ord (Dig) - Ord ('0') else if (Dig >= 'a') and (Dig <= 'z') then DigitValue := Ord (Dig) - Ord ('a') + 10 else if (Dig >= 'A') and (Dig <= 'Z') then DigitValue := Ord (Dig) - Ord ('A') + 10 else DigitValue := -1 end; ... even though this code has six branches. Is it the GNU Pascal problem or the back-end problem? NOTE: even attribute (const) after initialization of the array didn't help to evade memcpy(). Mirsad isvalidnumberbase.pas: ---------------------------------------------------------------------------- program isvalidnum (output); var i, Base: Integer; OK : Boolean; function IsValidNumberBase2 (s: String; Base: Integer): Boolean; attribute(const); var i, dv : Integer; attribute (register); b : Byte; attribute (register); function DigitValue (Dig: Char): Integer; {attribute (inline, const);} var d : Integer; attribute (register); {$if 0} {$if Low (Char) < 0} {$error "this won't work: negative Char used as index} {$endif} {$endif} v : array [0..255] of ByteInt = ( -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, -1, -1, -1, -1, -1, -1, -1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, -1, -1, -1, -1, -1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 ); begin if (Dig >= '0') and (Dig <= 'z') then DigitValue := v[Ord (Dig)] else DigitValue := -1; end; begin b := Base; Assert ((b >= 2) and (b <= 36), 'base out of range (2..36)'); i := 1; if s[i] = '-' then Inc (i); for i := i to Length (s) do {$define VERSION1} {$ifdef VERSION1} begin dv := DigitValue (s[i]); if (dv < 0) or (dv >= b) then Return False end; {$else} if not (DigitValue (s[i]) in [0 .. b-1]) then Return False; {$endif} Return True; end; begin { main } OK := IsValidNumberBase2 ('010101010101101010101', 2) and not IsValidNumberBase2 ('0101010210101101010101', 2) and IsValidNumberBase2 ('0121012210101101010101', 3); if OK then WriteLn ('OK'); end. ------------------------------------------------------------------------- isvalidnumberbase.s (edited): ------------------------------------------------------------------------- .file "isvalidnumberbase.pas" .local I .comm I,4,4 .local Base .comm Base,4,4 .local Ok .comm Ok,1,1 .section .rodata .LC0: .byte -1 . . . .byte -1 .byte -1 .byte -1 .byte 0 .byte 1 .byte 2 .byte 3 .byte 4 .byte 5 .byte 6 .byte 7 .byte 8 .byte 9 .byte -1 .byte -1 .byte -1 .byte -1 .byte -1 .byte -1 .byte -1 .byte 10 .byte 11 .byte 12 .byte 13 .byte 14 .byte 15 .byte 16 .byte 17 .byte 18 .byte 19 .byte 20 .byte 21 .byte 22 .byte 23 .byte 24 .byte 25 .byte 26 .byte 27 .byte 28 .byte 29 .byte 30 .byte 31 .byte 32 .byte 33 .byte 34 .byte 35 .byte 36 .byte -1 .byte -1 .byte -1 .byte -1 .byte -1 .byte 10 .byte 11 .byte 12 .byte 13 .byte 14 .byte 15 .byte 16 .byte 17 .byte 18 .byte 19 .byte 20 .byte 21 .byte 22 .byte 23 .byte 24 .byte 25 .byte 26 .byte 27 .byte 28 .byte 29 .byte 30 .byte 31 .byte 32 .byte 33 .byte 34 .byte 35 .byte 36 .byte -1 .byte -1 . . . .byte -1 .byte -1 .byte -1 .byte -1 .text .p2align 4,,15 .type Digitvalue.0,@function Digitvalue.0: pushl %ebp movl %esp, %ebp subl $296, %esp movl %ebx, -4(%ebp) leal -280(%ebp), %eax movzbl 8(%ebp), %ebx movl %ecx, -12(%ebp) movl $256, 8(%esp) movl $.LC0, 4(%esp) movl %eax, (%esp) call memcpy cmpb $47, %bl jbe .L4 cmpb $122, %bl ja .L4 movzbl %bl, %eax movsbl -280(%eax,%ebp),%eax .L5: movl -4(%ebp), %ebx movl %ebp, %esp popl %ebp ret .p2align 4,,7 .L4: movl $-1, %eax jmp .L5 .Lfe1: .size Digitvalue.0,.Lfe1-Digitvalue.0 .section .rodata.str1.1,"aMS",@progbits,1 .LC1: .string "base out of range (2..36)" .text .p2align 4,,15 .globl Isvalidnumberbase2 .type Isvalidnumberbase2,@function Isvalidnumberbase2: pushl %ebp movl %esp, %ebp pushl %edi pushl %esi pushl %ebx subl $92, %esp movl 8(%ebp), %edi movzbl 12(%ebp), %eax cmpb $1, %al seta %bl movb %al, -73(%ebp) testb %bl, %bl je .L6 cmpb $36, %al setbe %bl .L6: movl $25, -72(%ebp) leal -64(%ebp), %eax movl $25, 8(%esp) movl $.LC1, 4(%esp) movl %eax, (%esp) call memcpy leal -72(%ebp), %eax movl %eax, 4(%esp) movzbl %bl, %eax movl $1, %ebx movl $25, -68(%ebp) movl %eax, (%esp) call _p_Assert cmpb $45, 8(%edi) je .L18 .L8: movl 4(%edi), %esi cmpl %esi, %ebx jg .L9 movb $0, -74(%ebp) .p2align 4,,15 .L10: cmpb $0, -74(%ebp) je .L12 cmpl %esi, %ebx je .L9 incl %ebx .L12: movb $1, -74(%ebp) leal -24(%ebp), %ecx movzbl 7(%edi,%ebx), %eax movl %eax, (%esp) call Digitvalue.0 movl %eax, %ecx shrl $31, %ecx testb %cl, %cl movl %eax, %edx jne .L17 movzbl -73(%ebp), %eax cmpl %eax, %edx jl .L14 testl %edx, %edx js .L14 movb $1, %cl .L14: testb %cl, %cl je .L10 .L17: xorl %eax, %eax .L1: addl $92, %esp popl %ebx popl %esi popl %edi popl %ebp ret .p2align 4,,7 .L9: movb $1, %al jmp .L1 .L18: movl $2, %ebx jmp .L8 .Lfe2: .size Isvalidnumberbase2,.Lfe2-Isvalidnumberbase2 .section .rodata.str1.1 .LC2: .string "010101010101101010101" .LC5: .string "OK" .LC4: .string "0121012210101101010101" .LC3: .string "0101010210101101010101" .text .p2align 4,,15 .globl pascal_main_program .type pascal_main_program,@function pascal_main_program: pushl %ebp movl %esp, %ebp subl $136, %esp movl $21, 8(%esp) leal -32(%ebp), %eax movl $21, -40(%ebp) movl $.LC2, 4(%esp) movl %eax, (%esp) call memcpy leal -40(%ebp), %eax movl $21, -36(%ebp) movl $2, 4(%esp) movl %eax, (%esp) call Isvalidnumberbase2 testb %al, %al jne .L28 .L21: testb %al, %al jne .L29 .L23: movb %al, Ok testb %al, %al jne .L30 .L19: movl %ebp, %esp popl %ebp ret .p2align 4,,7 .L30: movl $22, 24(%esp) movl $2, 20(%esp) movl $.LC5, 16(%esp) movl $17, 12(%esp) movl $2, 8(%esp) movl $784, 4(%esp) movl $_p_Output, (%esp) call _p_Internal_Write movl _p_InOutRes, %eax testl %eax, %eax je .L19 jmp .L31 .p2align 4,,7 .L29: movl $22, -104(%ebp) leal -96(%ebp), %eax movl $22, 8(%esp) movl $.LC4, 4(%esp) movl %eax, (%esp) call memcpy leal -104(%ebp), %eax movl $22, -100(%ebp) movl $3, 4(%esp) movl %eax, (%esp) call Isvalidnumberbase2 jmp .L23 .p2align 4,,7 .L28: movl $22, -72(%ebp) leal -64(%ebp), %eax movl $22, 8(%esp) movl $.LC3, 4(%esp) movl %eax, (%esp) call memcpy leal -72(%ebp), %eax movl $22, -68(%ebp) movl $2, 4(%esp) movl %eax, (%esp) call Isvalidnumberbase2 testb %al, %al sete %al jmp .L21 .L31: call _p_CheckInOutRes .Lfe3: .size pascal_main_program,.Lfe3-pascal_main_program .data .type ctor_run_condition_14.1,@object .size ctor_run_condition_14.1,1 ctor_run_condition_14.1: .byte 0 .text .p2align 4,,15 .globl init_pascal_main_program .type init_pascal_main_program,@function init_pascal_main_program: cmpb $0, ctor_run_condition_14.1 pushl %ebp movl %esp, %ebp je .L34 popl %ebp ret .p2align 4,,7 .L34: popl %ebp movb $1, ctor_run_condition_14.1 jmp _p_DoInitProc .Lfe4: .size init_pascal_main_program,.Lfe4-init_pascal_main_program .p2align 4,,15 .globl main .type main,@function main: pushl %ebp movl %esp, %ebp subl $24, %esp movl __GPC_RTS_VERSION_20030507__, %eax movl 16(%ebp), %eax andl $-16, %esp movl %eax, 8(%esp) movl 12(%ebp), %eax movl %eax, 4(%esp) movl 8(%ebp), %eax movl %eax, (%esp) call _p_initialize call init_pascal_main_program call pascal_main_program call _p_finalize movl %ebp, %esp xorl %eax, %eax popl %ebp ret .Lfe5: .size main,.Lfe5-main .ident "GCC: (GNU) 3.2.1" -------------------------------------------------------------------------------

4 16

Web site search
by Frank Heckenbach 15 Jun '03

15 Jun '03

I'm installing a search function for the GPC web site (using ht://dig). Currently, you can try it at http://www.gnu-pascal.de/search.html (In the future the search form will be added to the regular pages.) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

Re: Segmentation Fault With Gpc/Gcc 3.3
by Waldek Hebisch 13 Jun '03

13 Jun '03

> Perhaps we should pass sets smaller than 16bytes in registers, like all > other structures are... > > > Pascal patches the backend (stor-layout.c) to get this. More precisely > > `stor-layout.c' contains the following (at line 1813): > > > > if (rounded_size > (int) alignment) > > TYPE_MODE (type) = BLKmode; > > else > > TYPE_MODE (type) = mode_for_size (alignment, MODE_INT, 1); > > > > Pascal makes alignment equal to size of long. By default alignment is > > BITS_PER_WORD. I do not know what other front ends are doing, but > > safe way is to expect any integer mode. > > I see, this can be problem for passing 128bit sets in register, but I > guess if we classify it using x86_64_INTEGER_CLASS it will just work > (get casted via PARALLEL) > > Honza The following snippet appearently works for Pascal and should be relatively safe for other front ends: else if (TREE_CODE (type) == SET_TYPE) { if (bytes <= 4) { classes[0] = X86_64_INTEGERSI_CLASS; return 1; } else if (bytes <= 8) { classes[0] = X86_64_INTEGER_CLASS; return 1; } else if (bytes <= 12) { classes[0] = X86_64_INTEGER_CLASS; classes[1] = X86_64_INTEGERSI_CLASS; return 2; } else { classes[0] = X86_64_INTEGER_CLASS; classes[1] = X86_64_INTEGER_CLASS; return 2; } -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

BPReal must be a packed record
by David Ulbrich 12 Jun '03

12 Jun '03

in unit system, the BPReal type must be changed to a packed record (at least if the target is not a i686). We're using GPC with GCC-crosscompiler for embedded ARM CPU's (4 byte alignment). Without 'packed', mapping of existing BP-created data structures containing this 6 byte 'real' type does not work. David

2 1

Seeking advice for function return
by Mirsad Todorovac 11 Jun '03

11 Jun '03

There is a conversion function, which accepts "Width" up to which the returned value should be zero-extended as additional parameter. I was wondering, what would you expect from a library or unit function to do when this Width can't be satisfied withing given TString result value: 1. silently truncate (simply return the converted number as TString of maximum possible length, for the truncated zeros do not make a change in numerical value assigned ot return string.) 2. return '' (empty string), which can be checked and detected by caller 3. truncate with some sort of warning, for suspiciously high Width silently truncated can hide a bug in program that will crash sometimes later something else less detectable a) do it once per program run (i.e. like compiler that reports some conditions only once per function) b) report it with each call to function in either case this warning might occur in test runs, indicating error or bug in calling program 4. raise RuntimeWarning() { deprecated by Frank } 5. raise RuntimeError() to abort the program What is the behavior you'd prefer for such a library function? Example of the function might be: Integer2StringWidth (i: Integer; Width: Integer): TString; So, for example, if High(TString) = 2048, and the code is: WriteLn (Integer2StringWidth (i, 2200)); what should be done? (NOTE: this is not the actual function, but a meaningless, but simpler example.) Thank you, Mirsad

3 2

Re: Segmentation Fault With Gpc/Gcc 3.3
by Frank Heckenbach 11 Jun '03

11 Jun '03

Jan Hubicka wrote: > > Frank Heckenbach <Frank(a)G-N-U.De> Writes: > > > > > Andreas Jaeger Wrote: > > > > > >> One More Thing That Does Not Seems To Work Are Profile Driven > > >> Optimizations. Are You Supporting -Profile-Arcs And > > >> -Fbranch-Probabilities? > > > > > > We Don't Do Anything Special About Them. Is This Required, I.E., > > > Aren't They Handled By The Backend? > > > > Honza, can you explain what needs to be done? > > > > AFAIK you do not initialize some fields correctly but Honza knows > > more... > > It may well be also problem present on hammer branch only. The problem > is that profile code uses trees to expand data structures passed to GCC > runtime. The language frontend needs to initialize all the types that > gcov code expects to be on the place. > Recently I moved gcov from c type nodes into it's own nodes to avoid > problems with fortran frontend not initializing things like > unsigned_long_node but with pascal frontend it still seem to be > crashing. I didn't investigated what exactly is missing. We call build_common_tree_nodes which initializes long_unsigned_type_node etc. If anything more is needed, it shouldn't be difficult to add it. I'd only have to know what. Is this documented anywhere? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

64 bit code generation
by Cserzo Miklos 11 Jun '03

11 Jun '03

Hi Folks, I need 64-bit code on Sun Solaris 2.9. The specification of the system (gpc -v): Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2.1/specs Configured with: /users/cserzo/big/src/gcc-3.2.1/configure --enable-languages=pascal --disable-nls --with-gnu-as --with-gnu-ld --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld Thread model: posix gpc version 20030507, based on gcc-3.2.1 Apparently, the 32-bit compiler should be able to generate 64-bit code. The problem is the missing 64-bit libgpc. The 64-bit version of the gcc library is there but its gpc counterpart not. How could I force the compilation of this library at build time? I made another test. With the 32-bit version one should be able to address ~ 4.3 Gb of the memory. In practice, I can allocate about 2Gb (array[1..500000000] of integer) but not much more. If I compile a code containing array[1..600000000] of integer the following error generated: /var/tmp//ccrvtgAm.s: Assembler messages: /var/tmp//ccrvtgAm.s:7: Error: .COMMon length (-1894967300.) <0! Ignored. /var/tmp//ccrvtgAm.s:7: Warning: rest of line ignored; first ignored character is `,' What is the correct way to make use of the memory in this case? Cheers, miklos

5 17

Regression with array inside packed record
by Waldek Hebisch 10 Jun '03

10 Jun '03

The following program used to work: PROGRAM FOO; CONST IDLNGTH = 12; TYPE ALPHA = ARRAY [1..IDLNGTH] OF CHAR; IDENTIFIER = PACKED RECORD NAME: ALPHA; END; VAR FILID : IDENTIFIER ; I, J : INTEGER; BEGIN J := 0 ; FOR I := 1 TO IDLNGTH DO J := J + ORD(FILID.NAME[I]) ; WRITELN('OK') END . With gpc-20030507 I get the following: bash-2.04$ gpc -v -B/mnt/a9/pom/kompi/gcc3/gpc-3.2.2/gcc name4.p Reading specs from /mnt/a9/pom/kompi/gcc3/gpc-3.2.2/gcc/specs Configured with: ../gcc-3.3/configure --enable-checking Thread model: posix gpc driver version 20030507, based on gcc-3.3, executing gpc version 3.2.2 /mnt/a9/pom/kompi/gcc3/gpc-3.2.2/gcc/gpcpp -D__BITS_LITTLE_ENDIAN__=1 -D__BYTES_LITTLE_ENDIAN__=1 -D__WORDS_LITTLE_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -v -isystem /mnt/a9/pom/kompi/gcc3/gpc-3.2.2/gcc/include -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=2 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ name4.p -famtmpfile=/tmp/ccZIDfUy.gpa /tmp/ccKpUnOZ.i GNU Pascal Compiler PreProcessor version 20030507, based on gcc-3.2.2 (i386 Linux/ELF) /mnt/a9/pom/kompi/gcc3/gpc-3.2.2/gcc/gpc1 /tmp/ccKpUnOZ.i -quiet -dumpbase name4.p -version -famtmpfile=/tmp/ccZIDfUy.gpa -o /tmp/ccXcnQqq.s GNU Pascal version is actually 20030507, based on gcc-3.2.2 GNU Pascal version 3.2.2 (i686-pc-linux-gnu) compiled by GNU C version 3.3. name4.p: In main program: name4.p:15: cannot take address of packed record field `NAME' -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

2 2

Preprocessor question
by Mirsad Todorovac 09 Jun '03

09 Jun '03

Hi, everybody! How could I make this preprocessor check work? domac:~/pascal/gcc-3.2.1/gcc/p/test> time make MASK='mtm017.pas' pascal.check-long 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 { gpc --version | head -1; gpc --print-search-dirs | grep install | head -1; hostname || echo "unknown host"; date "+%Y-%m-%d %H:%M:%S"; } | \ sed -e 's,^,Testing ,;N;s,\n.*gcc-lib[/\], (,;s,[/\].*,),;N;s,\n, (,;s,$,),;N;s/\n/, /' Testing gpc 20030507, based on gcc-3.2.1 (i686-pc-linux-gnu) (domac), 2003-06-07 15:36:13 echo "gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused " gpc -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused PC="gpc" PFLAGS="--autobuild -g -O3 -W -Wall -Wundef -Wpointer-arith -Wno-unused " SRCDIR="." TEST_MAKE_FLAG=test-make-flag "./test_run" mtm017.pas | tee test_log GPC-TEST-BEGIN ========================== TEST mtm017.pas: ./mtm017.pas:23: conditional expression: `Low' is not defined ./mtm017.pas:23: conditional expression: trailing garbage failed --------------------------------------------------------------------------------- function IsValidNumberBase2 (s: String; Base: Integer): Boolean; attribute(const); var i, dv : Integer; attribute (register); b : Byte; attribute (register); function DigitValue (Dig: Char): Integer; attribute (inline, const); var d : Integer; attribute (register); {$if Low (Char) < 0} {$error "this won't work: negative Char used as index} {$endif} v : array [0..255] of Integer = ( -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, -1, -1, -1, -1, -1, -1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, -1, -1, -1, -1, -1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 ); begin DigitValue := v[Dig]; end; ... Thanks, Mirsad -- "I have a dream!" -- Martin Luther King Jr.

3 6

Mac OS X download
by Adriaan van Os 08 Jun '03

08 Jun '03

Updated compiler sources and binaries, as well as updated Apple PInterfaces for GPC can be downloaded from <www.microbizz.nl/gpc.html>. Regards, Adriaan van Os

1 0

gpc-20030507 released
by Frank Heckenbach 07 Jun '03

07 Jun '03

I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/ The major incompatibility, compared to the previous release is that types liks `Integer (16)' have to be changed to `Integer attribute (Size = 16)' (as discussed recently). New features: * `Integer (16)' etc. changed to `Integer attribute (Size = 16)' (works for integer and Boolean types) (fjf861.pas) (@) * types can have attributes (note: no preceding `;') (fjf860*.pas) * object methods can have attributes (fjf826*.pas) * new attributes `iocritical' (fjf824*.pas), `ignorable' (fjf839*.pas) for routines * field names and array indices in initalizers are recognized (waldek5*.pas) (options `-W[no-]field-name-problem' removed, @) * object directives `published', `public' (both equivalent), `protected' (scope limited to object type and derived object types), `private' (scope limited to current unit/module) (fjf864*.pas) (options `-W[no-]object-directives' removed, @) * new options `-W[no-]parentheses' (fjf848*.pas) * new type `AnyFile' for parameters and pointer targets (fjf821*.pas) * Mac Pascal specific features are supported according to the dialect options (M) * GPC doesn't use `gpm' files anymore (instead, each module has an implicit `MODULENAME-all.gpi' interface which is a regular `gpi' file) * trimming string relations as functions (`EQPad' etc.) (fjf873.pas) * new options `-W[no-]interface-file-name' * `SeekEOF' and `SeekEOLn' use `Input' implicitly when no file is given (fjf871.pas) (B) * tagging for `with' statements (Sun Pascal) (tom6.pas) * new option `--sun-pascal' * the operator precedence and associativity of `+' and `-' is now as defined in EP by default (and as in BP with `--borland-pascal') <Pine.LNX.4.44.0210251249500.6181-100000(a)duch.mimuw.edu.pl> (fjf863*.pas) (@) * dynamic object methods (fjf859.pas) (B) * in `--borland-pascal' mode, `Assign' unconditionally (re-)initializes its file parameter (fjf858.pas) * make the program/module/unit finalizers non-public (`static' in C sense), omit them if easily possible * non-`interface' modules with empty implementation part (pmod1.pas, fjf843.pas) * `maximum-field-alignment' and `[no-]field-widths' work as local compiler directives now (fjf842.pas) * dropped `{$debug-statement}' (should not be necessary anymore, now that debug info mostly works) * new options `--[no-]longjmp-all-nonlocal-labels' * dropped computed `goto' (never worked for nonlocal `goto' into the main program, implementing it would be quite difficult, probably not worth it) (@) * `TimeStamp' is now a packed record (E) * `--interface-only' does not require `-S' or `-c' anymore (and does not create an object file) Fixed bugs: * some functions in boolean shortcuts are always called (fjf226*.pas) * possible stack overflow when using string concatenation in a loop (fjf419*.pas, fjf345e.pas, fjf460b.pas) - breaks berend3.pas (less important because strange test case, and just another instance of existing contourbug.pas) * declarations of a module interface are not visible in the implementation (kevin13.pas, mod12.pas) <Pine.BSI.3.96.971110210330.7570A-100000(a)malasada.lava.net> * check parameter and result variable names in repeated forward etc. declarations <20010321204051.A611@plato> (fjf284.pas, markus8.pas, fjf850*.pas) * initialized object variables don't work (fjf445*.pas) * the parser does not always recover well after a parse error <199911040915.KAA11168(a)humulus.daimi.au.dk> (fixed the case given in this report; if there are other cases, please report) * packed array/record fields don't work in `Read' etc. (tom5.pas) * file parameters must not automatically be bindable in `--extended-pascal' (fjf193[c-e].pas) * give an error rather than a warning when casting between types of different size in `{$X-}' * simplify code generated to compute size of dynamical variables if no bitfields are involved (ok with gcc-3) * detect invalid array slice access with constant indices at compile-time (peter2*.pas) * automatically close dynamically allocated files on `Dispose' and files declared in a statement block at the end of the statement block <6r9ir5$7v5$1(a)nntpd.lkg.dec.com> (fjf219[a-d].pas, fjf502.pas) * initialize local static variables in the main constructor, not in each routine call (fjf458*.pas) * modifying `for'-loop counters within the loop or in a subroutine is not allowed <200005240807.EAA05355(a)mail.bcpl.net>, <Pine.LNX.4.44.0210281004000.31943-100000(a)duch.mimuw.edu.pl> (az47.pas, fjf837*.pas) * label declarations must not be allowed in unit/module interfaces and module implementations (but in unit implementations, BP compatible, though we don't allow nonlocal `goto's into the constructor) (fjf835*.pas) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

10 61

How many bits in longreal?
by John Ollason 06 Jun '03

06 Jun '03

Greetings, I am running GPC under RedHat 7.3 on an Intel i686. I am trying to debug a MatLab program by running it against one written in Gnu Pascal. I am using the type longreal throughout. According to the manual this typically occupies 80 bits. Is there any way of finding out easily how long longreal is on my hardware? I want to avoid precision-related problems. The programs generate much the same output but depart beyond about 7 significant figures. Thanks in advance for information and advice. John O.

3 2

grx again
by Toby Ewing 05 Jun '03

05 Jun '03

Hi, all I'm doing a new install of gpc with grx2.45 on a Win2000 machine. (1) The recent change in the compiler, from recognizing "integer(32)" to requiring "integer attribute (size=32)", means I needed to change line 59 of the grx.pas file accordingly. No biggie, just info. (2) My computer uses 1024 x 768 pixels in 16-bit color when running windoze programs, but the c-compiled modetest demo won't go higher than 1) 1024 x 768 x 1-bit, or 2) 640 x 400 x 8-bit. When I run the Pascal modetest.pas, it exits with error 1: GrSetMode: could not find suitable video driver. Am I missing some critical files? No windoze programs have complained about my video. thanks, Toby

2 3

GCC and gpc
by Andreas Meier 05 Jun '03

05 Jun '03

Hello, now it is planned to integrate g95 in gcc. So my question: Is it planned to integrate gpc in gcc and when? Greats Andi -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lÃ¤cheln! Fotogalerie online mit GMX ohne eigene Homepage!

4 4

Overriding non-virtual methods by virtual ones
by Frank Heckenbach 05 Jun '03

05 Jun '03

I recently came about the issue of overriding non-virtual methods by virtual ones. GPC currently allows this, but it may be slightly confusing. BP allows it as well, so we shouldn't forbid it. But should we warn? (Always or unless `--borland-pascal' was given?) type a = object procedure p; end; b = object (a) procedure p; virtual; end; Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

4 9

BUG REPORT: function (n: LongCard): String(64); -- bug or not allowed?
by Mirsad Todorovac 04 Jun '03

04 Jun '03

Hi, Frank! ------------------------------------------------------- program mirsad16(output); function testproc (n: LongCard): String(64); begin n := n; return 'OK'; end; begin WriteLN (testproc (42)); end. ------------------------------------------------------- bash-2.05b$ gpc -Wall mirsad16.pas mirsad16.pas:4: warning: missing string capacity -- assuming 255 mirsad16.pas:4: parse error before `(' I couldn't find in reference docs whether this is actually banned by specification, or is it a bug in parser. Thanks, Mirsad -- "I have a dream!" -- Martin Luther King Jr. "You can't hold someone down ... without staying down with him." -- Booker T. Washington "... one thing is for sure about the rat race: Even if you win, you're still a rat." -- S. Baars

8 18

Re: Overriding non-virtual methods by
by Theo Carr-Brion 04 Jun '03

04 Jun '03

I am a delphi programmer. Nearly all Delphi code relies on the fields of an object being set to zero automatically. If gpc wishes to be compatible with Delphi it must have the option to do the same. In Delphi you cannot use an abject without calling its constructor so the initialisation of virtual methods is always done. Theo Carr-Brion -----Original Message----- From: Jason Burgon [mailto:gvision@ntlworld.com] Sent: 04 June 2003 08:58 To: gpc(a)gnu.de Subject: Re: Overriding non-virtual methods by Prof A Olowofoyeku (The African Chief) wrote: > PS: I know that, under BP and Delphi, a call to the constructor > automatically zeroes out all the object's fields as appropriate (e.g., > pointers are set to Nil, numbers are set to zero, and strings are set > to empty). This is not the case with BP or Delphi "object"s. It is Turbo Vision's TObject.Init (a constructor) that provides this functionality; it is not an inherent feature of an "object". In Delphi, all "class"es must be a descendant of TObject (a special class known to the compiler), and this also probably does field zeroing in Delphi classes. Jay Jason Burgon. Author of Graphic Vision Version 2.21 available from: http://homepage.ntlworld.com/gvision

1 0

ArcSin, ArcCos
by Frank Heckenbach 02 Jun '03

02 Jun '03

For now I'm using the libm routines, since I'm not convinced that the alternatives are really better. For complex numbers, I'm adding the following, rather simple, routines. If Emil (or someone else) wants to provide more optimized/numerically stable versions, let me know. function Complex_ArcSin (z: Complex): Complex; var t: Complex; begin t := Ln (Cmplx (-Im (z), Re (z)) + SqRt (1 - Sqr (z))); Complex_ArcSin := Cmplx (Im (t), -Re (t)) end; function Complex_ArcCos (z: Complex): Complex; var t: Complex; begin t := Ln (z + SqRt (Sqr (z) - 1)); Complex_ArcCos := Cmplx (Im (t), -Re (t)) end; Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

Problems with installing GPC under Red Hat 9
by Tomasz Kowaltowski 02 Jun '03

02 Jun '03

I installed gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz under my previous Linux (Red Hat 8.) and it worked without any problems. I did the same under Red Hat 9. When I tried to compile a program 'gpc' complained: gpc: installation problem, cannot exec `gpcpp': No such file or directory I put then in /usr/local/bin a symbolic link: gpcpp ->/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/gpcpp Now I got the message: gpc: installation problem, cannot exec `gpc1': No such file or directory I added the link: gpc1 -> /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/gpc1 Now I got a series of messages from the linker; some of them: --------------------------------------------- /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o)(.text+0x5d6): In function `_p_LocaleUpCase': /home/frank/gpc/gcc-2.95.3/gcc/p/rts/rts.c:838: undefined reference to `__ctype_toupper' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o)(.text+0x5ea): In function `_p_LocaleLoCase': /home/frank/gpc/gcc-2.95.3/gcc/p/rts/rts.c:846: undefined reference to `__ctype_tolower' /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/libgpc.a(rts.o)(.text+0x5fe): In function `_p_IsUpCase': /home/frank/gpc/gcc-2.95.3/gcc/p/rts/rts.c:851: undefined reference to `__ctype_b' (... more deleted ...) ----------------------------------------------- Any idea what the problem is? I am not a Linux expert and would appreciate simple advice :-). Please send a copy of the answer to my address because I am not a subscriber to this list. Thanks! -- Tomasz Kowaltowski

2 3

problems with GPC/Mac OS X
by Boris Herman 01 Jun '03

01 Jun '03

Hello I have DLed the newest version listed and the Dec2002 Developer Tools from Apple and have proceeded to work on a more complex project. However, I am unable to compile the source - it gives me this error: > alan.pas: In procedure `f_b': > alan.pas:577: internal error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://www.gnu-pascal.de/todo.html> for instructions. > Any ideas? If anyone cares to look into it I have attached the source, the preprocessed source and the data file needed to run it. Regards, Boris

7 13

Could anyone please tell me how GPC will align variables of most used types by default on Intel platform? (+)
by Ingvar Marny 29 May '03

29 May '03

Hi, dear All. I have made exhaustive (at least, hope so) search in the documentation and mail list archives but found only that "GPC will align variables according to maximum performance", but how exactly? On what boundary will be aligned Integer, Boolean, Longint, Word, etc. On what boundary will be aligned string, record, array, their elements and are there any differences between default alignment of variable without record and variable as record field? And, if possible, I need information for the other platforms. I understand that I can make experiments to find it out but it seems to me it should appear in one or in other place (GPS manuals or mailing lists). Thanx, dear All. Best regards, Ingvar mailto:marny@rambler.ru

5 4

Upper/lower case in identifiers
by Frank Heckenbach 22 May '03

22 May '03

As you probably know, GPC currently converts all identifiers to first letter upper-case/rest lower-case. Since this is often not nice, I plan to change this. This would affect at least the following things: - error messages - the file name chosen with `--transparent-file-names' (makes a difference only on case-sensitive file systems, i.e. not Dos/Windows); is this ok (to those who use this option)? - the file name prompt with external files without binding While I'm at it, it might be easy to add a warning if an identifier is used with varying case (something like `var Foo: Integer; [...] WriteLn (FOO)'). - Any ideas for the name of the option? (`-Widentifier-case'?) - Default? (I suppose off, though I think I myself would prefer on.) - Should it work across units/modules? Or should it be a tri-state option (never/current file/global)? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

8 8

New (randomized) test ...
by Mirsad Todorovac 20 May '03

20 May '03

Hi, Frank, others! Here is the first test I wrote using GPC manual's instructions for writting randomized tests. It concerns sets, since they have been a place where bugs appeared in the past - even though Frank's implementation seems invariant to number of bits ``MedCard'' type could have sometimes in the future. BTW, there seems to be a need for something called a "random set" of data, pehaps even with given ``Monte Carlo'' function, to get a different distibution than uniform one. The most plain random set could be the one with its MedCards initialized with random numbers with probably 0.5 probability for each bit being set. Having them initialized correctly is inefficient, and relying on internal implementation that could change without prior notice can backfire - hence IMHO it would be great to have a function like e.g. RandomSet{,Uniform}(LBound, UBound) Please consider this, IMHO right now it could be used for testing purposes, yet probably other uses could be seen ... All the best, Mirsad -- "I have a dream!" -- Martin Luther King Jr. "You can't hold someone down ... without staying down with him." -- Booker T. Washington

3 12

Gcc-3.3 release and gpc-20030507
by David Kredba 17 May '03

17 May '03

Hello all, when I am bootstraping new gcc-3.3 release with GNU Pascal 20030507 I got : make[3]: Entering directory `/home/david/gcc-3.3-build/gcc/p/rts' .../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path=/home/david/gcc-3.3-gpc/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat /home/david/gcc-3.3-gpc/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.3'" /home/david/gcc-3.3-gpc/gcc/p/rts/numtodec.pas /home/david/gcc-3.3-gpc/gcc/p/rts/numtodec.pas:113: internal compiler error: in dwarf2out_finish, at dwarf2out.c:12666 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [numtodec.o] Error 1 make[3]: Leaving directory `/home/david/gcc-3.3-build/gcc/p/rts' make[2]: *** [pascal.rts] Error 2 make[2]: Leaving directory `/home/david/gcc-3.3-build/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/home/david/gcc-3.3-build/gcc' make: *** [bootstrap] Error 2 gcc -v : Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3/specs Configured with: ../gcc-3.3/configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,objc,f77,ada,java Thread model: posix gcc version 3.3 uname -r : 2.4.21-0.16mm-mdksmp Configure command: .../gcc-3.3-gpc/configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,objc,f77,ada,java,pascal Make command : make -j4 bootstrap4 After 1st fail in gpc : make bootstrap4 and after fail in gpc : make bootstrap The same error results in all cases. David

5 9

New Install questions
by gpc＠radstream.com 17 May '03

17 May '03

It has been a while but I have come back to GPC again... I just installed the 20030507 Linux binary on my RH ver 8 machine. I thought I followed the FAQ and INSTALL instructions but I get this: [ken@illinois demos]# gpc hello.pas /usr/bin/ld: cannot find -lgcc collect2: ld returned 1 exit status So, I try another file... [ken@illinois demos]# gpc pi.pas pi.pas:31: module/unit interface `GPC' could not be imported Tell me the truth... Was I sleeping when I installed GPC last night? TNX Ken Linder KC7RAD

1 0

Re: Gcc-3.3 release and gpc-20030507
by Waldek Hebisch 16 May '03

16 May '03

David Kredba wrote: > Thank U, > > I`ll try gstabs. > > Your patch is not working for me : > > [david@g200 gcc]$ patch -Np1 -i ./dwarf.patch > patching file p/declarations.c > patch: **** malformed patch at line 11: return block; > > > David > I checked the patch both before sending and again after seeing your message (this time using the copy I got back from the list) and it was OK. Maybe your mailer garbled the patch (the original of the line which appears in the error message has four spaces at the beginning, while I see sixteen spaces after semicolon -- looks that that some whitespace may be converted to tabs and back). This time I put the patch as an attachment (should be more resistant to mailers...). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

1 0

object assignment
by David Ulbrich 16 May '03

16 May '03

Hi all, I like to use objects as data container only: (records with "inheritence", no methods.) type tHead=object ID :integer; sum :integer; end; type tFoo1=object(tHead) data:float; end; type tFoo2=object(tHead) data:longint; end; var headvar:tHead; foo1var:tFoo1; Head:=foo1; <- gpc gives "invalid explicit assignment between objects" //BP and Delphi assign with the statement above all common fields: // Headvar.ID :=foo1var.ID // Headvar.sum :=foo1var.sum it there a legal way to get the base-data from foo1var into headvar at once? Thanks David

2 1

Dynamic object methods
by Frank Heckenbach 15 May '03

15 May '03

One item on the to-do list are BP compatible dynamic methods. As far as I understand the BP description, they are semantically equivalent to virtual methods, only the syntax is different (an integer index added) and the implementation (which we don't have to follow, of course). Ignoring this index syntactically would be easy to do. Would this be useful, and is it really all that's required? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

10 36

Common symbols
by Adriaan van Os 12 May '03

12 May '03

While trying to build a Mach-O dynamically linked shared library with GPC and LD, I get the following error: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_0__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_1__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_2__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_3__ (size 32) In the Mach-O Runtime Architecture docs I found: "A common symbol is a symbol that may appear in multiple intermediate object files. The static linker permits multiple common symbol definitions with the same name in input files, and copies the one with the largest size to the final product. If there is an another symbol with the same name as a common symbol, the static linker will ignore the common symbol instead. The standard C compiler generates a common symbol when it sees a tentative definition—a global variable that has no initializer and is not marked extern. The following line is an example of a tentative definition: int x; A shared library cannot have common symbols. To eliminate common symbols in an existing shared library, you must either explicitly define the symbol (with an initialized value, for example) in one of the modules of the shared library, or pass the -fno-common flag to the compiler." My questions are: 1. Is there something special about symbols for sets ? 2. Would it help to rebuild libgpc.a with the --no-common flag ? 3. Any other ideas or suggestions ? Regards, Adriaan van Os

3 6

[Fwd: Re: gcc 3.x breaks ABI compatibility? [Was: Re: Bug 00314 -- div() still broken]]
by CBFalconer 11 May '03

11 May '03

Here is something I still have on my machine about this problem -------- Original Message -------- Subject: Re: gcc 3.x breaks ABI compatibility? [Was: Re: Bug 00314 -- div() still broken] Date: Tue, 29 Apr 2003 08:44:45 +0100 From: Richard Dawe <rich(a)phekda.freeserve.co.uk> Reply-To: djgpp-workers(a)delorie.com To: Andris Pavenis <pavenis(a)latnet.lv> CC: djgpp-workers(a)delorie.com, Ben Peddell <killer.lightspeed(a)bigpond.com>,rudd(a)cyberoptics.com References: <3e9c6920$0$21928$afc38c87@> <lzLqa.23283$1s1.356122(a)newsfeeds.bigpond.com> <3EABA5AA.99B8EDE3(a)phekda.freeserve.co.uk> <200304280954.02899.pavenis(a)latnet.lv> Hello. Andris Pavenis wrote: > > On Sunday 27 April 2003 12:40, Richard Dawe wrote: [snip] > > I've just looked at the gcc 2.95.2 sources and it looks like > > -fpcc-struct-return (i.e.: use memory) is the default there. > > > > The gcc 3.2.2 source seems to default to using registers. See the end > > gcc/config/i386/djgpp.h: > > > > /* Don't default to pcc-struct-return, because gcc is the only compiler, > > and we want to retain compatibility with older gcc versions. */ > > #define DEFAULT_PCC_STRUCT_RETURN 0 > > > > Why is this defined? I couldn't see a ChangeLog entry for djgpp.h. AFAICT > > this breaks backwards compatibility, i.e.: the opposite of what the > > comment says. Is there something I'm missing? > > I copied it from other i386 targets. GCC-3.2.2 didn't compile without > defining DEFAULT_PCC_STRUCT_RETURN, as there is no default Not all i386 targets define DEFAULT_PCC_STRUCT_RETURN to be 0. Linux and NetBSD ELF don't. I think we need to use the same as the default for 2.95.x, i.e.: #define DEFAULT_PCC_STRUCT_RETURN 1 This is a pretty critical bug. Do you have any plans to rebuild gcc 3.2.2 (or 3.2.3) with this fix? Thanks, bye, Rich =] -- Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]

2 1

GPC on Palm OS ?
by Adriaan van Os 10 May '03

10 May '03

I would be curious to know if anybody on the list * ever tried to build gpc for Palm OS, using prc-tools (<prc-tools.sourceforge.net>), * or worked with the PocketStudio Pascal compiler for Palm OS. Regards, Adriaan van Os

1 0

Re: gpc-20030507 - attribute bug?
by Prof A Olowofoyeku (The African Chief) 10 May '03

10 May '03

On 10 May 2003 at 12:22, I wrote: [...] > I have another problem. This code used to compile: > > unit attrbug_2; > interface > uses GPC; > FUNCTION DirectoryExists ( CONST DirName : String ) : Boolean; > attribute (name = '_p_DirectoryExists'); external; > FUNCTION FileSearch ( CONST FileName, DirList : String ) : TString; > attribute (name = '_p_FSearch'); external; implementation end. > > Now, it dies with this error: "attributes in forward declared routines > are not allowed". If "external" is removed, then you get an error like > "unresolved forward declaration `FileSearch'". > > This code is taken from the Sysutils unit, which exports some functions > that already exist in the GPC unit. In older times, you just asmnamed > them. In the penultimate snapshot, that was changed to the above. Now, > it doesn't work. I need this to work (or at least I need to have a way > to reexport routines from other units). This is reminiscent of the > earlier discussions on unit propagation. I am not sure how that > discussion was resolved. > Unfortunately, this problem is not only related to unit propagation. I have just tried to compile the Windows unit (that exports thousands of winapi routines, interfacing to the Mingw winapi libraries), and two of those routines are now rejected with the "attributes in forward declared routines are not allowed" error. There is no reason for those two routines to be singled out, and there is no USES problem here. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

1 0

Build problem 20030507 on 2.3.1
by Mirsad Todorovac 09 May '03

09 May '03

Hi, all! When I do gzip -cd <tbz2> | tar xvf -; cd ../p gcc-3.2.1; cd builddir; /home/.../gcc-3.2.1/configure --enable-languages=pascal w or w/o --prefix=/usr/local/gpc/20030507-3.2.1/ then make It didn't say that it wants to apply patch, and it also didn't build gpc in corresponding bin. I can't think of anything smart, I've done rm -rf gcc-3.2.1; gzip -cd ...; gzip -cd ...; mv .../p ...; ... several times, and I couldn't get to the point where it asked for >RETURN> before applying the patch, neither it said it did. Any idea? Architecture is i686, linux Debian woody, make is GNU make 3.80, ... Thanks, Mirsad -- "I have a dream!" -- Martin Luther King Jr. "You can't hold someone down ... without staying down with him." -- Booker T. Washington

3 3

gcc 3.2.3 successes
by Prof A Olowofoyeku (The African Chief) 05 May '03

05 May '03

Hi folks I have built gpc 20030323 with gcc-3.2.3 sources, both under Cygwin and Mingw. I used the gcc-3.2.2.diff. There were no problems with either configuring or building. I have not yet run the testsuites, but everything seems okay with my own programs. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

4 6

`Return'
by Frank Heckenbach 01 May '03

01 May '03

`Return' currently needs special syntactic handling, only because it's (optional) argument doesn't have to be enclosed in parentheses (like in C), such as `Return 42'. The only Pascal dialect (AFAIK) that also supports `Return' is Mac Pascal. Does it work without parentheses there? If not, I suggest to change it in GPC, even if it means a few (trivial) changes in existing code. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

4 7

Book about GNU Pascal
by Marek Soobik 01 May '03

01 May '03

Hi! Can anybody recommend me a good reference book of GNU Pascal (written in English). Marek

2 1

Weird type/identifier conflicts
by Grant Jacobs 30 Apr '03

30 Apr '03

This is an *updated* version of my previous message, which I mistaken sent to gpc-doc (my apologies). (See the bits 'Addendum' for the new stuff I've added.) Excuse my being frustrated. I am trying damn hard to get GPC (2.1 (20020510), based on gcc-2.95.3 20010315 (release)) to compile a Pascal program I wrote some time ago but keep running it things I can't make sense of. Maybe I'm being unfair, but I'll give you the whole story just in case its something new. The latest issue I'm having is a run of type vs. identifier conflict errors of the form: ./GHJ_AARegions.pas:49: type name expected, identifier `Fnames' given ./GHJ_AARegions.pas:49: warning: missing type in declaration of `Infname' ./GHJ_AARegions.pas:54: warning: parameter has incomplete type My trouble was fnames *is* a type. It is *only* defined as a type. So how the heck does the compiler come away thinking that its an identifier????? I eventually resolved this by directly 'using' modules, rather than rely on the hierarchy (read on). When this error occurred the GHJ_AARegions unit uses GHJFnames. GHJFnames in turn uses GHJFiles, which is where the type fnames is defined. (Really these two levels need to be the other way around, but this is a legacy program I am porting, so I have to deal with that after the port.) Since these uses statements were within the interface section, I presumed the definitions would propagate upwards so that they form a hierarchy. Or, put another way, I assumed the interface of a unit is extended by any units it uses in its interface section. Originally, I had: unit GHJ_AARegions ; interface uses GHJStdDefs, GHJStdMaths { for inrange() }, GHJttInterface { for press_return() }, GHJStrings { for get_string8() }, {=>} GHJFnames { for get_fname() }, GHJ_AAErrors, GHJ_AAUtils, GHJ_AAGlobalUnit ; By getting GHJ_AARegions to explicitly, directly, use GHJFiles, the compiler stopped complaining. ie. I changed the above code to: unit GHJ_AARegions ; interface uses GHJStdDefs, GHJStdMaths { for inrange() }, GHJttInterface { for press_return() }, GHJStrings { for get_string8() }, {=>} GHJFiles, GHJFnames { for get_fname() }, GHJ_AAErrors, GHJ_AAUtils, GHJ_AAGlobalUnit ; {=>} points out the offending line of source. If this is truly the problem, then I presume there is no way of building a hierarchy of units in GPC at present? (In this case my safest strategy is to have every unit uses *all* the lower units directly, "just in case". Or put, another way, I might just as well use includes to make everything one big flat program. Sorry, but I *am* frustrated!) Three thoughts: 1. This is the correct behaviour?: surely I should be able to use a higher-level module and have all the lower-level modules definitions within that higher-level module "gotten" at the same time without have to explicitly duck behind the scenes and drag out each module??? Excuse me for asking this, but its not terribly clear from the docs, at least on my reading of it. Addendum: I've since seen section 6.1.8.2. The source structure of UCSD/Borland units of the docs say "A units exports everything declared in the interface section". This it doesn't appear to do if we consider things in the units imported via uses. 2. Why the heck does the compiler report the message it does? "Missing type fnames" perhaps, but since fnames is only ever defined as a type and never as an identifier, it shouldn't be able to report the message it did... 3. Is there any chance you can tell the user where the "identifier" (see the error message) is defined so that in future users might have chance of trying to second-guess just what the compiler is "thinking"? Sorry I can't provide a full code example: I am porting a largish program (approx. 60,000 lines of source in a dozen or so modules) and in any event I can't understand the problem well enough to create an example - catch-22... Looking at the known bugs for ver. 2.1 there are a couple that might be relevant, esp."Types declared in a module interface are not visible in the implementation" (but does this refer to the same module's interface section and how are units and modules related with reference to this?) While I'm writing, is there any chance you can make the compiler keep trying after one unit has failed, rather than stopping at that point? It seems that if there is even one error in a unit, the compilation is abandoned at the end of that unit. Now to try figure out how GPC claims a type-mismatch on something that is definitely the same type and the type is only defined in one place... probably the same issue, we'll see... Addendum: Nope. It proves to be a unit issue, but a different one. It seems that --automake doesn't "drill down". If you modify a lower level unit, then recompile a higher-level one that uses the lower-level unit, GPC doesn't re-compile the lower-level unit first and instead comes out with (apparently) misleading error messages. --automake in my hands isn't so auto ;-) ! Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs(a)bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents.

8 77

[admin@gmane.org: gpc added to Gmane]
by Anja Gerwinski 30 Apr '03

30 Apr '03

Hello, checking the mail for gpc-owner, I found the message below. The GPC list has been added to http://gmane.org/ which is a mail-to-news gateway. They claim they received a request for this. Does anyone know anything about this? As the gpc list archive is public, I suppose it is no problem that the list is now archived at gmane, too. However, I find it puzzling that they add a list without asking for permission first. Our list archive provided by Frank's crystal removes email addresses from the formatted view. I did not check how Gmane deals with this. The mail below says "Address encryption is off". Could someone please check what this means, and get it changed, if necessary? Best wishes, Anja ----- Forwarded message from Gmane Administrator <admin(a)gmane.org> ----- X-Gmane-Information: For more information, see http://gmane.org/ From: admin(a)gmane.org (Gmane Administrator) To: owner-gpc(a)gnu.de Subject: gpc added to Gmane Organization: GNU Mail To News -- http://gmane.org/ Date: Sun, 06 Apr 2003 16:00:29 +0200 We have received a request for adding the gpc(a)gnu.de mailing list to the Gmane mail-to-news gateway/archive. A subscription request message has been sent. If this is contrary to your wishes, please send a mail to admin(a)gmane.org saying so, and the list will be removed from Gmane. Gmane is a mail-to-news portal that never expires its messages. It therefore also functions as a mailing list archive. It's a bi-directional gateway, but Gmane verifies that its users' email addresses are valid before passing the messages through the news-to-mail gateway. (Groups can also be made "read-only", which means that Gmane won't forward any messages at all to the mailing list.) Gmane can encrypt addresses to make address harvesting difficult, and heeds X-No-Archive and related headers. If you wish to import older archives into Gmane, send a message to the Gmane administrators -- just reply to this message. The following parameters are set for this mailing list: * Newsgroup name: gmane.comp.compilers.gpc * Mailing list address: gpc(a)gnu.de * The gateway is bi-directional * Address encryption is off * Spam detection is on * The list is described as: "discussions and development of the GNU Pascal compiler" * News URL: news://news.gmane.org/gmane.comp.compilers.gpc * Web URL: http://news.gmane.org/thread.php?group=gmane.comp.compilers.gpc This newsgroup will be created when the first message from the mailing list arrives. For more information about the Gmane project, go to <URL: http://gmane.org/>. This request was handled by Tom Koelman <tkoelman(a)xs4all.nl>. ----- End forwarded message -----

1 0

gcc-3.2.3
by Russell Whitaker 29 Apr '03

29 Apr '03

Hi gcc-3.2.3 was released today. Created a diff using 3.2.2, attached. Tried to compile using latest gpc alpha. Got as far as dwarf2out.c then got an internal compiler error message, dwarf2out_finish, at dwarf2out.c:12278 Russ

3 2

None
by Abduttawwaab Kim 29 Apr '03

29 Apr '03

subscribe gpc-announce akim(a)just.edu.jo

1 0

Urgent Business Relationship
by usmanalhaji＠incamail.com 26 Apr '03

26 Apr '03

FROM: USMAN ALHAJI TO: THE PRESIDENT/CEO Dear Sir, STRICTLY CONFIDENTIAL JOINT VENTURE PARTNERSHIP I am making this venture proposal to you, as a reliable partner. I got your contact from your country business guide as a reliable person/company in a related area of my interest for investment. The money I want to invest was acquired from the late Nigeria President(General Sanni Abacha) vault account then I was his financial adviser. I have successfully moved this money through a security finance company to United kingdom. The amount involved is US$20 million Presently, I work for the Nigerian Government as a civil servant. If you will like to assist me as a partner then indicate your interest after which we shall both discuss on the modalities. All other information relative to the presence of the funds will be revealed to you as we progress on. I will like my proposal to be kept confidential and you can reach me urgently on my confidential telephone number 234-803 337 0621 for more discussion. Please indicate your telephone and fax number. Bye and God Bless, Usman Alhaji NB: Please do reply me immediately on the above e-mail addresses.

1 0

Re: ANN : JEDI-SDL now also compatible with Gnu Pascal & TMT Pascal
by Dominique Louis 25 Apr '03

25 Apr '03

In case no one knows what SDL or JEDI-SDL are... SDL ( http://www.libsdl.org ) is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. It is used by MPEG playback software, emulators, and many popular games, including the award winning Linux ports of "Civilization: Call To Power", "Kohan: Immortal Sovereigns", "Tribes 2", "Unreal Tournament", "Soldier of Fortune" and most of the games @ http://www.lokigames.com/products/ Simple DirectMedia Layer supports Linux, Windows, BeOS, MacOS Classic, MacOS X, FreeBSD, OpenBSD, BSD/OS, Solaris, and IRIX and even Playstation 2 ( When will be see GPC on PS2 :). JEDI-SDL are the Pascal bindings/interfaces so allow you to use Pascal to write cross-platform games or other multimedia application. I hope this clarifies what JEDI-SDL is and how it relates to SDL. Dominique http://www.DelphiGamer.com := go on, write a game instead;

1 0

ANN : JEDI-SDL now also compatible with Gnu Pascal & TMT Pascal compilers...
by Dominique Louis 25 Apr '03

25 Apr '03

Hi All, Just a quick note to say that I have just checked into CVS the last JEDI-SDL ( http://sourceforge.net/projects/jedi-sdl/ ) changes ( for now ) that has added compatability for the Gnu Pascal and TMT Pascal compilers. Thanks to Alexey "Clootie" Barkovoy for his help with TMT support. Thanks to Prof. Abimbola "The Chief" Olowofoyeku and Eike Lange for their help with Gnu Pascal support. Thanks to Mr "Que Pasha Pepe" Kroket for his help with better FreePascal support. These latest changes have been tested under Windows and the newly modified JEDISDL Aliens demo ( the benchmark for cross-compiler compatability ) has also been checked into CVS. These Pascal bindings and the demo now compile flawlessly under Delphi, FreePascal ( FPC ) 1.0.4, Gnu Pascal ( GPC ) Latest Alpha & TMT Pascal. The Aliens Demo runs flawlessly with Music and FX under Delphi, FPC and TMT. The GPC version has a screen refresh problem, while sound collision detection etc work flawlessly. The GPC issue, may be due to the Alpha status of the compiler or my lack of familiarity with the GPC compiler, as all compilers are essentially compiling the same code. Looking ahead, testing and bug fixing is under way to make sure the headers support Gnu Pascal on Linux and MacOS X ( yes MacOS, woo hoo ) and FreePascal under Linux. I hope this widens the appeal of JEDI-SDL. Dominique http://www.DelphiGamer.com := go on, write a game instead;

4 4

Importing a module several times
by Frank Heckenbach 23 Apr '03

23 Apr '03

Is this valid EP? module m; export m = all; const o = 'O'; k = 'K'; end; end. program p (Output); import m only (o); m only (k); begin WriteLn (o, k) end. The following might mean it isn't: : The occurrence of an interfaceÂidentifier in an importÂspecification shall : constitute the definingÂpoint of the identifier of the interfaceÂidentifier : as an importedÂinterfaceÂidentifier for the region that is the block, : moduleÂheading, or moduleÂblock closestÂcontaining the : importÂspecification. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

Dynamic Linked Libraries under MacOS?
by Dominique Louis 23 Apr '03

23 Apr '03

How does one interface to DLLs ( or whatever they are called ) under MacOS? What are the steps required in order to achieve this? Thanks, Dominique http://www.DelphiGamer.com := go on, write a game instead;

2 1

Modules without implementation
by Frank Heckenbach 22 Apr '03

22 Apr '03

One of the listed bugs of GPC was "modules without implementation". However, if I understand EP correctly, this actually doesn't concern `interface' modules (as in pmodtest.pas without the `implementation' part): : Each identifier having a definingÂpoint as a moduleÂidentifier in a : moduleÂheading of a moduleÂ declaration containing the interfaceÂdirective : interface shall have exactly one of its applied occurrences in a : moduleÂidentification of a moduleÂdeclaration containing the : implementationÂdirective implementation. In contrast, the following works in GPC (with an almost empty module-block): module fjf843m; export fjf843m = all; const OK = 'OK'; end; end. What seems to be missing is this variant (no module-block at all), and I'll add it in the next release (that's easy to do): module fjf843m; export fjf843m = all; const OK = 'OK'; end. However, AFAICS, EP doesn't require to support `interface' modules without implementation. That's good because GPC has to know when compiling a module whether there will be an implementation part (because it has to create the initializer if (and only if) not). It also seems reasonable to me from the programmer's point of view. When you write a module interface, you know whether there has to be an implementation (namely, if there are any routines in the interface or an initializer or finalizer will be needed) or not (only constants, types and variables without need for initialization/finalization). So it makes sense to specify this explicitly (by writing `interface' or not). Can anyone confirm my interpretation? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

5 11

-Wparentheses
by Frank Heckenbach 21 Apr '03

21 Apr '03

GCC supports `-Wparentheses' (warn about some constructs where parentheses are suggested for clarification, although not strictly syntactically necessary). The corresponding code is also there for GPC. I'm going to activate it now. The questions are: - Which constructs to warn about? So far, I've come up with the following ones: * `and' in an operand of `or', as in `a or b and c' which is equivalent to `a or (b and c)', but may confuse the reader. (Same for `and_then' instead of `and' etc., of course.) * logical operations (`and', `or', `not', etc.) in an operand of a relational operator (`=', etc., `in'). This would catch cases like the dreaded `if not a = b'. - What should be the default? I suggest off by default and on with `-Wall' (same as in GCC). (Of course, the issue is not as serious in Pascal than it is in C where the danger of confusion between `==' and `=' in a comparison almost requires such a warning, but I think it's also useful in Pascal.) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

4 5

Progress of Mac OS X port
by Adriaan van Os 20 Apr '03

20 Apr '03

Yesterday, I wrote a small test program and linked it against Apple's "Carbon framework". To my surprise, it worked. So, against all expectations, the current compiler is able to link to Apple "dylibs" and Apple "frameworks". The compiler produces ".o" code and the Apple-"ld" linker takes care of the rest. This implies, that I am loosing interest in the Apple-patched GCC compiler. Apple writes "we're not even sure what all of them [the compiler changes] are, because the existing compiler has many undocumented changes inherited from 10 years of NeXT and Apple hacking, and nobody knows what some of them are for." This doesn't inspire confidence. Besides, important changes (like precompiled header support) are now getting integrated into mainline FSF. So, I am slowly considering it an advantage (rather than a disadvantage) that the current port is based on mainline FSF-GCC 3.2.1. And isn't it fun to read in officlal Apple docs for some compiler option "Not supported on Mac OS X" where the GPC compiler actually does .... As a further experiment, I compiled hello.pas into hello.o and tried to link it with "mwld", the command-line version of the MetroWerks CodeWarrior linker. Again, to my surprise, it worked. I added "hello.o" to a CodeWarrior Project and disassembled it there. It worked. So, maybe some day there will be a GNU Pascal compiler plug-in CodeWarrior (not a promise, just an idea) .... Regards, Adriaan van Os

6 13

gcc-2.95 with libefence
by Frank Heckenbach 20 Apr '03

20 Apr '03

I just build GPC with gcc-2.95.3 under Linux/IA32, linked with libefence and ran the test-suite. There was only one bug (7 instances: drf3a.pas, fjf639j7.pas, fjf669b.pas, goto7.pas, jj5.pas, sam11.pas, strindex.pas) which seems to be a backend bug. The bug seems relatively harmless -- only an invalid read access, and it might not even do any real harm in the worst circumstances (but I don't know enough about the backend data structures to tell for sure). So I won't add the fix to GPC's GCC patches (since GPC's support for gcc-2 will disappear "soon", anyway). If anyone wants to apply it, anyway, you can find it attached. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

gpc-20030323 released (IMPORTANT NOTES ABOUT BACKWARD-INCOMPATIBILITY)
by Frank Heckenbach 18 Apr '03

18 Apr '03

I've uploaded a new alpha to http://www.gnu-pascal.de/alpha/ You will hate this release ... at least if you make heavy use of external declarations or other directives. We all knew that some backward-incompatible changes in this area would have to be made, now that's happened. PLEASE READ THE NOTES BELOW FOR DETAILS. Changes that affect building GPC: ================================= - Dwarf2 debug info (the default under Linux and many other systems with gcc-3) finally works. This means you can now build GPC with gcc-3 without `-g0' or `-gstabs'. - Building GPC no more requires gperf (those who maintain build dependencies please note this). - Besides the source distributions as before, there is now also a "minimal" distribution. This is compressed with bzip2 instead of gzip and does not contain any generated files. These files will be generated automatically when building GPC, but you need some additional tools installed: bzip2, bash, *GNU* sed, GNU awk, GNU m4, bison, flex, autoconf, help2man, makeinfo (at least version 4.1). Other changes: ============== - Forward referencing pointers generate proper debug info now. - Discriminant identifiers are allowed as variant record selectors. - `export Foo = all (...)' (fjf811*.pas) - Delphi-compatible `initialization', `finalization' (chief43*.pas) - Type-casts are BP compatible now, in particular, value type-casts between ordinal and real or complex types don't work anymore. - All non-ISO-7185 keywords can be used as identifiers (with two small exceptions). (fjf440.pas) - `pack-struct' does not imply bit-level packing anymore (only explicit `packed' records and arrays do). - New options `--[no-]ignore-packed' (`--ignore-packed' is the default in BP mode). (fjf796*.pas) - New option `--maximum-field-alignment=N' - `{$[no-]pack-struct}' as a compiler directive - New options `-W[no-]local-external' (implied by `-Wall') - New options `--vax-pascal', `--mac-pascal' - Mac Pascal directives `definec', `macro', `undefc', `ifc', `ifoptc', `elsec', `elifc', `endc', `errorc' - Units without `implementation' part - When passing a schema variable as an untyped argument, the whole schema, including the discriminants is passed. (fjf798.pas) - `TimeZone' in `TimeStamp' counts seconds *east* of UTC now (not west, as before). (datetimedemo.pas) - Some bug fixes related to operator overloading. - Variables declared in interfaces of modules are now initialized (capacity of strings etc.). (daj3.pas, sven14c.pas, nick1.pas) - Various other bug fixes. Directives and attributes: ========================== - `external name' works (BP compatible). So procedure Foo; external; asmname 'bar'; or (equivalent previously) procedure Foo; asmname 'bar'; can be changed to procedure Foo; external name 'bar'; GPC also accepts procedure Foo; external 'libname' name 'bar'; but ignores 'libname'. It could be supported via automake, but since automake is to be replaced by gp, anyway, it seems pointless to do it now. - `name' works as an attribute. - `attribute's with single parameters can be written with `=', so attribute (name ('foo')) and attribute (name = 'foo') are equivalent. - Linker names (whether by `external name' or as an `attribute') can be string constant expressions now (e.g., involving declared string constants and `+'). The same applies to module/unit file names specified with `in'. - `asmname' is deprecated (and will be dropped in a future version). * External `asmname' constructions can be changed as shown above. * In a unit interface, change procedure Foo; asmname 'bar'; to procedure Foo; external name 'bar'; *if* the routine is really external (e.g. implemented in a C file or library); otherwise to procedure Foo; attribute (name = 'bar'); (previously, GPC didn't care, but now you have to distinguish these cases). - `external' without an asmname (whether by `external name' or as an `attribute') defaults to all-lowercase linker names now. GPC will give a warning now (because of the change). This warning will disappear in the future (but the change will remain in effect, of course). Routines without `external' or asmname still use first-uppercase linker names, for those who care. But it's not recommended to rely on this. So change procedure Foo; external; to procedure Foo; external name 'Foo'; (or change the corresponding C code to `foo' if that's under your control). - All of the above applies to variables as well. - `c', `c_language' are also deprecated. Instead of procedure Foo; c; or procedure Foo; c_language; write procedure Foo; external; (if you don't mind the warning for now), or procedure Foo; external name 'foo'; (if you prefer to make the linker name more explicit). - `static', `volatile' and `register' for variables are no prefix directives anymore, but attributes. E.g. var Foo: static Integer; becomes var Foo: Integer; attribute (static); - Same for `inline' with routines. inline procedure Foo; becomes procedure Foo; attribute (inline); - A new attribute `const' for variables (really read-only -- unlike BP's "typed constants", and also applicable to external variables). - `attribute' for routines doesn't imply `forward' anymore, so you don't have to declare routines twice in a program or implementation part when setting the linker name or some other attribute. E.g. procedure Foo; attribute (noreturn); { forward; -- ignored here before } procedure Foo; begin Halt end; becomes: procedure Foo; attribute (noreturn); begin Halt end; A final example: procedure Foo; asmname 'bar'; attribute (noreturn); procedure Foo; begin Halt end; becomes: procedure Foo; attribute (noreturn, name = 'bar'); begin Halt end; Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

9 66

Re: Need units for delphi classes and forms
by Prof. A Olowofoyeku (The African Chief) 17 Apr '03

17 Apr '03

Brian Keener wrote: >I am playing around with porting an application from Visual C++ and >Delphi to GNU C++ and GNU GPC and I have a working GPC Compiler >(based on a compile of the Tests in GPC). While I am no where near >to having a working Makefile or truly compiled GNU GPC code for this >application I have gotten as far as being able to determine that I >need units for Delphi Classes and Forms. > >Does anyone know where I might locate these or get replacements that >will work with GPC or is there some other using I need instead. Unfortunately, you will not get very far without a tremendous amount of work. Units for Delphi classes and forms do not exist for use with GPC. Even with compilers that fully support the Delphi object model (e.g., Free Pascal and Virtual Pascal), it would be a herculean undertaking to compile the Delphi VCL or build anything like it. There are projects (e.g., Lazarus) that aim to produce something like the VCL, but they still have a very long way to go. With GPC, the compiler itself currently supports only the old BP object model - a different thing from the Delphi model. I have produced GPC units that begin to implement some things for Delphi compatibility (e.g., a Windows unit, and a rudimentary Sysutils unit) - but you will need far more than these. In effect, you would have to rewrite your programs (or at least the user interface parts thereof). How difficult this will be would depend on the kind of programs that you have written, and how much use they make of VCL visual objects. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/

2 1

Need units for delphi classes and forms
by Brian Keener 17 Apr '03

17 Apr '03

I am playing around with porting an application from Visual C++ and Delphi to GNU C++ and GNU GPC and I have a working GPC Compiler (based on a compile of the Tests in GPC). While I am no where near to having a working Makefile or truly compiled GNU GPC code for this application I have gotten as far as being able to determine that I need units for Delphi Classes and Forms. Does anyone know where I might locate these or get replacements that will work with GPC or is there some other using I need instead. Brian Keener bkeener(a)thesoftwaresource.com

2 1

Remove {$debug-statement}
by Frank Heckenbach 16 Apr '03

16 Apr '03

GPC has supported the compiler directive `{$debug-statement}', mostly as a way to ease "WriteLn debugging" in a time when debug info was mostly unusable (i.e., until a little more than a year ago ;-). Since debug info now works (perhaps with small bugs, but at least better than WriteLn debugging), I think we can drop `{$debug-statement}'. Or does anyone still need it for any purpose? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

RHIDE URL
by Frank Heckenbach 14 Apr '03

14 Apr '03

Just noted that the RHIDE URL is broken. Does anyone have a new URL? If someone discovers broken URLs or hears about a linked page's moving, please let me know in the future. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

2 1

Bug: variable declared in a unit and masked in another
by Jean-Pierre Vial 13 Apr '03

13 Apr '03

One of my programs works fine with GPC2.1/gcc2.95.3 it does not compile with 2003/03/23 I could isolate the problem (out of a 5000 lines source) to two small units (see below) The original unit declaz contains global variables and procedure common to almost all the rest of the program. Ttwo of its (public) variables are masked in the implementation part of another unit by a variable with the same name (not a bug). There is a warning for this situation: fine, but not so fine, all the variables declared after the warning are ignored, and trigger errors when they appear later. To see it happen, copy the two sources below as gdeclaz.pas and gimpragr.pas, and try gpc --automake -c gimpragr.pas I get jp@brea:~/agreg/src/pascal> gpc --automake -c gimpragr.pas gimpragr.pas:21: redeclaration of `l132' gdeclaz.pas:6: previous declaration gimpragr.pas: In procedure `presidence': gimpragr.pas:23: undeclared identifier `president' (first use in this routine) gimpragr.pas:23: (Each undeclared identifier is reported only once gimpragr.pas:23: for each routine it appears in.) gimpragr.pas:23: undeclared identifier `presidente' (first use in this routine) ***************************************************************************** unit gdeclaz; interface var l132 : boolean; implementation END. ********************************************************************************* Unit gimpragr; Interface Procedure impression; Implementation Uses gdeclaz; Var l132, president,presidente,chrono: Boolean; Procedure presidence; Begin If Not (president Or presidente) Then Begin write('La prÃ©sidence est elle tenue par un homme ou une femme H/F ? '); End; End; { presidence } procedure impression; Begin writeln('impression'); end; END. ****************************************************************************************** -- Jean-Pierre Vial

2 3

Compiled gpc on cygwin but not sure what I have (where is gpc)
by Brian Keener 12 Apr '03

12 Apr '03

Hello all, As you can tell from the subject I am a real newbie to GNU-Pascal but I have an application I am trying to port to Cygwin and it has several pascal modules (originally from Borland Delphi) that I will need to compile so I am trying to get a working copy of gnu-pascal for my Cygwin install. I tried a binary install and it had a gpc.exe but the problem there was the binary was for cygwin and gcc 2.95.3 and cygwin has moved to gcc 3.2 and the binaries were compiled so they installed to cygnus/usr/bin instead of say usr/bin in cygwin so I couldn't really use the binary as it could not find all the 2.95.3 libraries for gcc it needed. I was going to try the install-gpc-binary script but was unsure if it would shorten the path so it would work if I copied to usr/bin as opposed to lengthening as if I had installed to /usr/local/cygnus.... So instead I decided to try to compile my own and attempted to follow the compiling instructions from the Website for gnu-pascal. I used cvs from the cygwin site to get the gcc sources for Cygwin for the 3.2.1 release and then I downloaded the gpc sources from website for gpc-20021128 which is supposed to work with gcc-3.2.1. I then created the symlink for p as described in the instructions and then I created a build directory and from there I ran the configure line and the make line as documented. I think I have done everything correctly but after compilation I am still not sure I have all I need. If in my build directory I do a find for gpc - I have the following: /usr/develop/obj $ find ./ -name "gpc*" -depth -print /gcc/gcc/p/gpc.o /gcc/gcc/p/gpc-common.o /gcc/gcc/p/gpc-decl.o /gcc/gcc/p/gpc-lex.o /gcc/gcc/p/gpc-typeck.o /gcc/gcc/p/gpcpp.o /gcc/gcc/p/rts/gpc.gpm /gcc/gcc/p/rts/gpc.gpi /gcc/gcc/p/rts/gpc_sp.gpi /gcc/gcc/p/rts/gpc_ep.gpi /gcc/gcc/p/rts/gpc_bp.gpi /gcc/gcc/p/rts/gpc_delphi.gpi /gcc/gcc/p/rts/gpc.o /gcc/gcc/gpc1.exe /gcc/gcc/gpcpp.exe /gcc/gcc/gpc-run This appears to be correct except that I don't see a gpc.exe like what existed in the binary install I did. I am really unfamiliar with pascal (I have often thought I would like to learn but...) but as I said I have an application I am trying to port to Cygwin and it has several pascal modules (originally from Borland Delphi) that I will need to compile. I see some warning but doesn't really seem to be any show stopper errors. Is anyone familiar with Cygwin enough to offer some pointers on compiling. Brian Keener bkeener(a)thesoftwaresource.com

3 8

ld.exe error...
by Dominique Louis 10 Apr '03

10 Apr '03

Hi all, During the compilation of a project using the DevPascal IDE and the latest release, I get the following error... C:/Progra~1/Borland/gpc/bin/ld.exe: cannot find -lsdl I gather that "sdl" is the DLL that ld.exe is looking for, but where should it be placed so that it can find it. The SDL exists in the System32 directory as well as int he same directory as the project and it still does not find it. I have not had a response to my previous emails, so am starting to wonder if I have broken some kind of protocol before posting here? Any clarifications welcome. Sincerely Dominique http://www.DelphiGamer.com := go on, write a game instead;

4 8

string utils
by Mehdi Khaldi 10 Apr '03

10 Apr '03

Hi, Are there utils to convert a String to integer, an Integer to String, etc...?

3 2

SizeOf sets (was: packed enumerated types?)
by Adriaan van Os 08 Apr '03

08 Apr '03

In the testprogram below, SizeOf( enum33) returns 4, which seems to me to be a bug. Regards, Adriaan van Os ---------- program test; type enum08 = ( a01, a02, a03, a04, a05, a06, a07, a08); enum16 = ( b01, b02, b03, b04, b05, b06, b07, b08, b09, b10, b11, b12, b13, b14, b15, b16); enum17 = ( c01, c02, c03, c04, c05, c06, c07, c08, c09, c10, c11, c12, c13, c14, c15, c16, c17); enum32 = ( d01, d02, d03, d04, d05, d06, d07, d08, d09, d10, d11, d12, d13, d14, d15, d16, d17, d18, d19, d20, d21, d22, d23, d24, d25, d26, d27, d28, d29, d30, d31, d32); enum33 = ( e01, e02, e03, e04, e05, e06, e07, e08, e09, e10, e11, e12, e13, e14, e15, e16, e17, e18, e19, e20, e21, e22, e23, e24, e25, e26, e27, e28, e29, e30, e31, e32, e33); set08 = set of enum08; set16 = set of enum16; set17 = set of enum17; set32 = set of enum32; set33 = set of enum33; begin writeln( 'SizeOf( enum08) = ', SizeOf( enum08)); writeln( 'SizeOf( enum16) = ', SizeOf( enum16)); writeln( 'SizeOf( enum17) = ', SizeOf( enum17)); writeln( 'SizeOf( enum32) = ', SizeOf( enum32)); writeln( 'SizeOf( enum33) = ', SizeOf( enum33)); end.

2 2

grx and gpc problems
by Toby Ewing 06 Apr '03

06 Apr '03

Hi, all Trying to compile a program, I suddenly see: > Internal GPC problem: internal option '--amtmpfile' not given I had compiled the program successfully a few minutes earlier. I get this problem with every program that USES GRX that I attempt to compile. But When I attempt to compile a program that doesn't USE GRX, I see > cannot file -lgcc Any guesses? GPC was working fine for me a few weeks ago. I'm using 2.1 (20020510) based upon 2.95.3 (20010315), under win2000, installed only a few months ago. thanks, Toby

3 2

gpc-20030323 for Mac OS X
by Adriaan van Os 06 Apr '03

06 Apr '03

Updated sources, binaries and patches for Mac OS X can be downloaded from <www.microbizz.nl/gpc.html>. Regards, Adriaan van Os

1 0

Time functions in gpc.pas
by Markus Gerwinski 05 Apr '03

05 Apr '03

Hi folks, does somebody know a way to get the TimeZone from the system? In gpc.pas, the procedure UnitTimeToTime wants it as a parameter, so I want to fill in a reasonable value. Besides, the function expects parameters named DST, TZName1, and TZName2. Can somebody tell me what they mean and how to find reasonable values for them? Thanks, Markus

4 6

Solver
by Cyelee Kulkarni 05 Apr '03

05 Apr '03

I'm using solver to integrate three eqautions. I want the output as a list of numerical values... how do I do this?..... Also, I'm having trouble opening files with an .mx extention, is this a common problem and is there any way I can open this file? Thanks! --------------------------------- Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more

1 0

Operator overloading
by Frank Heckenbach 04 Apr '03

04 Apr '03

Up to now, GPC supports overloading of binary operators like `+' and user-defined operators such as `Foo', but also only as binary operators. I propose to extend and generalize this mechanism, e.g. to unary operators. Besides the usual unary operators like `+' and `-', you can define your address operator as `@' (BP compatible) or `&' (like in C) or whatever you prefer. Also other C operators like `++' can then be easily defined without the need to have them built-in. A special case would be the `^' operator since it's used both prefix (in pointer type definitions) and postfix (in pointer dereferences). I'm still thinking about the syntax for the operator declarations, but `operator ^ (...)' and `^ operator (...)' would seem to be the most obvious choices. Some time ago, someone asked for backslash interpretation in string literals. Redefining the `'' (i.e., single quote) operator would make this easy. Also, the BP operators `#' and `^' (as in `^C') for character constants could be defined in a similar way, without messing up the syntax when they're built in. The same applies to BP's `$' for hex integer constants. But, OTOH, friends of the C syntax could define `0x' for hex and, if they like, they could even define the `0' operator for octal constants. Those who've always complained about Pascal's verbosity, could finally define the `{' and `}' operators as `begin' and `end' (preferably after defining the comment operator to `(*', `//' or whatever they prefer). And those who would prefer `;' as a statment terminator (as in C) instead of a statment separator can simply redefine this operator. Back to binary operators, apart from `:=' (as recently requested), also `,' would be a very interesting one. We could have all the interesting properties of this C operator in Pascal. Overloading `[' (for self-made arrays) and `.' (for records/objects) would work like in C++, of course, and can probably be used to implement Delphi-compatible object properties without further compiler support. Perhaps we can even define `class' as an operator (that inherits from `object', and `^') to provide for classes with implicit references. The `_' operator could be defined to be rejected in identifiers in classic Pascal (so we don't need the explicit compiler checks we have now), whereas, e.g., international letters can be allowed in identifiers by defining them as new operators. Overloading the `if' operator could be useful to make a new conditional syntax -- perhaps with `endif' to avoid problems with dangling `else' etc. By overloading `const' to `var' for typed arguments, BP's "typed constants" could be supported without any contortions in the compiler. Finally, overloading the `operator' operator seems very interesting, but I'll have to work out the details. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

6 9

Use of external and attribute keywords
by Dominique Louis 04 Apr '03

04 Apr '03

Hi All, A few of questions 1. When using the "external" keyword in GPC, do you have to specify the "name" keyword or does it default to the function name like in Delphi? 2. When defining function pointers, the Gnu Pascal compiler complains if I specify attribute(cdecl); For example type TSDL_Mixer = function( param1 : PSDL_Sound; param2 : Pointer ) : integer; attribute( cdecl );// <--- I get a compilation error here How do I specify the calling convention of a function pointer in Gnu Pascal? 3. If I have installed the Dev Pascal IDE how do I update to the latest snapshot so that I can start using the new keywords. Thanks, Dominique http://www.DelphiGamer.com := go on, write a game instead;

1 0

attribute const: no warning?
by Eike Lange 03 Apr '03

03 Apr '03

Hi Folks! By Compiling the following program with the given unit, the compiler throws no warning but fails running. program Foo; uses MySQL; begin WriteLn (MySQLOptConnectTimeout); MySQLOptConnectTimeout := 100; WriteLn (MySQLOptConnectTimeout); end. { ======== } unit MySQL; interface var MySQLOptConnectTimeout: Integer; external name '_p_MYSQL_OPT_CONNECT_TIMEOUT'; attribute (const); implementation {$L mysqlc.c, mysqlclient} end. _p_MYSQL_OPT_CONNECT_TIMEOUT is defined as "const int" in a C file. What do I have to do to make GPC throwing at least one warning like "accessing read only variable". BTW: Is mixing of attributes allowed like this: MySQLOptConnectTimeout: Integer; external; attribute (const, name ('_p_MYSQL_OPT_CONNECT_TIMEOUT')); Eike

3 3

Locale Directory
by Eike Lange 03 Apr '03

03 Apr '03

Hi Folks! I'd like to improve the facilities of our `intl' unit which interfaces GNU Gettext. There is one little problem with it: The user of this unit might not know where to install and retrive the locale informations, needed by `BindTextDomain'. * A common place under Unix like systems might be /Executable-Path-Without-Bin/share/locale which is well defined for Linux. * What about DJGPP, MinGW, CygWin, MacOS, ...? Are there common rules to find the locale directory? As a reference source code for this problem, you might want to have a look at `gettextdemo.pas'. Thanks for your help Eike

4 6

Re: gpc-20030323 - compiler crash
by Prof A Olowofoyeku (The African Chief) 31 Mar '03

31 Mar '03

Hi Frank [...] > Never say impossible ... > > program Chief44; > > uses Chief44u; > > type > TMemoStrings = abstract object (TStrings) > end; > > begin > WriteLn ('OK') > end. > > unit Chief44u; > > interface > > type > TStrings = abstract object > procedure foo; abstract; > end; > > implementation > > end. > > --- p/gpc-decl.c.orig Tue Mar 25 13:33:12 2003 > +++ p/gpc-decl.c Wed Mar 26 08:48:09 2003 [...] Unfortunately, while the patch works for the test program that you have created (above), the problem still exists with my code, and I still get precisely the same error as before. I have been trying hard (without success) to reduce the problem to a small program, but I have no idea what to look for, or what could possibly be the matter. Perhaps it could relate to lots and lots of sub-classing? Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

5 15

no EOF in untyped files?
by Eike Lange 31 Mar '03

31 Mar '03

Hi Folks! I've problems in one of my programs using untyped files. EOF does not work as expected: program Foo; var f: File; i, v: Integer; begin Assign (f, 'foo.dat'); Rewrite (f, SizeOf (Integer)); v := 101; for i := 0 to 10 do BlockWrite (f, v, 1); Close (f); Reset (f, SizeOf (Integer)); while not EOF (f) do begin BlockRead (f, v, 1); WriteLn (v) end; Close (f) end. The output is _not_ 11 times 101 as expected but six lines garbage. Replacing the while-loop with a for-loop (0 to 10), all works fine. What do I wrong? I'm using gpc 20030323 with gcc 3.2.2 Eike

2 1

Happy Birthday GPC
by Frank Heckenbach 31 Mar '03

31 Mar '03

According to the ChangeLog, Jukka Virtanen started implementing GPC exactly 15 years ago. Time for a little celebration! :-) Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

3 2

Re: gpc-20030323 testsuite
by Prof A Olowofoyeku (The African Chief) 27 Mar '03

27 Mar '03

Hi Frank [...] > > "./test_sum" | tee test_summary ./test_run: fatal: > > `--print-needed-options' yields: ./test_run: /mingw/bin/gpc: Invalid > > argument Nothing was run." > > Looks like an installation problem. What happens if you insert > > echo "$PC $PFLAGS --print-needed-options dummy.pas" >&2 > > in test_run before the needed-options stuff, and execute the command > that is shown manually (or from bash)? I get nothing. No errors, no output - just nothing. Looking in the directories in which I am building GPC, I see files called "needed-options" in the p/rts and p/utils directories, of zero bytes in size. I believe that this file has always had zero bytes, but that has not been a problem until now. > Is /mingw/bin/gpc the GPC executable? Yes. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

2 4

memory allocation with gpc
by Mehdi Khaldi 26 Mar '03

26 Mar '03

Hi, I'd like to know if memory allocation routines (ie : New, dispose, etc....) use malloc, free... C routines or if they use their own implementations. Thanks

1 0

Post GPC2.1 release problems
by Wood David 25 Mar '03

25 Mar '03

Hi, Just a short note to say that I've not had much luck compiling our software with the two 2003 gpc alpha releases. Everything works fine with the 2.1 release. Running gpc20030209 built with the gcc 3.2.1 backend, I got a segmentation fault whilst compiling one of our modules (no prior errors/warnings to indicate what may have caused it). Running gpc20030323, again built with the gcc 3.2.1 backend, the segmentation fault goes away but the compiler now hangs in an endless loop when I compile any module that uses a particular unit I have. Doing --debug-source seems to show the compiler hanging part way through each module, but I haven't found a pattern to the code which causes it to stop. I've now run the gpc20030323 i686 binary (built with gcc 2.95.3) and I'm getting a new gpc1 segmentation fault. This occurs when I do CASE i OF 0: Segmentation fault here BEGIN ... END; It occurred because integer i was no longer defined. The declaration was the no longer valid i : static integer which needed to be i : integer attribute (static); Admittedly, fixing this cured the fault and it appears I may be able to compile everything with this binary (I still have a lot of changes to make). However, a segmentation fault is a nasty way of exiting the compiler. I will do the code conversions to compile with this release (which you're right - I do hate) but the gcc 3.2.1 backend builds still seem fragile. Sorry I can't be any more specific about the bugs yet and I don't want to sound critical. I think gpc is in great shape thanks to all your efforts. The gcc3 step is no easy one to take as we have found in many other areas. Regards David Wood QinetiQ Farnborough The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

2 1

Pascal from C with 30020323
by Andrew Gregory 25 Mar '03

25 Mar '03

I've produced some Pascal which is called from C. The Pascal program looks like this: program myprog; {$gpc-main=Dummy} myfunc (parameters.. .) : integer; asmname 'name'; {$include "myfile.pas"} begin end. The function myfunc is given in the file "myfile.pas". To suit the new compiler 20030323 I changed the declaration above to myfunc (parameters.. .) : integer; attribute (name = 'name'); external; The compiler now objects to the re-declaration of myfunc. How can I get round this without editing myfile.pas (which is used by a number of other programs, so I don't want to alter it)? Andrew. ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Teddington, Middlesex, United Kingdom TW11 0LW. -------------------------------------------------------------------

3 2

Re: Pascal from C with 30020323
by Andrew Gregory 25 Mar '03

25 Mar '03

Apologies, I omitted the keyword Function in Function myfunc (parameters ...) etc. in my email. The problem of re-declaration of myfunc in included file still remains. Andrew. > -----Original Message----- > From: Andrew Gregory [mailto:Andrew.Gregory@npl.co.uk] > Sent: 25 March 2003 13:58 > To: 'gpc(a)gnu.de' > Subject: Pascal from C with 30020323 > > > I've produced some Pascal which is called from C. The Pascal program > looks like this: > > program myprog; > > {$gpc-main=Dummy} > > myfunc (parameters.. .) : integer; asmname 'name'; > > {$include "myfile.pas"} > > begin end. > > > > The function myfunc is given in the file "myfile.pas". > > To suit the new compiler 20030323 I changed the declaration above to > > > myfunc (parameters.. .) : integer; attribute (name = 'name'); > external; > > The compiler now objects to the re-declaration of myfunc. How > can I get > round this > without editing myfile.pas (which is used by a number of > other programs, > so I don't want to alter it)? > > Andrew. > > > > ------------------------------------------------------------------- > This e-mail and any attachments may contain confidential and/or > privileged material; it is for the intended addressee(s) only. > If you are not a named addressee, you must not use, retain or > disclose such information. > > NPL Management Ltd cannot guarantee that the e-mail or any > attachments are free from viruses. > > NPL Management Ltd. Registered in England and Wales. No: 2937881 > Registered Office: Teddington, Middlesex, United Kingdom TW11 0LW. > ------------------------------------------------------------------- > ------------------------------------------------------------------- This e-mail and any attachments may contain confidential and/or privileged material; it is for the intended addressee(s) only. If you are not a named addressee, you must not use, retain or disclose such information. NPL Management Ltd cannot guarantee that the e-mail or any attachments are free from viruses. NPL Management Ltd. Registered in England and Wales. No: 2937881 Registered Office: Teddington, Middlesex, United Kingdom TW11 0LW. -------------------------------------------------------------------

1 0

gpc-20030323 - Mingw binaries
by Prof. A Olowofoyeku (The African Chief) 25 Mar '03

25 Mar '03

Hi all I have uploaded Mingw binaries for gpc-20030323. These binaries are based on gcc-3.2.2. You can find them on the GPC server, in this directory: http://gnu-pascal.de/contrib/chief/win32/gcc-3.x/ The files are: gpc-20030323.i386-pc-mingw32.tar.gz (Mingw binaries) gpc-20030323-debug.i386-pc-mingw32.tar.gz (Mingw binaries, compiled with debug information). Note: these binaries contain "fixed" versions of system.pas and dos.pas Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/

1 0

[Fwd] Music programs/chord decoder
by Frank Heckenbach 24 Mar '03

24 Mar '03

The following was entered on the web user input forms (before they were removed, of course ;-). When answering, please note that the author may not be subscribed to this list. Therefore I've set the `Reply-To' (but those who let the list override their `Reply-To' might have to set it again). : From: <george325(a)twmi.rr.com> : : in 1980 i wrote a music program for a synthesizer to connect to a : computer. unfortunatly i did it in dos. about 1990 i completed the : job with chords and music notation. i never recoded it in windows. : i have about a dozen programs from others that allow me to play : the synth. unfortunaty none of these decode chords.i have now : retired and am looking for a pascal compiler to up date my : program. all of the video programming is lost to dos but the music : and chord decoder is still usefull. i hated boreland for dropping : pascal,i owned all 8 versions. before 1982 i used pascal z.which : was slow. i have tmtpl pascal which may do the job. any ideas are : appreciated george weible 734 464 1896

1 0

GPC 2.1 optimization bug
by Jan Kardell 24 Mar '03

24 Mar '03

Hi, I've run into a code generation bug with GPC 2.1. When I use optimization -O2, a calculation uses an uninitialized register. With -O1 the generated code looks very different, and it works. Compiler: Binary distribution of gpc 2.1 downloaded from http://www.gnu-pascal.de/binary/gpc-2.1-with-gcc.i686-pc-linux-gnu.tar.gz Computer: i586 running SuSE 7.2, kernel stock 2.4.17 I have not tried any newer versions of the compiler since i could not find binary versions and I do hesitate a bit to compile one myself. If binary versions of compiler snapshots where available, my guess is you would get a bigger testing audience. regards Jan Kardell MIDA Systemutveckling AB

4 3

Re: Conformant array curiosity
by Wood David 24 Mar '03

24 Mar '03

Frank, Thanks for your reply. I've managed to cut down the module to this very short module so I just get two errors, both - prior parameter's size depends on 'A': MODULE Test interface; export Test=(Test_proc); PROCEDURE Test_proc(List : ARRAY[a..b :INTEGER] OF DOUBLE); END. MODULE Test implementation; PROCEDURE Test_proc; BEGIN List[a]:= 2.3; List[2]:= 2.3; END; { Test_proc } END. The errors correspond to each assignment although the error line is the declaration. Sure enough, converting this to a unit fixes the problem: UNIT Test; Interface PROCEDURE Test_proc(List : ARRAY[a..b :INTEGER] OF DOUBLE); Implementation PROCEDURE Test_proc; BEGIN List[a]:= 2.3; List[2]:= 2.3; END; { Test_proc } END. Is the module syntax illegal or is it a bug? If it is a bug, at least you can take comfort in knowing it can kill the DEC Pascal compiler too! Regards David Wood, QinetiQ Farnborough The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

2 2

Re: TimeStamp?
by Frank Heckenbach 22 Mar '03

22 Mar '03

Peter N Lewis wrote: > >: - Data Type: struct tm > >: > >: [...] > >: > >: `long int tm_gmtoff' > >: This field describes the time zone that was used to compute > >: this broken-down time value, including any adjustment for > >: daylight saving; it is the number of seconds that you must > >: add to UTC to get local time. You can also think of this as > >: the number of seconds east of UTC. For example, for U.S. > >: Eastern Standard Time, the value is `-5*60*60'. The > >: `tm_gmtoff' field is derived from BSD and is a GNU library > >: extension; it is not visible in a strict ISO C environment. > > > >I think I could check for this field and use it where available. If > >this is present on Mac OS X (I hope so, since the field seems to > >come from BSD), this might solve the problem. > > Yes, the tm struct has this field. It looks to me like you should > call localtime to get it as otherwise it might not initialize the > timezone stuff. Yes, localtime is called, anyway. > >The descriptions also made me aware of the sign issue (which I > >hadn't considered before). Which sign is the "correct" one? > > Correct timezones are positive east. We are at +8 hours, the USA is > roughly -8 hours. > > This is the first I've ever heard of anyone doing positive timezones > going west. > > http://www30.cds.ne.jp/~yukinaka/eureka/library/articles/etc/timezone.html > http://www.zill.net/pgdocs/timezones.html > etc Thanks for the references. I'll change it (even if it means another incompatible change). Gale Paeper wrote: > There is a `tm_gmtoff' field in <time.h>; however, it is just a struct > field in a type declaration: > > struct tm { > int tm_sec; /* seconds after the minute [0-60] */ > int tm_min; /* minutes after the hour [0-59] */ > int tm_hour; /* hours since midnight [0-23] */ > int tm_mday; /* day of the month [1-31] */ > int tm_mon; /* months since January [0-11] */ > int tm_year; /* years since 1900 */ > int tm_wday; /* days since Sunday [0-6] */ > int tm_yday; /* days since January 1 [0-365] */ > int tm_isdst; /* Daylight Savings Time flag */ > long tm_gmtoff; /* offset from CUT in seconds */ > char *tm_zone; /* timezone abbreviation */ > }; > > So, in brief, on Mac OS X, the only thing available in <time.h> or > <sys/time.h> to get a valid value for TimeStamp's timezone field is one > of the available, appropriate function calls. Since I don't have the > breadth of systems experience necessary, I don't know what to suggest > for a GPC solution. If it would help, Frank, I could send you copies of > the two Mac OS X hearder files in private e-mail. I think you see a problem where none exists. We do have such a structure (returned by localtime), so we can just use this field. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

building gpc
by Mehdi Khaldi 22 Mar '03

22 Mar '03

Hi, I am building gpc on solaris7. First of all, I configure like that " configure --disable-multilib" I use this option because, an error occurs with gcc. Gcc developers said that I must set this option. Then, I build with gmake command and I get this error : ../.././xgpc -B../.././ -I../.././p/rts -c -I. -W -Wall -Wpointer-arith -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -g -O2 --unit-path= ./gcc-core-3.2.1/gcc/p/rts --automake `cat needed-options` -DRTS_RELEASE_STRING="'`cat ./gcc-core-3.2.1/gcc/p/rts/rts-version`'" -DGCC_VERSION="'3.2.1'" ./gcc-core-3.2.1/gcc/p/rts/string.pas ./gcc-core-3.2.1/gcc/p/rts/string.pas: In function `NewString': ./gcc-core-3.2.1/gcc/p/rts/string.pas:674: internal error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate thanks

2 1

gpc building
by Mehdi Khaldi 21 Mar '03

21 Mar '03

Hi, I fixed the missed space in the patch file. Then I built the gpc compiler with the make command. It worked until an other error occured : /Home/Users/mkhaldi/workspace/gpc-build/gcc/xgcc -B/Home/Users/mkhaldi/workspace/gpc-build/gcc/ -B/usr/local/sparc-sun-solaris2.7/bin/ -B/usr/local/sparc-sun-solaris2.7/lib/ -isystem /usr/local/sparc-sun-solaris2.7/include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,-h,libgcc_s.so.1 -Wl,-z,text -Wl,-z,defs -Wl,-M,libgcc/sparcv9/libgcc.map -o sparcv9/libgcc_s.so.1 -m64 libgcc/sparcv9/_muldi3.o libgcc/sparcv9/_negdi2.o libgcc/sparcv9/_lshrdi3.o libgcc/sparcv9/_ashldi3.o libgcc/sparcv9/_ashrdi3.o libgcc/sparcv9/_ffsdi2.o libgcc/sparcv9/_clz.o libgcc/sparcv9/_cmpdi2.o libgcc/sparcv9/_ucmpdi2.o libgcc/sparcv9/_floatdidf.o libgcc/sparcv9/_floatdisf.o libgcc/sparcv9/_fixunsdfsi.o libgcc/sparcv9/_fixunssfsi.o libgcc/sparcv9/_fixunsdfdi.o libgcc/sparcv9/_fixdfdi.o libgcc/sparcv9/_fixunssfdi.o libgcc/sparcv9/_fixsfdi.o libgcc/sparcv9/_fixxfdi.o libgcc/sparcv9/_fixunsxfdi.o libgcc/sparcv9/_floatdixf.o libgcc/sparcv9/_fixunsxfsi.o libgcc/sparcv9/_fixtfdi.o libgcc/sparcv9/_fixunstfdi.o libgcc/sparcv9/_floatditf.o libgcc/sparcv9/_clear_cache.o libgcc/sparcv9/_trampoline.o libgcc/sparcv9/__main.o libgcc/sparcv9/_exit.o libgcc/sparcv9/_absvsi2.o libgcc/sparcv9/_absvdi2.o libgcc/sparcv9/_addvsi3.o libgcc/sparcv9/_addvdi3.o libgcc/sparcv9/_subvsi3.o libgcc/sparcv9/_subvdi3.o libgcc/sparcv9/_mulvsi3.o libgcc/sparcv9/_mulvdi3.o libgcc/sparcv9/_negvsi2.o libgcc/sparcv9/_negvdi2.o libgcc/sparcv9/_ctors.o libgcc/sparcv9/_divdi3.o libgcc/sparcv9/_moddi3.o libgcc/sparcv9/_udivdi3.o libgcc/sparcv9/_umoddi3.o libgcc/sparcv9/_udiv_w_sdiv.o libgcc/sparcv9/_udivmoddi4.o libgcc/sparcv9/unwind-dw2.o libgcc/sparcv9/unwind-dw2-fde.o libgcc/sparcv9/unwind-sjlj.o -lc && rm -f libgcc_s_sparcv9.so && ln -s sparcv9/libgcc_s.so.1 libgcc_s_sparcv9.so ld: fatal: file /lib/sparcv9/values-Xa.o: wrong machine class What is the problem? How to fix it? Thanks

1 0

patch problem
by Mehdi Khaldi 21 Mar '03

21 Mar '03

Hi, I try to build gpc on a solaris platform (solaris7). I use GCC 3.2.1 . The gpc version I want to build dates 20030209. When I execute the configure file, an error occurs : *** *** Detected GCC version 3.2.1. *** GPC 2.1 requires a patch to GCC to build with version 3.2.1. *** This patch will now be applied. *** Press ENTER to continue, Ctrl-C to abort. *** Malformed patch at line 67: patch: Second character must be a ' ' character. What do I do to resolve this problem? Do I fix the patch? Where is the patch? Thanks.

2 1

Preparedisposepointer eats time
by Marten Jan de Ruiter 20 Mar '03

20 Mar '03

Hi all, I got some trouble compiling a finite element program called charles. I used GNU Pascal version 20020910, based on gcc-2.95.2 19991024 (release). to compile the program with profiling using the switch -pg. Because the program took an unusual amount of time running, I made a profile. Profiling the run yields that Preparedisposepointer uses exceedingly long times. This is the result for a fairly small problem, used to get output for this mail. I have seen 95% time use for Preparedisposepointer, but lost that profile testing other versions of gpc, and I am not patient enough to regenerate it, now that this output also shows the problem: /hole 17 % gprof `which charles` | more Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 59.13 3.14 3.14 Preparedisposepointer 3.20 3.31 0.17 _p_read_longreal 3.20 3.48 0.17 _p_trim ... (sorry for the crappy lay-out) Charles, compiled by an older version (see below) of gpc (seems to) works fine, but suffers from a memory leak in the file-io routines. (older version of gpc) /hole 20 % /usr/tm/bin/gpc --version 2.95.2 19991024 (release) I was not able to locate the difference in the pascal sources that explains why Preparedisposepointer now needs so much time. However, I suspect FreeMemPtr^ (in rts/heap.pas) does some things. A colleague mentioned that it might be a lot of moving in memory to prevent fragmentation. I tried to create a test program that creates a linked list of integers and disposes it. Then the allocation and de-allocation times are similar in magnitude: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 44.07 1.30 1.30 1 1.30 1.30 pascal_main_program 15.93 1.77 0.47 _p_new 10.85 2.09 0.32 Preparedisposepointer 10.51 2.40 0.31 _p_dispose Using 8 % gpc --version gpc 20030209, based on gcc-3.2.1 does not change much: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 46.82 1.40 1.40 1 1.40 1.40 pascal_main_program 16.39 1.89 0.49 _p_dispose 13.04 2.28 0.39 _p_new 9.36 2.56 0.28 Preparedisposepointer 6.69 2.76 0.20 Addheaprange Still allocation and deallocation take similar times Now I have the following questions: Any idea why deallocation takes forever in the FE program as compared to allocation? Maybe the reason is that the data-structure is slightly more complicated than a linked list of integers ;-) How can I isolate the problem? What kind of feedback can I provide you with to isolate and solve the problem? Gpc 20030209, based on gcc-3.2.1 does not compile the FE program, but that is another story, which is in my next mail. Regards, Marten Jan

3 6

Re: Bug report request
by Frank Heckenbach 20 Mar '03

20 Mar '03

Marten Jan de Ruiter wrote: > I tried to do so, but could not locate a core. To verify core-dumping > abilities, I whipped up the program at the end of my mail, which ran > as intended, and produced a nice core. Sorry, I forgot, gcc-3 disables coredumps explicitly. Try the included patch. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

TimeStamp?
by Peter N Lewis 19 Mar '03

19 Mar '03

TimeStamp has a field: TimeZone : Integer; { in seconds } Can GPC not sometimes have 16 bit Integer? Because if so, that field would be too small. Should it be defined as Integer(32)? Hmm, the TimeZone on my system comes back as: TimeZone (in seconds): -1878692308 It should be +8 hours (28800). Enjoy, Peter. -- <http://www.interarchy.com/> <http://download.interarchy.com/>

3 5

Bug report request
by Marten Jan de Ruiter 19 Mar '03

19 Mar '03

Hi all, I got some trouble compiling a finite element program called charles, see my previous mail `Preparedisposepointer eats time' gpc 20030209, based on gcc-3.2.1 barfs on me with the following output: <cut> #progress# POST/post.p (29) #progress# ELEMENTS/initelem.p (79) #progress# ELEMENTS/TRIANG_TOOLS/triang_init.p (147) #progress# ELEMENTS/TRIANG_TOOLS/triang_init.p (218) #progress# ELEMENTS/BED/initbed.p (23) #progress# ELEMENTS/BUBBLE_BED/initbbed.p (24) #progress# ELEMENTS/BUBBLE_BED/initbbed.p (249) #progress# MATERIAL/clpt.p (21) #progress# MATERIAL/clpt.p (219) #progress# MATERIAL/clpt.p (289) #progress# MATERIAL/clpt.p (381) #progress# MATERIAL/clpt.p (434) #progress# MATERIAL/clpt.p (585) #progress# MATERIAL/clpt.p (723) #progress# MATERIAL/clpt.p (871) #progress# MATERIAL/clpt.p (1074) #progress# MATERIAL/clpt.p (1253) #progress# MATERIAL/clpt.p (1350) #progress# MATERIAL/clpt.p (1599) #progress# MATERIAL/clpt.p (1835) #progress# MATERIAL/clpt.p (1913) #progress# MATERIAL/clpt.p (2110) MATERIAL/clpt.p: In procedure `GINLE_compute_tangent_stiffness': MATERIAL/clpt.p:2262: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. gpc1: gpc exited with status 1 gpc1: gpc exited with status 1 gpc1: gpc exited with status 1 ~/CHARLES 11 % gpc --version gpc 20030209, based on gcc-3.2.1 Copyright (C) 1987-2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ~/CHARLES 12 % gcc --version gcc (GCC) 3.2.1 Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Now http://www.gnu-pascal.de/todo.html does not tell me much... What can I do to help you eleminate the bug (if it is a new one, that is) I am not sure, but I thought I installed a gcc-3.2.1 based gpc at home, which compiled the FE program charles OK. But that is not using the latest gpc source, nor the latest charles source. Regards, Marten Jan

2 1

External variables and constants
by Adriaan van Os 18 Mar '03

18 Mar '03

Is it correct that an external variable can be declared in GPC as follows: var eV: integer; external; asmname 'eV'; Is there a similar construct to declare external constants ('extern const' in C) ? Regards, Adriaan van Os

4 3

Conditional keywords
by Frank Heckenbach 17 Mar '03

17 Mar '03

GPC supports a number of keywords that do not belong to all (or any ;-) known Pascal standards/dialects. To relieve the resulting problems, there are currently 3 mechanisms: - If any dialect option (`--extended-pascal' etc.) is used, all keywords not belonging to this standard are deactivated completely. - Individual keywords can be disabled using `--disable-keyword'. - Some keywords are recognized only depending on context, so compiling a program that uses them as identifiers is still possible without any of the above options. However, the 3rd approach only works in some situations (and can never work perfectly, since at some points there would simply be syntactic ambiguities between certain keywords and identifiers). I think for some words it would be easier to recognize them as keywords only if they have no current meaning (as identifiers) in the program, rather than turning them on and off in certain syntactic places (which is quite error-prone and probably still has some subtle bugs). I'm not sure if this approach will work for all problematic keywords, but at least for some. So this will still work: program Foo; var Foo: static Integer; begin end. Also this: program Foo; procedure Bar; var Static: Integer; begin end; var Foo: static Integer; begin end. But not this (which works now): program Foo; var Static: Integer; Foo: static Integer; begin end. Do you think this would a problem? It should not affect the ability to compile, say, EP code without `--extended-pascal' *as far as* that's possible now, since EP code can't use `static' as a directive (and it can't use as identifiers what are keywords in EP). Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

5 10

Re: gpc with gdb
by Frank Heckenbach 16 Mar '03

16 Mar '03

mkhaldi(a)softaddicts.ca wrote: > I'd like to debug a pascal program. When I run it in gdb, I can't examine > the variables. I can examine my variables before running it in gdb. > > I put yet the compile options to have debug information. > So, what do I do to get the variables' value when I run my program in gdb... > Is it clear? No. Did you actually read my previous mail? I wrote: : PLEASE, try : to give some information with your requests! Like, the Pascal : source, and what you expected to get etc. ... I suggest you read http://www.chiark.greenend.org.uk/~sgtatham/bugs.html and http://www.catb.org/~esr/faqs/smart-questions.html very thoroughly. Before sending a request, read it again and imagine you're someone who doesn't know about your problem and see if you can make sense of your mail. Sorry, but if you can't take the time to write a proper request, don't expect anyone to take the time to help you. I'll ignore such requests in the future. And again, reply to the list, not personally. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

5 7

Download links were temporarily broken
by Frank Heckenbach 16 Mar '03

16 Mar '03

The download links on the GPC web page were broken for some hours, due to a mistake. Everything should be working normal again now. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

Unwarranted error
by Wood David 15 Mar '03

15 Mar '03

Hi (Frank), I'm just trying gpc20030209 with gcc 3.2.1 and I've got a new error since the 2.1 build: "reference parameter passing of variant record selector" I don't understand what's illegal and the syntax of this error message is hard to understand. I think it means "variant record selector cannot be passed by reference" I have a variant record where the selector is an enumerated type (eg. true / false). I have a procedure which reads the true / false string from a file and assigns the corresponding enumerated type to the selector. This fails because the selector is passed to my procedure as a VAR parameter. The workaround is to use a temporary variable for the enumerated type in the procedure call, and then copy it to the selector afterwards. This seems to be just a way of avoiding a previously legal construct in the first place. Any comment. PS. I'll look out for the dynamic array change in a future gpc release and let you know how the tests go. Thanks. David Wood QinetiQ Farnborough The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

2 1

Promised unit "paper"
by Grant Jacobs 14 Mar '03

14 Mar '03

Well, I promised that I'd write up a brief account of what I really meant. Unfortunately I'm going to have to let it slip a little as I am extremely busy. Hope this rushed effort make its clearer, not more confusing! Looking at it briefly, if anything its redundant as all this seems to have already been covered, but all the same... I did promise more examples, which I have to admit I'm out of time for... maybe another week. Anyway, on with the show. A. Layout. Basically identical to BP units: unit DemoUnit; interface uses whatever; <export declaration part> end. implementation uses whatever, somemore; <definition part> end. The difference lies in the way the elements are used, not the syntax. Because of this, I suspect if this were to be implemented, a compiler switch such as the one Chief suggested would be appropriate. No new keywords, Frank! ;-) There are no different types of uses clauses; they always do the same thing: import stuff. The difference is what happens once the stuff is imported. The implementation doesn't import the interface, it only checks against the interface's declaration part. So it has to import its own stuff for itself; more on that in a mo'. B. Independence of action of the interface and implementation sections Firstly, let's clarify the flow of information of interface and implementation sections as this seems to have caused confusion amongst some people. Conventional units effectively work such that the declarations in the interface are imported into the implementation section of the same unit. Here, interface exports all of its contents to other units. Its declarations are *checked* against those of the implementation section. The implementation section has its own definitions; it does not import those from the interface for its use. As a consequence, it does not import the uses present in the interface section. Right? You *could* have the declarations in the interface imported as in BP units, but I believe it works best - for these types of units - if the two are more-or-less independent, bar the checking of the declarations. If you do have the implementation import the stuff from the interface, you now are asking for trouble with the uses clauses. Each section separately imports (uses) any other units that they need. This isn't checked across the interface/implementation boundary; only the declaration part is. *Everything* in the interface is exported, including any imported units (via uses). One rule, no exceptions. The interface section is a container saying that "these things ought to be exported". Everything in the implementation section is private. An interface is free to import (and hence re-export) any unit it feels relevant. It could for example import a related unit which is not needed in the implementation of the current unit, but which is useful for the users of the current unit in some way. The interface section will, of course, have to import the units needed to satisfy the declaration part of the interface. This has the effect that users of the current units get these dependencies "for free". This can work well, provided that developers of lower-level units don't place a lot of things into the interfaces that really aren't needed to be there - which they ought not to be doing anyway. Put in another way: the current unit's interface looks after the "required definitions" on behalf of any users of the current unit by exporting those that are needed. (To do this with more control - a good thing I think - you really need the ability to import only subsets of an interface.) We've already discussed how this can shield higher-level units from re-organisation of code in lower-level units. The implementation is free to import units it needs that are not needed to satisfy the interface declaration part or needed by the user of the current unit. It could, for example, import units which are effectively private to the implementation of the current unit, such as one we decided to bundle all system-dependent elements into or a unit with some obscure internal manipulations which are necessary for the implementation but really ought to be hidden from higher-level units. Because of the way things work, there will almost always be a uses in both the interface and the implementation, unlike in BP units where you can use only only one uses in the interface section and rely on the implementation section picking this up. Having the uses in the interface imported by the implementation imposes restrictions on the interface and if you left things that way the idea of re-exporting interfaces of imported units would awkward. I think this is where some people's early complaints of "re-exporting everything" come from (i.e. they are thinking of a single uses in the interface section importing everything needed for both the interface declarations and the implementation. I wouldn't want all the stuff for the implementation section re-exported either and with the two uses you don't have to.). You really need the interface and implementation sections to be more independent and you need a uses clause in both (so that they are independent) to make this work well. You could mimick the equivalent of the BP uses situation, by allowing the result of a uses clause outside both the interface and implementation sections to be 'read-only' to both sections, but personally I think this could be confusing - ? (You might have problems if the interface and implementation are placed in two separate files - haven't got time to think about this right now.) I'm really not sure what to do about the possibility of a uses clause outside of both sections, but it strikes me as being inconsistent with the rest of the approach. While you could introduce an export clause of some sort, they aren't really necessary under this scheme and it seems easier on the programmer to just remember that everything in the interface is exported, including what is brought in through uses. Its a simple enough rule. And no new syntactic elements, Frank! (But perhaps some of the behaviour differences are annoying instead?) BTW, I don't have experience with use of several interfaces for one module as Frank mentioned in a earlier post (he says this is possible in EP). If anyone has any comments on this, I'd be happy to hear them. Not recommended in general, but on rare occasion useful - you can allow users to optionally relax the type checking across the interface/implementation barrier (comparing the implementation's definitions to declaration part of the interface) to allow explicit recasting of types for the rare occasions this is useful. This isn't possible if the interface is imported into the interface section. Not exactly a feature to rest a debate on, though ;-) The inheritance is the key thing; this is just a minor aside. C. Circular references. Skating out on thin ice here... If a unit's interface has already been imported, a re-importing of it is redundant (unless you allow importing only parts of an interface, but let's keep this simple for now). This ought to be able to break the deadlock -- ? Ditto for the initialisation code. I have to get back to work, so this is where I stop. Sorry... or perhaps you're grateful?! ;-) Cheers, Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 476 1820 (office, after 10am) PO Box 6129, or +64 25 601 5917 (mobile) Dunedin, gjacobs(a)bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents.

4 8

--pack-struct
by Adriaan van Os 13 Mar '03

13 Mar '03

We are running into a real problem while porting the Apple Pascal Interfaces to gpc. Consider the following record definition: type word16 = cardinal( 16); word32 = cardinal( 32); rec = record a: word16; b: word32 end; For binary compatibility, the size of the 'rec' type must be 6 rather than 8. Section 7.2.16 of the gpc manual reads as follows: "GPC by default aligns fields of records and arrays suitably for higher performance, while BP doesn’t. If you don’t want the alignment (e.g., because the program relies on the internal format of your structures), either declare the relevant structures as ‘packed’ (which BP also accepts, but ignores), or give the ‘--pack-struct’ option." Now, the problem is: (1) --pack-struct doesn't seem to be available as a source code compiler option. (2) adding 'packed' to records makes it impossible to pass any field of the record as an actual 'var' parameter. For these two reasons I have an urgent feature request, which is to make --pack-struct available as a compiler option that can be added to the Pascal source code. Regards, Adriaan van Os

7 20

Re: Pascal compilers for/from Apple [was: Promised unit "paper"]
by Tom Verhoeff 12 Mar '03

12 Mar '03

Adriaan van Os wrote: >Frank Heckenbach wrote: >> I might be a little confused about the Pascal compilers by Apple >> and/or for Mac, since I've never used one of them myself. > >Yes, it is confusing, so I have listed the Pascal compilers for >Macintosh that I know of: I miss the UCSD Pascal system that ran (very well) on the Apple ][. I believe it was based on Wirth's p-system, producing p-code. It had a text-based UI with menus. A typical prompt looked like Program-name: C(ommand1, C(ommand2, ...: Because almost all the system software was written in UCSD Pascal as well, the language had been extended with numerous facilities for writing efficient system software. Many of these Pascal extensions have survived in one form or another. We had a large group here in the Netherlands that did wonderful things with this system on homemade Apple ][ clones. These had been extended with 1 MB RAM disks (lightning fast). There were no hard disks at that time; only the slow 5.25" floppies for your OS, tools, and program and data files. I still have such a machine in my attic, but I have not tried to boot it in a very long time. Tom Verhoeff

6 6

Re: Dynamic array sizes
by Wood David 12 Mar '03

12 Mar '03

Adriaan van Os wrote: > > (1) What about this: get a pointer to the first array element > and then > clear sizeof-array-element * array-size bytes ? > > (2) With modern risc processors, the time delay for > operations on large > data sets is typically in memory stalls, not in processor > instructions. > Are your records densely packed or unaligned on the processor's > "natural" data bounds ? Did you actually try to zero the > array in a for > loop per record (with a low-level routine if you want) ? Did you > profile the software ? Thanks Adriaan (and Frank) for your comments. I'm pleased to say I've sorted out all my problems (and successfully converted another 15000 lines of DEC Pascal to gpc with approx. 2000 line changes to get around DEC specifics - mostly the use of x:= ZERO to clear anything). You're right - execution time wasn't the key issue. It was more to do with the fact that I had various records with > 10 components, each element having a unique array type. So working out the size of each record was tedious and zeroing with loops meant coding lots of sub-loops for the arrays within the records. I have effectively adopted approach (1), which is in line with the fact that my_dyn_arr^ points to the first array element already. But for simplicity, I support Frank's suggestion that in future gpc releases, my_dyn_arr^ points to the start of the whole schema so I can do `FillChar' on sizeof(my_dyn_arr^) and then `Initialize' . However, is it really true that a floating point 0.0 isn't always all zero bytes? Regards David Wood. The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

4 7

Re: gpc-20030209
by Prof A Olowofoyeku (The African Chief) 12 Mar '03

12 Mar '03

On 12 Feb 2003 at 05:45, Frank Heckenbach wrote: > > > But it should be possible with moderate effort to implement > > > something like > > > > > > export Foo = all (FileMode => GPC_FileMode); > > > > > > so one won't have to name all interface declarations, but only the > > > re-exports and renamings explicitly. > > > > Ok. I'd rather not touch any EP stuff (e.g., modules) at all. > > However, if that is going to be the only realistic option, then I > > guess it would have to do ... > > Even when QI will work sometime, I think export renaming is still the > better solution (shorter to write, and a little more efficient), so you > might as well get used to it. :-) > > As I said, the problem currently is that the syntax given above > doesn't work yet, but you'd have to name all regular exports in the > `export' clause as well. > > Any opinions (also from others interested) on whether I should add > this feature, and if so, with the syntax above or differently? I can't see many responses to this, so perhaps I am the only one who needs it. The syntax that you suggest above is quite fine by me. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/

2 1

gpc with gdb
by Mehdi Khaldi 11 Mar '03

11 Mar '03

Hi, I want to debug my pascal program with gdb. I can't examine my variables when I run my program in the debugger. Nevertheless, I compile with gcc -gstabs foo.pas and I got that : Line number 0 is out of range for "<implicit code>". list foo.pas:1 (xxgdb) p d $1 = 42 (xxgdb) break 5 Breakpoint 1 at $120002948: file foo.pas, line 5. (xxgdb) run Breakpoint 1, pascal_main_program () at foo.pas:5 (xxgdb) p d $2 = { i = {0, 1076887552}, d = 16 } How to get value at all the time???? Thanks

2 1

updated pascal editor
by Russell Whitaker 11 Mar '03

11 Mar '03

Hi About a year ago submitted a pascal editor to the list. Attached is an updated version. Most of the changes are in the search section. One improvement I think you will like: added a "Identifier" option to the search menu. This checks the character just before, and the character just after, (if any), to see if they are not in [ A..Z, a..z, 0..9, _ ]. Handy for searching for a short identifier in a long program. Enjoy Russ

2 2

"Result" as return value for operator?
by Peter N Lewis 11 Mar '03

11 Mar '03

It seems to me that there is a delphi extension where the variable Result can be used for any function return value. Eg: function sum( a, b: integer ): integer; begin Result := a; Result := Result + b; end; Given this, I expected operator to work the same way: operator + ( a, b: integer ): integer; begin Result := a + b; end; But this results in "parse error before `:'". I would think the above operator code should work given the Result extension. Would it make sense to allow this? Perhaps giving an error if the Result extension is disabled? Thanks, Peter. -- <http://www.interarchy.com/> <http://download.interarchy.com/>

2 1

GPC on Solaris 9
by Cserzo Miklos 06 Mar '03

06 Mar '03

Hi Folks, we need to install GPC on Solaris 9 (64-bit sun). Compilation stops at the rts part. Most probably due to the 64-bit architecture. Is there a protocol around this? Cheers, miklos

4 8

Range Checking
by Frank Heckenbach 05 Mar '03

05 Mar '03

Hi, after some friendly requests and discussion, I'm planning to implement range checking as one of the next major things in GPC (probably in Januaray, if nothing urgent gets in between ...). Note, I'm using "range checking" in the specific meaning I explained recently, not generally for all kinds of runtime checks, and not including overflow checking of arithmetic operations etc. (that will be a separate issue). Also, as I said before, I'll do an "easy" implementation. I'm still not convinced that anything more is worth the (big) effort when the programmer in the rare (AFAICS) cases where it matters could just as well use explicit types etc. to avoid checks where he doesn't want them. Since some of you have said they'd like to help, but can't code in the compiler itself, here are at least 2 chances: 1. Help finding all places where range checking must be applied In mean this from a Pascal point of view, covering, of course, all standards, dialects and extensions that GPC supports. So far I've found the following ones: - assignment to variables and function results, - value parameter passing to user-defined and built-in (e.g., `Chr', `FillChar', ...) routines, - array indexing (R/W), - array slice indexing (R/W), - `for' loop bounds, - conformant array range, - actual schema discriminants, - initialization of types, variables and typed constants, - `asm' targets 2. Write test programs Test programs should follow the guidelines in the manual. In particular, since most of the tests will check for errors, each one must be a separate test for each situation (each of the cases above plus any that others of you will come up with). For a way to test runtime errors see, e.g., fjf424d.pas. Range checking will be on by default, and can be switched on/off with the options `--[no-]range-checking' and the compiler directives `{$[no-]range-checking}', and `{$R+}', `{$R-}'. A complete set of tests should also test all of those. If you'd like to do so, please post a short note, so several of you won't duplicate efforts, but can coordinate. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

6 15

Prefix directives -> attributes
by Frank Heckenbach 04 Mar '03

04 Mar '03

Some directives in GPC are written in prefix form, in particular `static', `volatile', `register' for variables and `inline' for routines, e.g.: inline procedure Foo; var a: static Integer; Since this syntax is also more like C than Pascal, I'd like to turn them into attributes, thereby also making them non-keywords. E.g.: procedure Foo; attribute (inline); var a: Integer; attribute (static); I suppose `static' variables are `inline' routines are used to some extent (but hopefully not too much), the others should be negligible, so the amount of changes necessary should be limited. And since I'm doing the incompatible changes WRT `c', `c_language' and `asmname' now, it might be a good time to do them all at once. Any objections? Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

2 1

high comprehension
by Francois Schoubben 03 Mar '03

03 Mar '03

Continuing my tests on range check, i'm rtfm... On the HIGH keyword part, it's said that "For array types or variables of that type, @samp{High} returns the highest index a variable of that type can assume." Same for LOW. So, i'm expecting, in the example --- program highlow; var a : array[1..100]of integer; procedure hilo(ar : array of integer); begin writeln(LOW(ar),' ',HIGH(ar)) end; begin hilo(a); end. --- that it write 1 100 but it's currently saying 0 99 Why not, but, i think it's not what's said in the documentation... Am i still "out of the game"? Am i using a too old version?

2 2

Standard question: `New' with variant records
by Frank Heckenbach 03 Mar '03

03 Mar '03

Another standard question. Is the following valid: program Foo; type t = record case Integer of 1: () end; var v: ^t; begin New (v, 2) end. Some of GPC's test programs (not written by me) do something like this, but I doubt whether that's ok. As usual, the language of the standard (6.7.5.3 in EP) is somewhat confusing, so I'm better asking to be sure ... Another thing: The standard allows to set variant tags or schema discriminants in `New', but not both together. Is this an artificial restriction, or would there be some deeper problem with code like this: program Foo; type t (n: Integer) = record case Integer of 1: () end; var v: ^t; begin New (v, 42 { discriminant }, 1 { variant tag }) end. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

2 2

DLL Calling conventions and refering to external functions...
by Dominique Louis 02 Mar '03

02 Mar '03

Hi Eike and any one else who can guide me, When using a DLL or Shared object under Delphi or Kylix the headers tend to have function declarations as... function SDL_Init(flags: UInt32): Integer; cdecl; external 'SDL.dll'; where cdecl is the calling convention and the external key word allows you to specify in which DLL or SO, the function is to be found. Obviously in this case it is 'SDL.dll'. I noticed in Eike's port that he renamed the SDL functions to make them more Pascalised. Is there another way of achieving dynamic linking without going down the rename route? How does GNU Pascal dynamically link to DLLs and how are the Pascal headers defined? Thanks, Dominique. http://www.DelphiGamer.com := go on, write a game instead;

1 0

`external name'; dropping `c', `c_language'
by Frank Heckenbach 28 Feb '03

28 Feb '03

As another small step towards cleaning up the `external' mess in GPC, I'm now implementing `external name', i.e. procedure Foo; external name 'bar'; will be equivalent to procedure Foo; external; asmname 'bar'; `external name' is BP compatible, AFAIK. I'm not yet changing the fact that `asmname' implies `external' for routines -- this should be done, too, but I'd rather do it together with other incompatible changes later. However, unless there's heavy resistance, I'd like to deprecate the `c' and `c_language' directives, and drop them in a later release. So, procedure Foo; c; should be turned to: procedure Foo; external name 'foo'; What about a plain `external' without `name' or `asmname'? Currently, this keeps the "default" asmname (first letter uppercase, the rest lowercase). Some time in the future, we'll need name mangling (for qualified identifiers and overloading), so the default asmname will be something ugly which one should not have to know about in order to write interfacing C code or such. Of course, it would be possible to make `external' set the first-uppercase-asmname even then, but I'm not sure how useful this is. (Currently, it's chosen as the default to avoid linker conflicts with "usual" C routines, but with name mangling, this won't be an issue.) So, to me it seems more reasonable to make a plain `external' set the asmname to all-lowercase (just like `c' and `c_language' do now). Then, procedure Foo; c; can be turned to simply: procedure Foo; external; But a current procedure Foo; external; will have to be turned to: procedure Foo; external name 'Foo'; (or the corresponding C code turned to `foo' in lowercase, which I'd usually recommend -- since these routines are explicitly coded, you usually know that there are no conflicts with libc etc.). Another question is whether `asmname' should be dropped entirely. In external declarations (the most common case), it can be turned into `external name' as described above. But there are cases where you need to set the asmname of a non-external routine or variable. But perhaps we can just use `name' then, e.g.: var Foo: Integer; name 'bar'; (instead of asmname 'bar'). The advantage would be to have another non-standard (conditional) keyword less. Or we could even use `attribute', something like: var Foo: Integer; attribute (name ('foo')); (or `asmname' -- that doesn't matter since within `attributes' we don't have the problems of keywords, anyway). This way, `name' would not be a real keyword (only special after `external'), at the cost of a little stranges syntax. But while we're at it, I think the attribute syntax can be simplified to var Foo: Integer; attribute (name = 'foo'); (also for other attributes with parameters, and without changing the existing syntax -- there wouldn't be any conflicts). I think this could be an acceptable way (syntactically), so `asmname' can be dropped. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

8 18

SDL support in GNU Pascal...
by Dominique Louis 28 Feb '03

28 Feb '03

Hi all, Are there many people using GNU Pascal for game development? I am the project leader for the JEDI-SDL project ( http://www.delphi-jedi.org/Jedi:TEAM_SDL_HOME ) and my aim from the start was to provide Pascal bindings/headers for as many Pascal compilers as is feasible. Currently I support Delphi 4^, Kylix 1^ and FreePascal. I noticed that there is already a partial SDL conversion for GNU Pascal made by Eike Lange. I believe that my bindings are more complete at this stage and would like to incorporate support for the GNU Pascal compiler if someone on this list can tell me how I can make that possible. The latest JEDI-SDL ditribution, that shipped with Delphi 7 and Kylix 3, can be downloaded from http://www.sf.net/project/jedi-sdl/ . Any feedback would be greatly appreciated. L8R, Dominique http://www.DelphiGamer.com := go on, write a game instead;

2 2

Stupid Question
by Richard D. Jackson 26 Feb '03

26 Feb '03

When trying to use the Stringutils unit I've run into a issue. In that how do you determin the number of strings returned from the Tokenize funcions? For instance TokenizeString returns PPStrings but does not use a nil sentinal at the end of the array of strings. So with out the use of a nil sentinal how do you find out how many strings are being returned? The PPStrings are dynamicaly allocated so can't use SizeOf on it to get what I need. I know there must be a way to do it or the Tokenize routines would use a nil sentinal. I made a local copy of the routine I'm using and added a nil sentinal to it so I can get done what I need but I'm still wondering how you would do this. Thanks Richard

2 3

bootstrap broken in gcc-2.95.3 with new alpha
by Matthias Klose 25 Feb '03

25 Feb '03

Building the new alpha based on gcc-2.95.[34] using the bootstrap process fails with: make[5]: Entering directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc/ch' make[5]: *** No rule to make target `../cc1chill'. Stop. make[5]: Leaving directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc/ch' make[4]: *** [cc1chill] Error 2 It is necessary to build the CHILL language as well to see this failure. The same setup works using gpc-20020910.tar.gz. Comparing the build logs during configure you see the following differences: @@ -703,7 +697,7 @@ creating po/Makefile.in creating util/Makefile creating config.h -linking /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/texinfo/intl/libgettext.h to intl/libintl.h +linking /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/texinfo/intl/libgettext.h to intl/libintl.h Configuring gcc... loading cache ../config.cache checking LIBRARY_PATH variable... ok @@ -808,10 +802,10 @@ checking whether setrlimit must be declared... no checking for sys_siglist declaration in signal.h or unistd.h... yes checking if mkdir takes one argument... no -Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/config/i386/i386.c' to output insns. -Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/config/i386/i386.md' as machine description file. -Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/config/i386/linux.h' as target machine macro file. -Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/config/i386/xm-i386.h' as host machine macro file. +Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/gcc/config/i386/i386.c' to output insns. +Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/gcc/config/i386/i386.md' as machine description file. +Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/gcc/config/i386/linux.h' as target machine macro file. +Using `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/gcc/config/i386/xm-i386.h' as host machine macro file. checking for strerror in -lcposix... no checking for working const... (cached) yes checking for inline... (cached) inline @@ -847,8 +841,6 @@ checking assembler subsection support... working .subsection -1 checking assembler hidden support... yes checking assembler instructions... filds fists -Adjusting /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/p/Makefile.in for gcc>2.8.1 -Adjusting /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/p/Make-lang.in for gcc>2.8.1 Links are now set up to build a native compiler for i386-pc-linux-gnu updating cache ../config.cache creating ./config.status @@ -859,16 +851,7 @@ creating cp/Makefile creating f/Makefile creating auto-host.h -linking /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds14/src-native/gcc/intl/libgettext.h to intl/libintl.h -Merged x-linux. -Merged t-linux and i386/t-crtstuff and t-install-cpp. -Created `ch/Makefile'. -Merged x-linux. -Merged t-linux and i386/t-crtstuff and t-install-cpp. -Created `objc/Makefile'. -Merged x-linux. -Merged t-linux and i386/t-crtstuff and t-install-cpp. -Created `p/Makefile'. +linking /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/gcc/intl/libgettext.h to intl/libintl.h creating libintl.h Configuring etc... loading cache ../config.cache Here you see, that the t-linux files don't get merged and the ch, objc and p Makefiles are not created. So what's different/wrong? Removing the two patches in the gcc-2.95.3 diff to *** gcc/configure.orig Mon Apr 9 11:27:06 2001 --- gcc/configure Thu Nov 14 16:36:27 2002 and *** gcc/configure.lang.orig Thu Nov 14 17:05:00 2002 --- gcc/configure.lang Thu Nov 14 17:05:09 2002 correctly generates the other Makefiles, but then stops in the p sub directory: Bootstrapping the compiler make[3]: Entering directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc' make[3]: *** No rule to make target `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/src-native/gcc/p/Makefile.in', needed by `Makefile'. Stop. make[3]: Leaving directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc' make[2]: *** [bootstrap-lean] Error 2 The relevant change seems to be: 2002-11-14 16:59 Frank Heckenbach <frank(a)pascal.gnu.de> * config-lang.in: create a dummy Makefile.in if needed (can't always be avoided, it seems)-: ... So this does not seem to work (src != build in my case) * diffs/gcc-2.*.diff: patch the gcc configure to check if <language>/Makefile.in exists before trying to use it (code taken from the configure of gcc-3.1.1); similarly for configure.lang Tried to revert it. * Makefile.in: merged with Make-lang.in; file removed How to undo/revert this? Thanks for any help Matthias

2 1

help needed - build gcc-2.95.[34] based gpc-20030209 and CHILL
by Matthias Klose 24 Feb '03

24 Feb '03

I am trying to build gpc and CHILL using 'make bootstrap'. This leads to a bootstrap error pointed below. The same setup works well, if only enabling one of gpc or CHILL. Please could somebody try to reproduce this (my current setup is i386-linux / Debian GNU/Linux unstable)? I have no problems to build CHILL and gpc-20020910 together with the same setup. Thanks, Matthias cd ch; /usr/bin/make "AR_FLAGS_FOR_TARGET=rc" "AR_FOR_TARGET=` if [ -f /build/pa ckages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc/../binutils/ar ] ; then ec ho /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc/../binutils/ar ; else if [ "i386-pc-linux-gnu" = "i386-pc-linux-gnu" ] ; then echo ar; else t= 's,x,x,'; echo ar | sed -e $t ; fi; fi`" "BISON=bison" "BISONFLAGS=" "CFLAGS=-g -O2 " "CLIB=" "GCC_FOR_TARGET=./xgcc -B/usr/i386-linux/bin/ -B./ -I/usr/i386-lin ux/include" "LDFLAGS=" "LEX=`if [ -f /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds 15/build-native/gcc/../flex/flex ] ; then echo /build/packages/gcc/2.95/gcc-2.95 -2.95.4.ds15/build-native/gcc/../flex/flex ; else echo flex ; fi`" "LEXFLAGS=" " LN=ln" "LN_S=ln -s" "MAKEINFO=makeinfo" "MAKEINFOFLAGS=" "RANLIB_FOR_TARGET=` if [ -f /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native/gcc/../binutils /ranlib ] ; then echo /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build-native /gcc/../binutils/ranlib ; else if [ "i386-pc-linux-gnu" = "i386-pc-linux-gnu" ] ; then echo ranlib; else t='s,x,x,'; echo ranlib | sed -e $t ; fi; fi`" "RANLIB_ TEST_FOR_TARGET=[ -f ` if [ -f /build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/bui ld-native/gcc/../binutils/ranlib ] ; then echo /build/packages/gcc/2.95/gcc-2.95 -2.95.4.ds15/build-native/gcc/../binutils/ranlib ; else if [ "i386-pc-linux-gnu" = "i386-pc-linux-gnu" ] ; then echo ranlib; else t='s,x,x,'; echo ranlib | sed -e $t ; fi; fi` ] || ( [ "i386-pc-linux-gnu" = "i386-pc-linux-gnu" ] && [ -f /us r/bin/ranlib -o -f /bin/ranlib ] )" "SHELL=/bin/sh" "STAGE_PREFIX=stage1/" "exee xt=" "build_exeext=" "objext=.o" "exec_prefix=/usr" "prefix=/usr" "local_prefix= /usr/local" "gxx_include_dir=/usr/lib/gcc-lib/i386-linux/2.95.4/../../../..`echo /usr | sed -e 's|^/usr||' -e 's|/[^/]*|/..|g'`/include/g++-3" "tooldir=/usr/i38 6-linux" "gcc_tooldir=/usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux" "bindir=/usr/bin" "libsubdir=/usr/lib/gcc-lib/i386-linux/2.95.4" "datadir=/usr/ share" "distdir=../tmp/\$(subdir)" "localedir=/usr/share/locale" "CC=stage1/xgcc -Bstage1/ -B/usr/i386-linux/bin/" "CHILLFLAGS=" "CHILL_FOR_TARGET=cc" "CHILL_LI B=-lchill" "GNUCHILL_VERSION=1.5.2" ../cc1chill make[5]: Entering directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build -native/gcc/ch' make[5]: *** No rule to make target `../cc1chill'. Stop. make[5]: Leaving directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build- native/gcc/ch' make[4]: *** [cc1chill] Error 2 make[4]: Leaving directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build- native/gcc' make[3]: *** [boot_stage_c] Error 2 make[3]: Leaving directory `/build/packages/gcc/2.95/gcc-2.95-2.95.4.ds15/build- native/gcc' make[2]: *** [bootstrap-lean] Error 2

1 0

beautifier
by Mehdi Khaldi 24 Feb '03

24 Feb '03

Hi, Where can I find a beautifier for my pascal program? Thanks

1 0

Re: gpc-20030209 (capitalization error message)
by Tom Schneider 24 Feb '03

24 Feb '03

> So, what's best now, "varying capitalisation", "varying capitals", > "mismatched caps"? > "varying capitalisation" would be my choice > "varying letter-cases" may be clearer, and it avoids > the ambiguity on "cases" that started the discussion > Keep it short. Maybe "varying id letter case: <oldid> <thisid>"? > Perhaps "mismatched <oldid> <thisid>"? It has to be CLEAR which means things like 'caps' won't do because it is not obvious that this is an abbreviation. How about straightforward English: The capitalization of the definition <original> does not match <current>. or more tightly: Capitalization of definition <original> does not match <current>. This way there would be no question as to what the message means. I think that a few extra bytes for clarity is worthwhile. 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 (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

7 8

bug in new alpha
by Russell Whitaker 24 Feb '03

24 Feb '03

hi minwidth for strings in writeln is broken: program hello; begin writeln('hello':30, ' ':30, 'world'); end. The output should be 25 spaces in front of hello and 30 spaces between hello and world. Russ

4 6

Update for Mac OS X
by Adriaan van Os 24 Feb '03

24 Feb '03

Updated sources, binaries and patches for GPC on Mac OS X can be downloaded from <www.microbizz.nl/gpc.html>. Regards, Adriaan van Os

1 0

Accessing command line data
by CBFalconer 23 Feb '03

23 Feb '03

There is no provision in any of the standard Pascals for accessing command line data. The Borland clones provide an analog of the C/Unix world in Paramstr and Paramct. In PascalP I handled this with a system file, called cmdline, much like input and output. It was defined at the encompassing level 0 as a read-only text file, and held a single line. To access it one could use: reset(cmdline); cmdline^ get(cmdline); eoln(cmdline) eof(cmdline) read(cmdline, ch); read(cmdline, intvalue); (* etc *) i.e. absolutely no extensions to the standard system. Note that it could be reset multiple times, to restart reading from the beginning. Since it is a one line file after readln(cmdline) eof(cmdline) will be true. If cmdline is empty eof(cmdline) will be true immediately after reset(cmdline). Naturally the contents of that line depend on whatever shell launched the program. How are the chances of adding this to gpc. The line itself must already be there for the runtime to prepare paramstr and paramct. An advantage of this is that other systems can be source compatible. All the users need do is prepare a one line file, call it cmdline, and run the Pascal program. At the same time gpc users can still access an exterior file call cmdline, by simply defining it themselves. The 'extension' will only kick in when no "VAR cmdline : text" is in user scope. -- Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!

4 3

GPC into FreeBSD ports tree
by samir namér 22 Feb '03

22 Feb '03

has anyone tried to get gpc into the freebsd ports tree? it would be a great help when trying to install it... // samir namér --- "may the source be with you"

1 0

gpc and gcc-3.3
by Matthias Klose 22 Feb '03

22 Feb '03

I'm currently experiencing problems with gpc builds based on gcc-3.2.[23] on non ix86-linux architectures. These bugs are fixed in the current gcc-3.3 release branch. Did "somebody" already began updating gpc to work with gcc-3.3? Thanks, Matthias PS: Would you mind sending automatic testsuite results to this list for the various Debian architectures (linux, hurd and freebsd)?

1 0

gpc with *bsd
by Juha Korkiakangas 22 Feb '03

22 Feb '03

Have somebody have any luck to compile gpc-3.2.1 for freebsd. What options did you use, if any?

1 0

Web server moving
by Frank Heckenbach 21 Feb '03

21 Feb '03

Hi, the GPC pages are moving to a new web server. If everything goes well, you won't notice any difference, but if you encounter any problems, please drop me a note. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

Calling libraries from MingW GPC
by Silvio a Beccara 20 Feb '03

20 Feb '03

Dear Chief, I have one "strange" question: I have some libraries written for Qbasic under DOS: they are used to communicate, via RS232C, with a device which can read analogic and digital inputs and control relais and stepping motors. My question is: do you think it could be possible to link these libraries and write a wrapper unit to control the interface from within GPC in MingW/DJPP? If necessary, I can send you the binaries (the software isn't any longer sold nor supported ). Thank you, best regards Silvio a Beccara

2 1

Re: Dynamic array sizes
by Wood David 20 Feb '03

20 Feb '03

Frank Heckenbach replied: > > >>are particular Pascal structures that shouldn't be zeroed by this > > >>technique (apart from dynamic arrays)? > > > > Any kind of schemata, which include dynamic arrays ans strings > > Also files and objects. > > There is a built-in procedure `Initialize' to (re-)initialize any > variable, so you could theoretically zero out everything, then > initialize it again, but I'm not sure if I should have mentioned > this. ;-) In any case, you'll do some extra work (init, zero, init > again) ... > > But I agree, in this case I'd recommend a `for' loop, too. > > PROCEDURE zero(VAR param; ch : char; size : longint); asmname 'memset'; > > BEGIN > NEW( Test1, a ); > writeln(sizeof(Test1^)); > zero(Test1^,#0,sizeof(Test1^)); > END. > OK - that's helpful. My example was trivial, but in practice I'm trying to zero very large arrays of large records which I very time consuming with loops and type-matched assignments. So I do new(anyvar,x, y); zero(anyvar^,#0,sizeof(anyvar)); initialize(anyvar); .. and because initialize is a built-in, it doesn't need any declaring. BUT ... when I run with electric-fence I get a SIGSEGV in memset. Doing some experimentation, it appears that each dynamic array dimension uses an extra 4 words. So if I amend my zero function call as follows ... zero(anyvar^,#0,sizeof(anyvar)-8); ... the problem goes away. In this case, the Initialize() call doesn't seem to make any difference. Am I right in assuming that the dynamic array sizing is tacked on the end of the storage so deducting 4 words per dimension is the right approach? Is Initialize() only required after I've zeroed a string or a record containing a string? Finally, given that Initialize can very usefully take any variable as a parameter, it's a shame that it doesn't actually do the zeroing. Is there another built-in I haven't spotted that will do this without be having to explicitly worry about the number of dimensions the dynamic arrays have? David Wood, QinetiQ Farnborough. The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

3 2

Mingw binaries updated
by Prof. A Olowofoyeku (The African Chief) 20 Feb '03

20 Feb '03

Dear all Updated Mingw binaries for gpc 20030209 are available on the GPC server: http://www.gnu-pascal.de/contrib/chief/win32/mingw32/ There are binaries based on gcc-3.2.2, and gcc-2.95.3-6. Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/

1 0

linker issues
by David Hajoglou 20 Feb '03

20 Feb '03

To Whom It May Concern, I tried to locate any FAQ/manual information about the error I get but did not find any information. I installed MinGW and GNU Pascal on a windows machine and I can compile a program into an object file but I cannot go any further. When using gpcc the linker (ld.exe) fails with the following error: ========================== c:\MinGW\bin\gpcc test.p GPCC (Win32 (Mingw) build), v2.18: BP-compatibility shell for GNU Pascal. (c) 11th May 2002, Prof. A Olowofoyeku (The African Chief). Compiling PROGRAM "test.p" ... CFG file = c:\mingw\bin\gpcc.cfg Args = [gpc --automake -s --no-typed-address --extended-syntax --ignore-function-results --no-io-checking --no-stack-checking -O2 -march=i486 -mcpu=i486 -O2 -mcpu=i686 --executable-file-name test.p] \mingw\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw32\bin\ld.exe: cannot find -lgcc ========================== I tried to point at the local copy of ld.exe and this error occured: ========================== c:\MinGW\bin\gpcc test.p --L \mingw\bin\ld.exe GPCC (Win32 (Mingw) build), v2.18: BP-compatibility shell for GNU Pascal. (c) 11th May 2002, Prof. A Olowofoyeku (The African Chief). Compiling PROGRAM "test.p" ... CFG file = c:\mingw\bin\gpcc.cfg Args = [gpc --automake -s --no-typed-address --extended-syntax --ignore-function-results --no-io-checking --no-stack-checking -O2 -march=i486 -mcpu=i486 -O2 -mcpu=i686 \mingw\mingw32\bin\ld.exe --executable-file-name test.p -l ] \mingw\lib\gcc-lib\mingw32\2.95.3-6\..\..\..\..\mingw32\bin\ld.exe: cannot find -l--library=gpc ========================= The program (simple 'hello world' program) complies into an object file just fine with 'gpc -c test.p'. It would appear that gpc can find ld.exe but ld.exe is not responding correctally. I verified that the specs file is correct and tried both the install gpc and the patched gpc. Perhaps this is a problem with my MinGW install, however their mailing list archives are not functioning and I am unable to get any information from them. Below is my install details: -- *MinGW 2.0.0-3 *GPC 2.1 (GNU Pascal version 2.1 (20020510), based on gcc-2.95.3-6 (mingw special) *GPC fix1 (20 sept. 2002 patch) *Windows 2000 Prof (sp3) Any help or documentation would be helpful as I know nothing of this environment and am trying my best to learn it quickly. Regards, David Hajoglou ::David Hajoglou ::Systems Administrator, Department of Computer Science ::Saint Mary's University of Minnesota ::Phone :: 507.457.1415 ::Fax :: 507.457.1401 ::Office :: LaSalle 141C ::Email :: dhajoglo(a)smumn.edu

2 1

Re: Dynamic array sizes
by Wood David 19 Feb '03

19 Feb '03

It's still not that simple... 1. I've now found a variable with a single dynamic dimension (i.e.. an array of 432 byte mixed type records) which adds on 8 bytes for the dynamic size instead of the usual 4 (as I get for all the small record arrays I've tried so far). This makes choosing the correct area of memory to zero even more hazardous. How do I reliably calculate how much space has been added on for the dynamic size info. without meticulous trial and error? 2. If sizeof() reports a dynamic variable (e.g.. an array of 3 doubles) to be, say, 28 bytes, which we understand to be 3 x 8 + 4 for the dynamic size, the total size of the Pascal storage area is 28. So why should linking with efence produce a SIGSEGV anyway when using memset on this area? David Wood QinetiQ, Farnborough The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

2 1

Virus
by Maurice Lombardi 19 Feb '03

19 Feb '03

Hi all, I have received through gpc-announce a message containing a virus: WORM_KLEZ.H in file .pif It has been removed automatically by our mail system, but others should be careful !!! The subject was A IE 6.0 patch sender was bug-m4 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 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

Re: gpc-20030209 (capitalization error)
by Tom Schneider 19 Feb '03

19 Feb '03

> > A tiny bit of punctuation would help: > > foo.pas:42: Capitalization of identifier "<current>" doesn't match original one. > > foo.pas:17: The original capitalization is "<original>". > > Well, most other errors don't include puncutation, and no complete > sentences. So it would be unsystematic to make this one different. Sigh. Maybe it's time to start making them more clear? If not, how about: foo.pas:42: capitalization of identifier "<current>" doesn't match original one foo.pas:17: the original capitalization is "<original>" The quote marks would help. > > Note that I substituted 'original' throughout for clarity. (Surely > > you don't mean the *previous* one - the one that just preceeded? In > > that case it would yell for the third item in this series: Knifefish > > ... KnifeFish ... Knifefish. I would think it should only object to > > the second one.) > > No, sorry. Storing *all* capitalisations is extra effort. Since > someone who uses this warning is supposed to want uniform > capitalisation, I don't think the effort is worth it ... No, I thought that you would only store the first one ("original") and compare all later ones ("current") to that. Generally the first one is the definition, so this should work fine. In this case it WOULD only object to the second case. If, on the other hand, you store the PREVIOUS one, it would object to both the second KnifeFish AND the third Knifefish, even though that matches the original (first) definition. That could be rather confusing to someone. ("Why is it yelling at me for this one? It's right!") Hmm. I just realized that there is a question of scope here. Are you making a pushdown stack for this? var Knifefish ... procedure capture; var KnifeFish ... begin ... end; It should not object to this case. 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 (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

2 1

universal pointer
by Mehdi Khaldi 19 Feb '03

19 Feb '03

Hi, Is it possible to use universal pointer like void* in C? I have seen that there is a keyword "univ" with sun compiler. How to do to have universal pointer with gpc? thanks

4 5

A IE 6.0 patch
by bug-m4 18 Feb '03

18 Feb '03

Content-Type: application/octet-stream; name=wntw_title_maria[1].jpg Content-Transfer-Encoding: base64 Content-ID: <OHK7061bUs2> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAALgAA/+4ADkFkb2JlAGTAAAAA Af/bAIQACgcHBwcHCgcHCg4JCAkOEAwKCgwQEw8PEA8PExIOEA8PEA4SEhUWFxYVEh0dHx8d HSkpKSkpLy8vLy8vLy8vLwEKCQkKCwoNCwsNEA0ODRAUDg4ODhQXDw8RDw8XHRUSEhISFR0a HBcXFxwaICAdHSAgKCgmKCgvLy8vLy8vLy8v/8AAEQgAlQIwAwEiAAIRAQMRAf/EALwAAQAD AAMBAQAAAAAAAAAAAAAEBQYBAwcCCAEBAAMBAQAAAAAAAAAAAAAAAAEDBAIFEAABAwMBAggI CAkIBwYHAAABAAIDEQQFBiESMUFR0hMVVRaRsSKT0xSUB2FxoTJTc7M0gUJSI3Q1dTYXwWJy gjMkJdXhklS01ORl0aKEhZXF8bJDpMSltREAAgIBAwMBBwIFBQEAAAAAAAERAgMhEgQxQVFh cZGxwSIyE4Gh8EJSchTRYoIjMwX/2gAMAwEAAhEDEQA/APGuJfS+eJfVQoARccalY3Hz5a/g x1rTp7l4jj3jQVPBUqCCMinZrD3eByM2Lv8Ad9YgID+jO+3aOIqDUFCTjYuVxsV1g9LZPUMN 7Nj+j3cfH00/SP3TuUPBs28CEFL40K4XOxSDlEqFxVQQc0StEAqQBx7Fcag0vk9Ni0OS6Kl9 F00IifvncNPnbBRSdFMPlXK7LeB1zPHbx035XBja7BVxoFYah07kdMX4x2T3PWCwSfmnb43X cG2iEFVsXK+di5BQg5RcVSvGoByuKJxLlAEXAouUARcbOVcoAp0H9i34v5VB4VOt/wCxb8X8 qlko7URFBIREQBERAEREAREQBERAEREAREQBERAEREAREQBERAEREAREQBERAEREAREQBERA EREAREQBERAVQXofvJsrG1w2nJLS3igdNagyujYGF5oza+nCvPAvXZsPD7y9NYjqu+gtslio vV7i2nJBoABXyQTxcil9UCi1LZWcXu30/eQ28UdzK8iWZrQJH7HfOPCr3QdlZO0ti7028Ruh lA3pywdJSp2b1K0U/J6YxuZ03Z6Kx2ZtZMxhaPkaTSMkg7wrt5V027rDR1thNHG5jvcpJfsm uehNWRh54ContEkdT51hrHSWG1Fc2E+nYclK4jrC6lI3ySBsjDmHi+JRJfdnh7rUNvfWsjot N3Nv69JHwPY0cMQKx3vJIOs8k4GoL27f6oXp0uprDB22n7fKHdscjj/Vp5Bt6OoG0+Haph9h HgzY11oKS66kfpiBuHL+iF2KdMBWnSfMr8PzlodN6fj0Xks8+2pd46S0Zc28ch4Y6PO4/hry LOM90Ubb0X5zNmdPhwl9Y6T84Y61p+R8q2uYzeGtM7FhLm4ENrk8f0MNwSNwGpAqeKteNRGm jJPItW6us9SsgZa4a1xBgJLn21KyVHAd1jFZ+7/A4aWxyWqdQQm6sMSAW2vFJJSvlcoVfrDQ l5pFkM813BdwXbiIXQkk0G2rtlFd6TcP4aalYSAd5tBUVOwKW4WgLLH3ulPeQbjCjCRYTIRx Plsri2LfxOKSjI10WeJ0/wC7/Bw5vUVi3L5a9cRaWkn9kwM49oI+Qqo90BA1eC4gD1aepJpx BaW8ZjfePjRh2XsVjncRNIyGOY0ZLHUjZ/o4ElTBBGih0x7y8ddnHY2PB5+xZ0wEFOjkYOWj WeJXWstW2umbbE2d7hbXLOltRSS5pVm4AKCsb1VY/G2Purx19fZa+hus5eRGG0tbY79AfxnV ps/Au/JYaH3p4nG5HE30Fvf2URhurS4JBB2clfwbKKIXrBJ5dZzCfO287WCJst1G4MZwMBkB oPiXrXvF1nYYjInEz4G1yE0tsCLuanSDfBpwxk7PjXkFH4rKAOo99lOK02gmN3+heq6r0vF7 wIotW4DIW4DbYC4t5XFrmOjFaCm9Q/Gp7rQEFkOmfd1h7G7yeNjzWeyUfTCKanRRRkfzmvA4 eRdGSsNOa505eagwVgMRlcWN67tI6dFIylaigA/DQKbc42x95+HsJbC+htNQY6IQXFrOaB4G yo4T411XMGO922l8hi5b2K91BmG9GYYDVsUdKbTw/wDanbQh/uZz3W21rd6wtre8hjnhfHJW OVge0kDkK4xVtbP95EVo+GN9scg5hhIBjLanZuqHoLM22C1TZZC9O7bAmOWTh3GyDc3vwL0G DQdtjtTnWk2YtOoY5TeMeH1kNakNpSnCeVH1/QPuYfVFvbQe8Ca2hhZHbi8jaIWsAbQluzdC 9Fv9C4efUOQzl1ZGbH2EUZhxtpHTp5AK03Ix8ir8loW2zmohq+zzFp1JJKy6lkc+jmhhBeKf g5VNsfeDjMrm8phra+ONiuyGY3JbKdIBuV8sUoTwV4Vy50gI6rNmM1XKcLl9FS4SKUFttfxQ FpjIGwyP6KNVkOkcL7v7C5z2qbcZSYTmGwtDsjfQ7HkbRweBXfqOr8Q2S/1VrNsGLjBMbrUx mWQ8QAkipt/Cqi3yeP8AeThZdOX2RMGVtZjLj7q8IBmbUgdJ0YArQ8QUzAk67GbSnvMjuMZH iIsHm4ony2k1tTceGcT91sdfAuuwscJ7v9MwZvMYyLL5W/kLI45qdHGBXg3g7k5FeaD0FFpD Lm9zGRtZb+SN8drbQyVND89/l04lT+9B7ZNK4mhFRcSUAI/nqE9YWqY9DzfN5KLL5O4yENsy yZO7ebbRfMjFOAbAuYP7BnxfyquVjB/YM+L+VdPoSdqIigBERAEREAREQBERAEREAREQBERA EREAREQBERAEREAREQBERAEREAREQBERAEREAREQBERAEREBXNhlc2oFQeNfQgnBqAQeUGiu 49baoYwCTNZInjPrkx4/rV9d+tS9s5L2ub0qnUFELecGoBB+A7U6GcGoBB4a12+NXvfrUvbO S9rm9KnfrUvbOS9rm9KmoKMwzuNSCTyk1QxXBFCCRxCtVed+tS9s5L2qb0qd+tS9s5L2qb0q akQUXQT0pQ05K7PGjoLg03gTxCpqr3v1qXtnJe1zelTv1qXtnJe1zelTUkpDDcEBpBIHACdg XAiuACACAeEA7D8qvO/Wpe2cl7VN6VO/Wpe2cl7VN6VNSIKMQ3ANQCDyg0XHQTcO6a8tQr3v 1qXtnJe1TelTv1qXtnJe1TelTUQUboZ3GpBJ+E1KCGdpq0EHlBorzv1qXtnJe1TelTv1qXtn Je1TelTUQUXQSnbunwhciG4bwAj4jRXnfrUvbOS9qm9KnfrUvbOS9qm9KmogoRDK0ggEHlBC 5NvOTUtJPGahXvfrUvbOS9rm9KnfrUvbOS9rm9KmpJQ+ry/kn5Fz0E9KUNOSuxXvfrUvbOS9 rm9KnfrUvbOS9rm9KmoKIQT0pQgHhFdnjXHq8v5B+RX3frUvbOS9rm9KnfrUvbOS9rm9KmoK MwznhBIHBt4Fx6vL+SfkV7361N2zkvapvSp361L2zkvapvSpqRBR9DcVrQ15a7fGuTFcEUIJ HECf9Ku+/Wpu2cl7VN6VO/Wpu2cl7VN6VNRBQ+ry/kH5FMhBbE0EUIG0fhVl361N2zkva5vS p361L2zkva5vSpqSQUU7v1qXtnJe1zelTv1qXtnJe1zelUQCCind+tS9s5L2ub0qd+tS9s5L 2ub0qQCCind+tS9s5L2ub0qd+tS9s5L2ub0qQCCind+tS9s5L2ub0qd+tS9s5L2ub0qQCCin d+tS9s5L2ub0qd+tS9s5L2ub0qQCCind+tS9s5L2qb0qd+tS9s5L2ub0qQCCind+tS9s5L2u b0qd+tS9s5L2ub0qQCCind+tS9s5L2ub0qd+tS9s5L2ub0qQCCind+tS9s5L2ub0qd+tS9s5 L2ub0qQCCind+tS9s5L2ub0qd+tS9s5L2ub0qQCCind+tS9s5L2ub0qd+tS9s5L2qb0qQCCi nd+tS9s5L2ub0qd+tS9s5L2ub0qQCCind+tS9s5L2ub0qd+tS9s5L2qb0qQCCind+tS9s5L2 ub0qd+tS9s5L2ub0qQCCind+tS9s5L2ub0qd+tS9s5L2qb0qQCCind+tS9s5L2ub0qd+tS9s 5L2ub0qQCCind+tS9s5L2ub0qd+tS9s5L2ub0qQCCind+tS9s5L2ub0qd+tS9s5L2qb0qQCC ind+tS9s5L2ub0qd+tS9s5L2qb0qQCCind+tS9s5L2ub0qd+tS9s5L2ub0qQCCind+tS9s5L 2ub0q+ZtZahnhfBcZbISwygsfHJcyua9jhQseDJtBBSARO7d99JF4XcxO7d99JF4XcxaZFbt RXuZme7d99JF4XcxO7d99JF4XcxaZE2obmZnu3ffSReF3MTu3ffSReF3MWmRNqG5mZ7t330k XhdzE7t330kXhdzFpkTahuZme7d99JF4XcxO7d99JF4XcxaZE2obmZnu3ffSReF3MTu3ffSR eF3MWmRNqG5mZ7t330kXhdzE7t330kXhdzFpkTahuZmu7V9+XF4Xcxd9npLIX15b2McsLX3M rIWOeXgAvIaN783WlVfKw0/+vsZ+l232rU2oKzkyrdJQvkLG53Gh3wtvgPC6xondOHf6Lr3H FxNAGtviCfgpY0Vnb42ztGsblbn1a6udghdGSGsd+M558lpPEvubH2ONMssdyJ327N9rKtPz uDdLahYbcjIu1Z7fxJp/HN9tFK7tnVZe7bIZCc29nlMdJK0bzh/e2gD43WbQu+490+ZtWOfP ksc1rBVx3rp3B/RtSpelM/qe0uGMs8UJ7e9e0SXTmvIDK0rvh26KKfqbN6s9fmsW2ccmNru+ tNY4t3Dwlz2u2EIs2buqT6PT4mn/ABsTUzfx07+4xfdWA/NzmPO2myO/4RxbLBdLsDYMeWPz +PDhsLTHka8H7PXfAH2d/cW0T99pI3JDsrVS4cYBOZJGCTfad5jqPG0ULhUChR8rbaLxESmj Jejq2kit6ix4IBz+P8rg/N5Hb/8Ar13O0vbNibM7PY3ddsApfF/DxsFjvfIvuK1s47hssR9Y IJHRymjWnl2bVKuGyW15FkILZzJ9yjGyPMkb3EU321aD8QXa5MtKI9pWp8I6bLRJyMgis81j pXkVApet2f17IKNfaSyFje3FjJLC59rK+F7mF5BMZ3Tu/m6q/wALbyvHqlvaSWsryHyPYC4P A4Kg73H+BT9Qfr7J/pdz9q5XYrO0zC9hN3Faw+vUxPdu++ki8LuYry393dzPBFN67G3pWh5b 0ZNKivDUVUpbGw+42/1UfiCtaRWrMxH8Nbj/AG6PzZ56pJ9L3sNxLAJYiI3FlS4itDTkXrSx t/8Afbj62TxlQkg7My8Gl72a4igMsQEjgyocTSppyK7/AIa3H+3R+bPPU2w++2/1sfjC2SNI KzPPLj3d3MEEs3rsbuiaXhvRkVoK8NTRUfdu++ki8LuYvV7/AO43H1UniKxylJB2ZTY3Rt3k bgwunjiAaX7wBdwEDgo3lVl/DW47Qj82eer3Tn36T6o+Ni0ahpBWZ5rk9B3WPgEzLuOYl4bQ tLOEE1/G5FV92r78uLwu5i9J1H9xj+tHies2pSQdmVON0kLll5Nf3LoILKAXB9Vi9ZkcTNDb hoZJJbj/AOrvfOWh0/7rMdqSzffWWbniijkMThPYMa7eABOxt6/lU/T0NxKzKstn9DKLLebJ QO3d26tXu+dsOwLYaIspMdgn7zxLHcP9ZjkApvCXiI4qUWbkZHjhVf7F+Gu5qVp59TKfwNhJ AGedtNPuI/4tZq50Rg7a6ms5cvd9JbvdG9wx8W6S3ZsrkOBe4slIc2vKvHsq49cZEVB/PyEf hKzLk5J6rr4NuHjYr2i0xHZlWNH4FxAblr0kmgaMdEak8Q/xBSbzQGFsWMM2Zuekk29E3Hxl zf6Q9fps+NfVtdm3f09PKh2inD8anWTbvN3BFtRxftdM75rQFVl5eerW2NvlovXCwQtLTHRM g473e4fJXjbOPMXUJf5LZpccwRbx4G7zL55qfiV8/wBxYY/dObfu0+f6mwN/716D8itOhyWP ZZxWEcE08crJJt8uYSWkEcAOyiiakz2abmOrru6Y9lR08jmERxFw/s4Iw5po0cLnOqu8XKzW rLSb9EU24dHkrSitr6FbH7n8VLeyY6HU7JbyIb0kLLVj3NB/KDbw0+Ir4yfugt8dj7++bmzO +wtp7kweqtbvGGN8oYT608tru0+aV3utn2+Cytzgn+qWtkA592HPZv3EhDWiPy94uNeE7Apu TwsNiyV1m5xMeIyDr2QuJ6aR1hODJI4/OeXHhV2PNkdlOmqTUa9YKrceiVlu+2rfpKXQ8rwu PblsxYYt0nQi/uYrbpQ3f3OmkEe/u1bWleVbg+6/Fhu87N3Ib+y3D/8AKWS0d+92C/aVn9vG trp3U09jiMxm2zzXmRsY2Nc2+uHvi3p39H+bhB4hwuJVue967dq6z2K8GJZK3baW2Or6zP8A odUHuqsLkS9Fmrk9DE6ZwdjaEtBA8mt3wqHce7zDWzKvzVyZCAWwjGjfdU8QdegfKtjp+5vZ oRJd3D3XU9hczP3XbrA17A9rWM4fJI4Ssxc5R3WkMl04vdIAau4fJFFmy5+RWs0S09C7HxaX fXQp59JYK3O7Lk78P/JGOiJB/BkVdae91mI1LC9+N1E9r4j+cgmsA2Rvw0F2RT4iq9176zcv eQXHeIA4aknbRei6HgNteMc2F7DPG7eLqAMDaU+E1VdOXnbiyXrCLL8PHttar+1SUH8Bm8HX x9iH/FJ/AVlP1+a/oX/NL1ver8J5VxXjVy5GQy/iqeSfwFbX9fn2L/mk/gK3t8+xf80vXKni XFSn+RknsPxo/Kmax7cTmL/Ftk6YWFzLbdKW7m/0Mhj392rqVpyrTt0PiWwWr7nLXDJbi3t7 l0cdiyRjfWIY7gMD3XrC7dElK7oVFrH97s9+0rz7eRbO8k3Y7EcP+HY3/crdaslnWunkni4q Zb3V+iq2o8yiBD7u8TMN9mXugwEB0hx8e634/wC/1V/D7jIJ69DqDfApUix5QD/ta6rGVjoZ 4XuDekZ5NeUK70nfZHMNvbd87o8bbOpI2KrJJCxg39+Xa7c2DYKLN/kZdzUKF3JyYqK+1KPB Qz+5zG27ix+payD8RtjvGo5KXVFRzaFwkBeG5i6lDDTejx8ZBA4SK5AbFf22SkifkJpZSd4F rYwTuRx7TuRt+LZ8K5xcFxcwi7AY4PcCYpa0aziFBwqm3K5CtDVUuxqrw8SSdp3PsZ2bRGFg tBdzZW9Y11N1px0e84HkpkN35VJb7usKyw6xvs5Pjo3O3YorqxjbLJsrWNjL59Ve6mfdPx0p YGCBm6WujNXg/EODaq2cy3eF0tDKd+We4nlkkfVznbjwKuL612BW48+W0y16aEZOPx600Vt/ VudIPiH3W46a0mvW5m4bHBCLh7XWDA4sJ3aBovuH41EHu7xpLd3J3ro3CvTNx0ZZ+Fwv9i3U Fw4jNQtb861aGtbtr5TVQM3m1jqRXhaCR8i0Y1kyUmt61a6ymyvj4MOSrdpXs1MLqnAW+n7m 0itrp17FeW/rIkfD0DhSaa3LdwSyjhhr85US2PvGYY7zDsdSox22hqNt5eLHK6GoUz6mPIqr JdLom0vYbxERWGYIiv8AReKssznGWN+wyQOjkcWhxaatFRtaQgWpQItrkPd1fNz0dnYVdjLk mRtydoiYPnNeeNw/F5fCo+vNP4zASWEeNY5onZIZHOeXlxaWAHb8fEkona/cZJF6BpnR2Eu8 NbT5irb7KOk9To9zSGtaS3yWkA7GF21Y+HHOhzkeKvWkFt0y3mbwVHSBjqH4UkQ9PUr0Xpcu m9GHPd2hZ3LLqSPpG3DJCWNG6X7d5xpsHG3hVLpvS+OudV5DCZCtzb2ccpY5riwlzJI2AncP DRxqFEobWY5Fb4PD9b6ghxgB6F0p6WnFEwlz9v8ARFFe6z0zibDHw5TAgm3ZNJbXQ3nPo9ri z8Y7KOaR4FM6wIcSYtERCArDT/6+xn6XbfatVerDT/6+xn6XbfatUBdUWmSwuk7+V0uYvH3E jyA0QuLY4h82rqbNp4yszndP4/D2z5sdLJLHIQxkbiHbON28FttF6Yw9/h48zeve83Jc18FQ WPY1xG6Rw8S7MroVl2yQ4eb1Ytq6CxkFYjXi3yaheZbFyE9racOXST1KWxNb0n0+6NDP6KuJ 7zETYmG6bbzR7zWNlG9G5ruEU2bVKkxcuBsbhmRvt+Karo7eIbtXnhJ2k0VngNETWEU0eUDQ 6dvkCMmrHg13g/lWV1La5DHumtblznndIikcPnA8HlLmlXucqHL0fY1VvNOs+zoZzEhmSvJ3 yu3GQkyMB5AeBWwv7mzyEsYtDcwlv5skVG0Vrs4lmcZNNbb1DuOc4NIINT8C1LJJDIHPNC9u 4HVoBUcC45CrW8tSui9PUzVv9My02ZTpLm2yLpGt6Jr3nadoa13FVanMeqxNtbm2yPT2zWtD mneqx1Nu5VU19adXP32btyK7S52xp5SuyDK9BBdRTWzJm3Me4wEV3CfxmUWnHlT22rWr0iWY b1o902tV+hYWeQtHXrZBleiO5Sp36jh2bFbag/X2T/S7n7VyxFrbQXJihiY+O5c478jtjA0D iW31B+vsn+l3P2rltpk3/TFVtXZR18lLxqqnda25/wAz8eCvWysPuNt9VH4gsatlYfcbb6qP xBdMI71jb/77c/WyeMrZLG3/AN9ufrZPGUQYsPvtt9bH4wtksbYffbb62PxhbJGEdF/9xufq pPEVjVsr/wC43P1UniKxqIMttO/fpPqj42LRrOad+/SfVHxsWjUMLoVWo/uMf1o8T1m1pNR/ cY/rR4nrNqUcvqWOOvhjcfnLssMm7YBu6DukiS6touH+st5p2VrdP45jRutfBEQ3hpsqvPra Z1tis1NGBvss4t0OFR99sxtW5xFy99hjHyU3pIWudQUFd3kXnc3Sy0nT5m7jK3490fTMde/s L7fAc34wvGczcEZvJMFXONxIGtFSTt4gF686Xym8lRVZTEW8WMGVy8kbTeX97KIJCAXNiYS3 ySeU1WajT0fU28dfXp4M9p/T95dzh2SgdBA6OQxMlO498gadwOZ84NqtbjmQWWItmWzGMkZG GT7N3feNj9+m2tVFe6aV7ZoJA2eocSRvbeGnDsPIuyGSSOORkkrpi8FxMtCQ4/0QNiq5GPdV Quj6e01wlEeBgrz1nNxTNjZFjqOcXl3DM126RQ8VBXYshqK8F5lru6Dt5r3PewjbwHZw/EtE yyMEfRRyb0TtrIiButPKylCFR6ltmts/Xo2brmP6J7gAAWuFKn+sFbjqqqEoldizjpVyu9td 2mvSDR4+0trrQh3WCKPK3tv0gZRlQ2Rm9/8AKuchLGGZm3YKMbi8g2MnbsFrNxrtwkcb9D4S OcDo+mkmcCKg9GXkfKq6W8ivIco+OXpHR47IgkAUP9zn4wOJW4tbrv8AVWP0PPzxOTtLtouh 5vo797sF+0rP7eNXjLaOLAaibGHB3rFnDI08FTJI7yVR6O/e3A/tKz+3jWnx0brjS97KSZJL /NW8bjwbI2uk2f6y15v5X7TNxdFf9PmaTFOjbk7SNwAa6xnic4VA2xuAaafEs9dYmLMta6GU WlzFU27pK7p2/Nc4cHxq6Y+K2uIrkOdI2CIF7abrqvDwWgnhG1U014x0fQ2sTYYuA0JLj8az U5FVV1duvaJUmnG67dZ1LDDaYFi22yV3K27iad9xhFQ1/wDO+JbPTzpLzMeswy9LaxscPIa4 UceJ5JpVec4u7lxN/FdxPcYq0mjJNC08Oyqt5MtqLDXdzJirg2sV44XDD0bHMkaeBw6Rp4uR ZUnv3Np/oXvPX8LrSur01PX94H4KcS5qTs4AsnobV15qF09hlooxe27RIyaIbokZweUzbtHw LWHhVm7p/CMXeIOdvEuPhCbeDwfAuKmm3akw5+QPzDrH9787+0rz7eRarIuoLIDs3Gf7jbLK 6x/e/O/tK8+3kWlyrgDZjkx2MqR+g2y9DP8AYv7vkccNxkv/AGfNEm0JdNA2pbvua2o20qaV Wi09NDg8bnYRIZCyeeJr6UJc4Na2vxrLWkm7LA6u0PaflC6crkbiDJZGC3l/u09w6R7RQ1c0 8KzKrsl5TLM91S9b21gXbjGZnElrXGpI4afAthYwtisIJY2unhljY9rx88Eiu1eeS3Ek58sl 55CV6DpSbpsBA0EkxFzCOSh4FXzKpQ4jTwXU5iz5IrXakuvdnxfPYMdexNqJixri59G7rSa8 lBwKtLC6HTO8B5FlPM7krI4rq1VZXFl09+2VzrC+LG3EYG2NzdjXfEV02Gct8hcW1tPEIvVr dlnbBlTvtDqkmvASlKxROsQk9SvNmqtyto46MvYZ3x3WRcakPgIaOSlCoNlcPtnNmLauI8oO FHbfgKmtfHHczP3fzbhIAHCpAFNlG8KiQyWc7vz73DdJDSfJa74HOdRyswZ6KsOrjbrHX9Dr DZKsNaNLoZj3kOjfe4h0TOiYcdsZyf3y9qsatn7yRGL3ECGnR9WilDUffLyu341jFtUQo6Rp Pgw5Y/JaP6n8TeIiK4yhav3b/vPH9TL4llERhOHJqr3WGYsWZTCQyfmpLmYRzV8uJhe/fYw/ zvk4lcaxx8mUudM4+L59xDuVHECIt539VtSvPUUQTuPUs/mdK2WVtLW7fdsnwe50DLYNMTTu scAd7h8kAFVuq7GGTP4XUdl5VplJLcud/PDmFpP9JlPAV5+iQS7SewXOp5bXWQ0/c7vqN1Gx kbhVr2yvHk+WCD5R2Kn0ji5cPrrJWMrnPAtZHxyO2l7Hywua4njO3b8K83RNo3fE9C0TFbYe 0y2qshvMhY828bmgF1N8b+6Dw1cWgKbgZ9L5ixv9MYyW6PrrHz/3zdNJPJ8thbxhwDqfAvME SBu9Dsngltp5Ladu5LC50cjTxOad0jwrrRFJyFYaf/X2M/S7b7Vqr1Yaf/X2M/S7b7VqgLqi 50/JjtF4Vkd/cH1ucmVzCS47zuJreIK0xmrsbK91zLOd5u1kZBFfgqvLcrc3dzkHT3bg/pKO jc01aWH5u78FFLxzukkA3gI28NTSvxLLw+JfJnTtMzNv1PVz8jFjwOtUo29X5Pc8dlLXKxF9 ua0+cx3CAujI2TJG1LQ5vGCAR8qw2BvX2d9DJAS0ucGvBNQQTtXpT6OG0VB4QtvN4KTUaN9G eZwudZOY0nVdjMHSWEyTmyZC0aXxkGN8dY3D+sylR8apdYaVtbZsMmMc6Hfq1zKb1aDYVvQG NFBwKpzts2cRTB+6YiQG8R3lmz42sG11Tj4l18ivn3V0TPLrPS19GXx3TGTWr9rNpaQSfjKu cboqNpO+CWnb0bX0I+LeH8q0whexo3hQH8o1BXBJjZ6zERvt2FrXVFDsNGleLe1pctryka6c XHbsVh0riIg5k8AAeNu01Hw1Ys5qD9fZP9LuftXL0CGeBjGeshzqnhI3qV+HkXn+oP19k/0u 5+1ct/8A87Xf/wAfmUczEsaoko1f7FetlYfcbb6qPxBY1bKw+4231UfiC9FmRHesbf8A325+ tk8ZWyWNv/vtz9bJ4yiDFh99tvrY/GFsljbD77bfWx+MLZIwjov/ALjc/VSeIrGrZX/3G5+q k8RWNRBltp379J9UfGxaNZzTn36T6o+Ni0ahhdCq1H9xj+tHies2tJqP7jH9aPE9ZtSjl9Sb aMEuMzTNgrZs2kAj77Z7dqvsHmnXVxZY7omtEMRAex1a7g3SSNlK8Sq8AwSR5NjhVrrWMOB/ JN7ab3yK9hx1jYXkRs2lgdWprXi+FeXz2/yVX+1fE28aNjnyXV0Z3272W0gimP8AZyObvBp5 d3jVHknyQY+0bK4OkbKekeBQOO2rt3iqVbmSreXaNqotSyhllvDaIXNI4tpKy0U2foviehxu rGNlgFo+S4PQulkduVcDvgbA4U2ii7Jbi3Bo543XigPACfgKqorOBlu1z4ZzO4VrHTdFdvC6 i63Onb+bD2UcKdHJG4739Ld4/hXf1L1NUJ9Gy46eKMiOR43WijHnhdyKqywNxa3tvGS9m43c YPyh/Kvh9nNFbSPkAYN3yaPqGn+tQj8K68LIZ7FlSXOLwx7+GpB41KT7wctqrUOdS/tr3HY7 RunjfzxNt5BLG4vIpvOPzdvGFXzzWLrnM2+Lex1lFh70joTvRl5tJ941BIqpORs8ZNpia0vo 2yR2Mj5LKKtHB8pqXCh4iSqHAv8A7hmCKVdj8g0kEbKWc54F1hf/AGKJ1spnp40MeZ6X0Wu5 pmP0d+9+C/aVn9vGrN2YvbPDwYe0DI2MmdfMumbwl6Rw3NtdhFByKs0d+92C/aVn9vGrR0Vr JjnPaCRHG90W66tPKFN5beRZLbPeSjhx9c6THzL+4v2XGKtZIXOPSxgvc/Y4kbDwHlCp3TSR vYG/jcIpwpZv3sbbtptazb4V07wFyBWrgODaVi2w31ZdZx0JwLJBukUPGCpQuJpLSKzkJe20 3ugLjtaxxqWfFXgVc642bRwcPIvqG4eXtoOOgqoa6SiJ9DV6FuPV9TWr2benD4HgHgq2oPyL 1aQmu3YvDcBessM/YXkz+jgbcxh7gNgDjTiXuknDUDYudF1+By+qPgEn4E+RK7K7Vwaf6EnX pIPzDrH9787+0rz7eRaHLvO/aD/puL/3C2Wf1j+9+d/aV59vIr7NE79n8GOxlfYLZejn+1f3 fIq4n/pb+1nMEn9mOQjaqu4NJpvK3xvuAfwb23hUtj/IqDwBV8hDYxynb+EqvH0lEcx9DkVo CB8J+JafTufuMbYTQxW7LiNj98t3i15DvyeLZRZgHydvIp2KlZGJHkHpNgjkHAw/lO4t3lqm etbU+pTBnwXdbzXQ1Z1FLf201tc4+I20zd0MdKWyur+SxzeEFZKw6PHZOF16THHA+rzQlwHF sap73iWVhu2i7k27t0zyWNPE4n8ZVuSuYLmbdYd+doInl3dwOI4PJ2qrFRKrok0v48l2azvD s9U/Bq7Z0F3mmzxk+rXUJo8VaTs4fK4F13txLjrN9avc1wijIlJ2mpqabVHxFtJNFbvk/sPV 3RkcpXxBaz3FxMWzUt43t6SCQfijhPCaI8eKYdK2ju0Vu11qrOq8Ipte7+/g+kJc/qwbxcdt fXLzlWSWx94333EEUoMeafEL29WOW2n2VjwiG23L1k3qKp7yWH0cvgbzk7yWH0cvgbzldKKd r8Fsiqe8lh9HL4G85O8lh9HL4G85JQ2vwWyKp7yWH0cvgbzk7yWH0cvgbzklDa/BbIqnvJYf Ry+BvOTvJYfRy+BvOSUNr8Fsiqe8lh9HL4G85O8lh9HL4G85JQ2vwWyKp7yWH0cvgbzk7yWH 0cvgbzklDa/BbIqnvJYfRy+BvOTvJYfRy+BvOSUNr8FsrDT/AOvsZ+l232rVme8lh9HL4G85 S8VqzG2WUsryaOboraeKaQMa0uIY4OIAMjduxJQrVz0OL6W1udNYm5LhHJC6W2dIaVc0Heb5 Lfya0UewfNHGC4F7eJ4G0/6tfEoXQ6U3Gx9aZLcDt4jq6Hh+D/EVZQZHSUDd0XuSI/QoR/7g r+Lmpjb3Wdf3J5FbXqq1Shdi1x+SLJWE7Nxwd4CvQb7WVrHGxtv+dkIFaFeYNzWkRT+85L8N lD/mCvMZrbQGOjaJLXIXFwOGZ1vCPA03bgFoy8nDdpu26PRmfHhvWYrE+qNJNrC5aB+boeQ/ /AKoGspMhlrayeA9pfuvb84VPgXRde8PRlyx7DDfNDhsJtIHU/8Au1l4clpOC9F7DeZFsgkE rf7hCdoNe0Fh5WR3xuuONTXholab9j1i36KRxML2hrDtjcylPg8raFzMxrgHAMDq7NxwqfDu rKy+83SEjmyOiyAlb+O23gB/3tcu96WlHN3eivweCvqsO94fXV4luJyNYr7mvn0PQx58S+5x 7zUSgiOjTI00qG1B28nlVosLqD9fZP8AS7n7Vymt95mlxsd1g4DgpawA0+E+ubVl8rqvHXuT vb2CObormeWaMOa0ENe8vFQ2Th2rZwcWTHv/ACV2zHdP4FXOvjyLH+O26G50j4ktbGw+42/1 UfiC847yWH0cvgbzlf2/vBw0NvDC6G6cY42sJDI6VaKbPzq2towqr8GwWNv/AL7c/WyeMrv/ AIj4T6C6/wBSP0qoLnU+PluZpmRzBskjnCobWhNfykTQdX4Liw+/W31sfjC2S81ttT4+K5hm fHMWxyNcaBtaA1/KV/8AxHwn0F1/qR+lRtBVfg0d/wDcbj6qTxFY5Sbj3g4aa3mhbDdNMkbm AlkdKuFNv51UHeSw+jl8DeciaDq/BrNOffpPqj42LRrz7E6xxljcOmlinIMZYA0NJqSDxyDk Vt/EfCfQXX+pH6VG0FV+C21F9xj+tHics2uctrnE39s2GCG4a9rw+rmRgUAI4pTyqo7yWH0c vgbzkTQdX4Nfp90TGZN0oqwWrDTj++Wm38BV1Hdsluo4n/2jdrX0oCCORYPG60xuONyJbGW9 juouhdGJWwUAlinDt4sm44h+Kpo95GLaYqYe5pCCGjrCPgPEf7gvP5fHyZcqtWHXak9e6Zqw XpXG1ZOZlG/3qgfGqLU72iwuHSuDI27p4DvChG3jVEfefY77ZBiblrW8MYv4t0/HWwqo+T94 GGytu+2ucPcsZJTeMWQjB8k147EqvHxMlW9yWvqacfIx0Tl6v0NbZy2j7KLoLqJ4LQd0Paa+ E1C4daNd+ceZGg8AjBGz428PhWDOqNNFoYcPeeTsH+Ixf5eg1RgGNLY8bkI6jYWZSMU/B1fT 5Fb/AI1+kI7XMxrTX9DYyW0UMUkjW9HTgL6/94lTsy61N7ZZK2p0d/C179zY0vApXZsXnbtS adkA6bGZCU8Zfkoj/wC3UUlus8Oy1js+rsgbeB29DGclFRhBr5P+HKHxsnaCHy8bsnroaXUP rIw0txZmk8JG+0tDy+J2xw5dh2qr05N0WMyNvchzLmWwyVGFlAALG4dt5F8s94+KY0N6muXU 27zr+OvyWCinW+Ijtb2ODEXAnvYbqITzXrJNx11DJbufuts46gCTgquqYLp1mq+5NuddBl5W O9HVWs9Gko0llFo797sF+0rP7eNXNxYWdjpwXcTHNuJg5jnl3zhvfk15PgWcwuQbicxYZV0f TCwuYrnog7c3+hkEm5vUdStORWPWmltv+F5Gjq7OsoSBX/y1X5aWs6w+nVeTLx8tabp7l5FE I8fAQD5TG0HGdnH8Cgtb00r3BwqDQtJoNnxLsGsMA2CO36ovCyJoaCcjHU05f8PXSNT6bDzJ 1PeEnlyEP+XLM+PeZSXvLHmxtkgwnYZHBzRsDGjdAX1H88UFDxDj2BdI1bp4HZh7sf8AmEVP /wCeuW6w0+xwcMPeVH/UIv8AL1D4+TwvePzY/L9wuw11uxp8kl+9s4di98w9yLvCWF0CXdJB GanhqGgGq/P02qNOTvY9+JvWmOtA3IxU28v+HLU47312+MsIMdDg5HxWzdxjpL4F5A/KItAP kUPjZNOmnqcvNR+/wewg/hXFdvwryf8AjtF2C720f8KuD79YuwXe2j/hFD4uZ/0+86/NSe/u PO9Y/vfnf2lefbyK+zNOltANlcdi/wDcLZZjNZBuWzF/lWx9CL+5lueiLt/c6aQybm9RtaV5 FeS6mwVyLd13i7t88NtbWz3xX0UbHerQR2we1jrGQjeEdfnFbclXZQvMlOHIqWbfdQcg0by0 UG44SDwqV3j032Tff+ow/wCXLrdnNMPrvYq/2/8AUof8tVdMdkogcm6yNbe3odQBop2LYDHK 5zd9jSN5orV380fGo/XmmBs6qv8A/wBRh/y1d0GpdNwNcGYi9NSCHHIxVBHBQjHBL47WUL4l FVFk3qWMm8YtyIepN3aequaA5wrw1dtNPhWbbVkjxtAqfncKuTrHAvcHz4i8mlaKNkkyERcP Bjh8qhzZ3TE8xmdib8FwAoMjCBs+Dq1RTFZJp9/UsyNWiOxp8f6w60tYxLSB8MgaNvkvA4ar qxGMbA0zySb0j3ltATV38521VVrrLAWjmOiw94ejYYxvZGIgg8Z/w/hXfDr3BwCjMLck1J3j kI67f/AKViepF/qWjhkb3ibLrDVNT1aNv/jLxY5X2qM/b5+4tJbW1dZxWdt6sGSzCdx/PTT7 2+2KLjmpwKhV1VFarwkiAin9RZvs668zJzU6izfZ115mTmqQQEU/qLN9nXXmZOanUWb7OuvM yc1AQEU/qLN9nXXmZOanUWb7OuvMyc1AQEU/qLN9nXXmZOanUWb7OuvMyc1AQEU/qLN9nXXm ZOanUWb7OuvMyc1AQEU/qLN9nXXmZOanUWb7OuvMyc1AQEU/qLN9nXXmZOanUWb7OuvMyc1A QFIswDdwNcAQZGAg8FCQu/qLN9nXXmZOavtmEzrHB7cddhwNQRBICCP6qA9MlscbkNURxwxQ XLcbqEW1w02kdsIreWSSOO1G4NyeOsfC815BtKocXfWEzM1fPvWzNtLCHo7t2MtgYS68gjO7 bbxjeSHUqTx/AqKefXl1LDPdyZeeW1f0lu+U3L3RvH48ZfXdPwhfF2dbX4eL/rS6D29E/p/W ZKxhwk3D0ldm+K05UBZXFzPj8FBksMGSvvry6F5kfVo+k32ub0Nvu7rhCHxnpOjHDU8QV3b2 1jazZCe59VxN0+xxst4ZbSO4itp5pWCUerFrwzpGGpFNlabOBY2wt9X4tznYuHJWT3ijnWzZ 4i4fCY6VXWMdqZomb6pfUuaGcdHLSSh3vzmzytvKgNe9tni7fUMpazDNZl4YoKWsN8WQyRXc rYo+loN1wAcCD8S88eavJB3gTWtKV/AtBbza8s6+qPy9tVscZ6I3MfkxikbfIpsaOBVz8Ln5 XGSTH3jnuJLnGCUkk8Z8lAVqKf1Fm+zrrzMnNTqLN9nXXmZOagICKf1Fm+zrrzMnNTqLN9nX XmZOagICKf1Fm+zrrzMnNTqLN9nXXmZOagICKf1Fm+zrrzMnNTqLN9nXXmZOagICKf1Fm+zr rzMnNTqLN9nXXmZOagICKf1Fm+zrrzMnNTqLN9nXXmZOagICKf1Fm+zrrzMnNTqLN9nXXmZO agICKf1Fm+zrrzMnNTqLN9nXXmZOagO/TeNjy2Yt7O5eIrSpmvZSaCO2iBlmfX6sFbSKyx79 Q9fW7LWOxvcbkJZBbRsube2u7W1kMvRxvG4SPImAPLRYqLFahtxIIbG8jErTHKGwyjeYSCWP oODYu2Gy1RbRmG3tr+KJwdvRxxzNaRIzo5Ktbs8tuw8oQF7gcq+XK5OOKSG9tvUL66ZLLZW8 ZM0Nk97H9HuP3dx8Y2A0419W2QidpAX95cx213c5G8jc9lhbzGRrba0pH5Qj6MCv4vKs5Bi9 RWxe63sr2IyNfE4tilbvRvBY+M0G0OGwhSrJ2t8bbutcd1pZ20hLnQ2/rETCSN0ktjoDsCA0 mobezdpkRwNgmubfH4ifoI7eOOa2bJbRma5MwYHyNkeQH7TQkErztXPqWq+k6ToL/f6EWxd0 c1eg3Oj6Lg/s9zZTgoovUWb7OuvMyc1AQEU/qLN9nXXmZOanUWb7OuvMyc1AQEU/qLN9nXXm ZOanUWb7OuvMyc1AQEU/qLN9nXXmZOanUWb7OuvMyc1AQEU/qLN9nXXmZOanUWb7OuvMyc1A QEU/qLN9nXXmZOanUWb7OuvMyc1AQEU/qLN9nXXmZOanUWb7OuvMyc1AQEU/qLN9nXXmZOan UWb7OuvMyc1AQEU/qLN9nXXmZOanUWb7OuvMyc1AQEU/qLN9nXXmZOanUWb7OuvMyc1AQEU/ qLN9nXXmZOanUWb7OuvMyc1AQEU/qLN9nXXmZOanUWb7OuvMyc1AQEU/qLN9nXXmZOanUWb7 OuvMyc1AQEU/qLN9nXXmZOanUWb7OuvMyc1AezoiLorCIiAIiIAiIgCIiAIiIAiIgCIiAIiI AiIgCIiAIiIAiIgCIiAIiIAiIgCIiAIiIAiIgCIiAIiIAiIgCIiAIiIAiIgCIiAIiIAiIgCI iAIiIAiIgCIiAIiIAiIgCIiAIiIAiIgCIiAIiIAiIgCIiAIiIAiIgCIiAIiIAiIgCIiAIiIA iIgCIiAIiIAiIgCIiAIiIAiIgCIiAIiIAiIgCIiAIiIAiIgCIiAIiIAiIgCIiAIiIAiIgCIi AIiIAiIgP//Z

1 0

Re: gpc-20030209 (capitalization error)
by Tom Schneider 18 Feb '03

18 Feb '03

Frank: > > Capitalization of definition <original> does not match <current>. > > "Definition" is generally not correct, since it can also be an > applied occurrence of an identifier. Thanks, I suspected that wasn't the right term! > I'd prefer to have it in two lines, so the file names/line numbers > can refer to both points of usage. But breaking a sentence in such a > way, with a (generally) different line number in between, might be > confusing. So I'd then suggest something like: > > foo.pas:42: capitalization of identifier <current> does not match previous one > foo.pas:17: previous capitalization <original> > > or > > foo.pas:42: msimatched capitalization of identifier <current> > foo.pas:17: previous capitalization <original> 1. mismatched :-) 2. I find this use of the term 'mismatched' to be confusing. Line 42 does not stand by itself. Mismatched to what? Oh, that. It doesn't flow in logical order. 3. It's a bit confusing if you read it rapidly in one go and think it is one sentence. So I think the other example is better: > foo.pas:42: capitalization of identifier <current> does not match previous one > foo.pas:17: previous capitalization <original> A tiny bit of punctuation would help: foo.pas:42: Capitalization of identifier "<current>" doesn't match original one. foo.pas:17: The original capitalization is "<original>". Note that I substituted 'original' throughout for clarity. (Surely you don't mean the *previous* one - the one that just preceeded? In that case it would yell for the third item in this series: Knifefish ... KnifeFish ... Knifefish. I would think it should only object to the second one.) Ok, now to tighten the screws and make is it shorter: foo.pas:42: Identifier "<current>" capitalization doesn't match original. foo.pas:17: The original capitalization is "<original>". so: foo.pas:42: Identifier "KnifeFish" capitalization doesn't match original. foo.pas:17: The original capitalization is "Knifefish". :-) 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 (use only if first address fails) http://www.lecb.ncifcrf.gov/~toms/

2 1

Dynamic array sizes
by Wood David 18 Feb '03

18 Feb '03

> Beware dynamic array sizing. This caught me out ... > > PROGRAM dyn_arr_test(input,output); > > CONST > a = 3; > b = 10; > > TYPE > Dyn_arr( Max_index : INTEGER ) = ARRAY [1..Max_index] OF INTEGER; > Ptr_to_dyn_arr = ^Dyn_arr; > > VAR > Test1 : Ptr_to_dyn_arr; > Test2 : Ptr_to_dyn_arr; > Test1a : ARRAY [1..3] OF INTEGER; > Test2a : ARRAY [1..10] OF INTEGER; > > PROCEDURE zero(VAR param; ch : char; size : longint); asmname 'memset'; > > BEGIN > NEW( Test1, a ); > writeln(sizeof(Test1^)); > zero(Test1^,#0,sizeof(Test1^)); > NEW( Test2, b ); > writeln(sizeof(Test2^)); > zero(Test2^,#0,sizeof(Test2^)); > > writeln(sizeof(Test1a)); > zero(Test1a,#0,sizeof(Test1a)); > writeln(sizeof(Test2a)); > zero(Test2a,#0,sizeof(Test2a)); > END. > > The results are 16 and 44 for the dynamic arrays, 12 and 40 for the > non-dynamic arrays. > ie. the 'sizeof' function returns an additional 4 words for the dynamic > arrays and so my zero function was overwriting memory beyond the dynamic > array boundaries. > > Is this an unavoidable feature, a compiler bug or to be completely > expected? > > I am assuming the 'new' function doesn't explicitly zero memory and so I > need to do. I have used this zero function on all the usual Pascal > variables without problem, but I suspect it has a strange effect when used > to zero a record containing a string. Can anyone confirm whether there > are particular Pascal structures that shouldn't be zeroed by this > technique (apart from dynamic arrays)? > > Regards > > David Wood > QinetiQ, Farnborough The Information contained in this E-Mail and any subsequent correspondence is private and is intended solely for the intended recipient(s). For those other than the recipient any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on such information is prohibited and may be unlawful.

4 3

Darwin fink
by Juan Falgueras 18 Feb '03

18 Feb '03

Is there any Fink maintenance project in the future for Apple Darwin? -- juan

2 1

documentation
by Mehdi Khaldi 17 Feb '03

17 Feb '03

Hi, Is there an updated documentation? Because I downloaded the current documentation but it misses lots of explanations of keywords like external, etc... Thanks

1 0

gpc-20030209
by Frank Heckenbach 17 Feb '03

17 Feb '03

I've uploaded a new alpha version. Besides many internal cleanups (again) and bugfixes (thanks especially to Artur Zaroda for many reports), one new feature is to preserve the case of identifiers in error messages etc. and an optional warning for varying cases. GPC now installs the two utilites `binobj' and `gpidump' (with man pages if the program `help2man' is available at build time). However, since `binobj' is a BP compatiblity utility, and `gpidump' is mostly useful for debugging and understanding GPC internals, these programs might not be too useful to most GPC users. Those who build GPC packages of some kind, please note the new files. The structure of the homepage has changed. (It is now generated using `makeinfo --html' instead of `texi2html'.) Since many file names are different now, your links and bookmarks might break, but if you start from the home page, you should be able to find anything again. (Except for the info and texi versions of the to-do list which have been dropped from the home page. They're still contained in GPC source (info and texi) and binary (only info) distributions, and the HTML version is on the home page.) Furthermore, each page now contains an input form at the bottom where everyone can enter their additions. This was inspired by a discussion on gpc-doc. We hope this will encourage more contributions to the documentation. BTW, the source code of the CGI program that handles this input form can be found in my `cgiprogs' package in contrib/frank. There are some slightly incompatible changes. I hope they won't be a big problem to anyone: - dropped `--[no-]borland-char-constants' (now simply coupled to dialect options) - `=' and `<>' comparisons of structures (arrays, records, ...) except strings and sets are forbidden now - irrelevant operands and arguments (e.g. `foo in []'; `bar * []'; `Im (baz)' if `baz' is of real type) are not necessarily evaluated anymore (which is allowed by the standard); instead, a warning is given if they have side-effects - only one program, unit, module interface or implementation or a module interface and the implementation of the same module are accepted in one source file; new options `--[no-]ignore-garbage-after-dot' (fjf735*.pas) - dropped the usage of `GetMem' as a function with one parameter (only the BP compatible usage as a procedure with two parameters remains). (Both are semantically equivalent, so if you used the function syntax, you'll only have to make a minor change in your code, possibly using a new variable.) - accessing the variable `FileMode' now requires using the `GPC' (or, for BP compatibility, the `System') unit - routines declared in a program or module/unit implementation, with an `asmname' or `attribute' specification must now be marked `forward' explicitly (not so in an interface since those declarations are always forward if not external). E.g., previously: procedure Foo; asmname 'Bar'; procedure Foo; begin end; Now (note, this way also works with previous GPC versions): procedure Foo; asmname 'Bar'; forward; procedure Foo; begin end; The `asmname' etc. stuff is still quite confusing and unlogical (otherwise, you shouldn't need the two declarations at all), but at least now `forward' should work regularly. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

10 33

Re: Some observations [GHJ]
by Frank Heckenbach 15 Feb '03

15 Feb '03

Grant Jacobs wrote: > Shifting this thread over from gpc(a)gnu.de... (excuse the length of this) Shifting back the part of your mail that really isn't about documentation. ;-) > >> 1. --interface-only -c doesn't (always) produce a .o as the docs > >> say, > > > >Maybe you misunderstand the purpose of the option. It means to > >process only the interface part of a unit/module. Of course, you > >generally don't get a complete program without the implementation. > > I sort-of got this right the first time around ;-) > > The reason I went astray, was that I expected that compiling a unit > would produce an object file, which would later be linked in when the > main was compiled. That's right -- but only for compiling a whole unit. > In practice, none of the units I've tried compile > fully on their own. Of course not. > You get complaints about undefined main, etc., > which lead me to thinking that there much be some sort of compiler > switch that'd tell it to not look for / create a main function, just > create an object file 9library if that suits you better) to later be > linked to a main program. So, that's where the confusion seems to be. Compiling a unit never creates a `main' function (that's for the main program). What you seem to want is simply `-c' (compile the unit, but don't try to link it), whereas `--interface-only' really processes only the interface part and ignores the implementation part, so it can't create a (useful) object file. > This is why a description of how to compile units/modules would have > helped... Generally, just compile your main program with `--automake' and all units used will be compiled automatically when necessary. > > > if the file is untyped. It'd be nice if there was > > > a 'silent default' so that existing programs work 'as is'. For example > >> reset( infile, infname ) ; > >> gives a syntax error and demands that a buffer size be added. > > > >Yes, it's be nice, but BP stands in the way, as noted above. (AFAIK, > >the misdesign goes back to UCSD Pascal and the CPM file system ...) > >I think it would be too confusing to have two different silent > >defaults, depending on the dialect option. > > But how about an explicit default by the user from the command-line? So if someone forgets this option while compiling, the users get rather strange effects at runtime. I'd rather stay away from such obscurities ... > Easier than fiddling with their code (not that that's a terribly to > do in this case)... low priority... its solvable if faintly > irritating. if it was C, I'd use a macro to solve this, FWIW. Well, if you reaaally like to, you can do this in GPC as well ... :-/ > >The only thing I could possibly imagine would be to make the > >difference clear in some other way, e.g. to have the file declared > >as `file of Void' or so (with a default of 1), whereas a simple > >`file' (as in BP) behaves as it does now. > > Or redefine type File, doing which, err, must raise its own issues... > > type > file = file of void ; I had suggested that, but I don't really like it. It looks like a "typed file" for which `Read' and `Write' rather than `BlockRead' and `BlockWrite' would apply. > {or} > file = file[1] ; { ie file[<bufsize] } Too close to EP's file index (`file [domain] of element-type'). > {or assigning it, a la OOP in an initialisation section } > file.bufsize = 1 ; Too "magic" (making up a field of something not a record). If anything, one could think about using bindings (EP compliant) -- but then again, that wouldn't exactly be easier than adding one parameter in `Reset' ... > Hmm. Getting a bit fanciful, perhaps. What I'm trying to do is to tie > the buffer size with the file handle, which does makes some sense. I agree, but I don't see a reasonable way to do so. > I > suspect fewe users would vary the buffer size from one reset/rewrite > to another, I suspect very few would ever use anything else than 1 ... > so in principle it could be associated with the file for > most folk. But I can see the merits of sometimes needing to altering > it. Actually, I don't. For the very rare cases, it wouldn't be demanding to much having to declare another variable. > > > 3. One of my enumerated types contains 'property' and 'operator' > >> which prove to be GPC reserved words of some sort as the compiler > >> throws up a syntax error. I don't really want to have to alter > >> these... are these keywords part of some new standard? > > > >`property' is from Delphi, `operator' from PXSC. > > > >Generally, if you don't want any extensions (which include a few new > >keywords, of course), try `--extended-pascal'. > > > >The next GPC will also support `--disable-keyword=property,operator' > >(or `{$disable-keyword=property operator}' in the source). > > Grr. Any ideas on how long its going to take for this to appear? Uhm, last week. (IOW, sorry for the late reply. ;-) > I got the vague idea that part of the strategy of GPC was to allow > keywords to be redefined so that older code won't bump into keywords > from newer/different implementations of Pascal. So this isn't really > in place yet? Yes, but only where it's feasible to parse this. In some situations it's very hard to impossible to tell certain keywords from identifiers (i.e., it would require too much context, or maybe there would even be ambiguities). GPC does it in a number of cases, and probably some more can be done with more effort (volunteers welcome ...). But for the cases not recognized automatically, the new option is now available. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707

1 0

GPC 20030209 - Mingw binary release for gcc-3.2.2
by Prof. A Olowofoyeku (The African Chief) 15 Feb '03

15 Feb '03

Hi all You can obtain the binary of the Mingw version of GPC 20030209 (based on the "Mingw special" gcc-3.2.2 sources) from the Mingw web site: If you want a link, here it is (it overlows the line, so you will need to join it all together manually): http://prdownloads.sourceforge.net/mingw/gpc-20030209.i386-pc-mingw32- 1.tar.gz?download PS: the sources are also there (inclusive of the gcc-3.2.2 patch that I used). Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/

4 7

New bug in gpc-20030209
by Maurice Lombardi 15 Feb '03

15 Feb '03

Hi all When trying to recompile an old program with the new alpha, I found a new bug: name conflict between an object initializer in a program and an object initializer with same name in the IMPLEMENTATION part of an unit it calls, which should be invisible to him. The bug is displayed by the two files ---------------------- bug.pas ---------------------------------- program bug; uses u; type t = object constructor init; end; constructor t.init; begin end; begin writeln('OK'); end. ----------------------- u.pas ---------------------------------- unit u; INTERFACE IMPLEMENTATION type t = object constructor init; end; constructor t.init; begin end; end. ------------------------------------------------------------------- Error message: c:\djgpp\tmp\cc39phrP.o: In function `T_Init': c:/lombardi/djgpp/gpc/bug7/bug.pas:10: multiple definition of `T_Init' c:/lombardi/djgpp/o/u.o:c:/lombardi/djgpp/gpc/bug7/u.pas:13: first defined here collect2: ld returned 1 exit status gpc -v Reading specs from c:/djgpp/lib/gcc-lib/djgpp/2.953/specs gpc version 20030209, based on gcc-2.95.3 20010315/djgpp (release) 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 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

Debugging adventure on OS X
by Adriaan van Os 15 Feb '03

15 Feb '03

As part of the OS X port, I try to make GPC part of Apple's ProjectBuilder, a GUI integrated development enviroment running on top of tools like JAM, GCC and GDB. There is a screen shot of how it will look at <www.microbizz.nl/gpcscreen01.png>. I had expected debugging GNU Pascal programs (with Project Builder) to work, bit it didn't. After a late night session I found that stepping and breaking actually do (!) work. It was just that the Pascal source on the screen and the current-line indicator didn't reflect it .... Stephen Bespalko (from the Mac OS X Ada team) advised me to try the GDB command line, so (in another late night session) I found: (gdb) info source Current source file is /SourceCache/Csu/Csu-45/crt.c [instead of pentomino.pas] Compilation directory is /SourceCache/Csu/Csu-45/ Source language is c. Compiled with stabs debugging format. Does not include preprocessor macro info. (gdb) info sources Source files for which symbols have been read in: /Users/adriaan/gnu/gpc-3.2.1-patch/gcc/p/rts/init.pas, <implicit code>, /Users/adriaan/gnu/gpc-3.2.1-patch/gcc/p/rts/numtodec.pas, ../../gpc-3.2.1-patch/gcc/libgcc2.c, /Users/adriaan/gnu/gpc-3.2.1-patch/gcc/p/rts/sets.pas, /Users/adriaan/gnu/gpc-3.2.1-patch/gcc/p/rts/move.pas, /Users/adriaan/gnu/gpc-3.2.1-patch/gcc/p/rts/file.c, /Users/adriaan/gnu/gpc-3.2.1-patch/gcc/p/rts/rts-va.c, ../../include/stdarg.h, start.s, /SourceCache/Csu/Csu-45/crt.c, tconfig.h, ...<snip>... /Users/adriaan/gnu/gpc-3.2.1-patch/gcc/p/rts/rts.c, /SourceCache/Csu/Csu-45/crt.c So, the problem seems to be that GDB sees /SourceCache/Csu/Csu-45/crt.c as the source code instead of ./pentomino.pas. The promising point is that debugging Pascal code in listed runtime units (like init.pas) seemed to work perfectly. So, I started playing with the linker: [G4:~/pb/pentomino] adriaan% gpc -g -c -o pentomino.o pentomino.pas [G4:~/pb/pentomino] adriaan% set libpath = /Developer/Pascal/gpc321d8/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ [G4:~/pb/pentomino] adriaan% ld /usr/lib/crt1.o pentomino.o -L$libpath -lgpc -lgcc -lSystem [G4:~/pb/pentomino] adriaan% gdb pentmino GNU gdb 5.3-20021014 (Apple version gdb-250) (Sat Dec 7 02:14:27 GMT 2002) (gdb) info source Current source file is pentomino.pas Compilation directory is /Users/adriaan/pb/pentomino/ Located in /Users/adriaan/pb/pentomino/pentomino.pas Contains 254 lines. Source language is pascal. Compiled with stabs debugging format. Does not include preprocessor macro info. Suddenly, the problem had gone..... So, somehow, the source-file name "pentomino.pas" gets lost when typing one of these: [G4:~/pb/pentomino] adriaan% gpc -g -o pentomino pentomino.pas [G4:~/pb/pentomino] adriaan% gpc -g -o pentomino.o --automake pentomino.pas What can that be ???? Here is what it does (-v) [G4:~/pb/pentomino] adriaan% gpc -o pentomino -v pentomino.pas Reading specs from /Developer/Pascal/gpc321d8/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ specs Configured with: ../gpc-20030209/configure --enable-languages=pascal,c --prefix=/Developer/Pascal/gpc321d8 --enable-threads=posix Thread model: posix gpc version 20030209, based on gcc-3.2.1 /Developer/Pascal/gpc321d8/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ gpcpp -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_NO_ALIGNMENT__=1 -v -iprefix /usr/bin/../lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=1 -D__GXX_ABI_VERSION=102 -D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__APPLE_CC__=999 -D__DYNAMIC__ pentomino.pas -famtmpfile=/var/tmp//ccMIljqO.gpa /var/tmp//ccknfExA.i GNU Pascal Compiler PreProcessor version 20030209, based on gcc-3.2.1 (Darwin/PowerPC) /Developer/Pascal/gpc321d8/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ gpc1 /var/tmp//ccknfExA.i -fPIC -quiet -dumpbase pentomino.pas -version -famtmpfile=/var/tmp//ccMIljqO.gpa -o /var/tmp//cc6VO6Cd.s GNU Pascal version 3.2.1 (powerpc-apple-darwin6.3) compiled by GNU C version 3.2.1. GNU Pascal version is actually 20030209, based on gcc-3.2.1 as -o /var/tmp//ccm7Qu4a.o /var/tmp//cc6VO6Cd.s /Developer/Pascal/gpc321d8/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ collect2 -o pentomino -lcrt1.o -L/usr/bin/../lib/gcc-lib -L/Developer/Pascal/gpc321d8/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1 -L/Developer/Pascal/gpc321d8/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1/ ../../.. /var/tmp//ccm7Qu4a.o -lgpc -lgcc -lSystem -lgcc Regards, Adriaan van Os

2 2

about pascal
by Mehdi Khaldi 15 Feb '03

15 Feb '03

Hi, Can I include files .h with "include" keyword in a pascal program? How does gpc process this keyword? Thanks

2 1

Re: Range Checking
by Adriaan van Os 14 Feb '03

14 Feb '03

I am forwarding a message by Francois Schoubben: > From: Francois Schoubben <fsc(a)info.fundp.ac.be> > Date: vri feb 14, 2003 17:20:31 Europe/Amsterdam > To: Adriaan van Os <gpc(a)microbizz.nl> > Subject: Re: Range Checking > > Le ven 14/02/2003 à 17:16, Adriaan van Os a écrit : >> Francois Schoubben wrote: >> >>> I would be interested in helping too, but leaving for a week just >>> this >>> starurday. When i'll come back, and if it's still usefull, i'll be >>> able >>> to write test, especially for >>> - for loops >>> - array indexing >>> - strings maybe ? >> >> I will be pleased if you write the tests, as I am actually quite busy >> with the OS X port (not to mention other work). > > Ok, i put it on my todo list for the week i'll come back... > >> I guess Frank (Heckenbach) will appreciate any help (after you had >> time >> to understand gpc internals). > It might take time, i've just look at it and ... wow :-) > > -- > Francois

1 0

gpc with gcc-3.2
by samir namér 14 Feb '03

14 Feb '03

i wonder if anyone knows how to compile gpc with gcc-3.2 (or if it even works?), since i've had some trouble trying to find out myself. //enemix

1 0

[Fwd: Re: String Question]
by Richard D. Jackson 13 Feb '03

13 Feb '03

forgot to copy the list :) -----Forwarded Message----- > From: Richard D. Jackson <richardj(a)1gig.net> > To: Frank Heckenbach <frank(a)g-n-u.de> > Subject: Re: String Question > Date: 13 Feb 2003 10:14:20 -0600 > > On Thu, 2003-02-13 at 01:27, Frank Heckenbach wrote: > > <snip> > > > In this case what gpc does is truncate the return value to fit into > > > myStr. Other words this does not cause a compiler error so the compiler > > > sees these two strings as being equivlant even though that is not the > > > case. > > > > My previous reply to Chuck's mail should have made this clear. > > > Did not get that one until after I wrote my reply. > > > <snip> > > > What is interesting is that. > > > Given > > > > > > var > > > buff : String (255); > > > > > > I can stuff 30925 chars into it after that majic number I get a > > > segfault. > > > > I can't. The following stops at 255. > > > > program Foo; > > > > var > > buff : String (255); > counter : Integer; > > > > begin > > buff := ''; > counter := 1; > > repeat > > buff := buff + ' '; > > WriteLn (Length (buff)) > WriteLn ( counter ); > counter := counter + 1; > > until False > > end. > > > Here even though the Length of buff will stay 255 after the 255th > iteration counter will go to 30951 before the segfault. Which means the > sting buffer is going out of bounds. > > > If what you mean is treating the string as an array of char and > > indexing out of range, this would be a matter of range-checking(*) > > -- I'm not sure if you mean this, that's why it's always a good idea > > to include some example code! > > > Here is what I used but note it is slopy as I was trying out other > things as well. NOTE: You can replace Str255 with TString and get the > same result. Also I'm still using gpc-20021128 based on gcc-3.2.1 > > program stringtest( Input, Output); > > uses GPC; > > type > Str255 = String (255); > > var > testout : String (100); > > function foobar: Str255; > var > counter : Integer; > buff : String (255); > > begin > buff := 'B'; > for counter := 1 to 30923 do > if counter = 99 then > buff := Concat( buff, 'E' ) > else > buff := Concat( buff, '1' ); > buff := Concat(buff, 'D'); > writeln( buff ); > foobar := buff; > end; > > begin > testout := foobar; > writeln( testout ); > end. > > > > (*) which GPC is currently lacking. I wrote a mail about it on > > 2002-12-14, but there doesn't seem to be much interested from > > the users. > > > > > If I suround a string with other > > > vars they are not getting overwriten wich is a good thing but I still > > > wonder why it did not segfault at 256. I guess it is something I will > > > have to look into when I have more time to dig into it with gdb. > > > > Programming languages have more or less implementation-defined > > behaviour, but I don't think any language would guarantee a segfault > > in a certain situation. ;-) > > > True I don't expect the language to guarantee a segfault under certain > situations. I was mustly just testing if I could create a buffer over > run. Now how a Hacker would exploit that I don't know. But it does mean > that when using strings for input I will have to make sure it does not > happen. Mostlikly I will have to use LibC functions to protect against > this. > > Richard

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc