Gpc

gpc@gnu.de

5400 discussions

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

Jump to page:

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