September 1997 - Gpc

Procedural parameters and types: bug report and work-around
by Jesper Lund 19 Sep '97

19 Sep '97

Dear GPC developers: In my recent post to the list about compiler warnings with "incompatible pointers" (when using user-defined types), I mentioned that I had a similar problem with procedural types/parameters. This statement is much, much too vague for a bug report, so here is an example that demonstrates the problem. (Peter, thanks for the speedy response to my first bug report!) Note that, contrary to the "incompatible pointers" problem that I reported a few days ago, the program below does *not* compile (unless the work-around in the example is used). In the example below, there is one unit (u4) and the main program. The example demonstrates all facets of the bug (type inconsistencies) that I have discovered, and includes a simple bug work-around (I am assuming here that the typecast needed to fix the problem is not a feature ...). ------------------------- u4. pas ---------------------------------- unit u4; { Note the start-up code } interface type procType = ^procedure (var x : Integer); procedure proc3 (procedure f (var x : Integer)); procedure proc4 (f : procType); implementation { Example with Procedural parameter (Standard Pascal) } procedure proc3 (procedure f (var x : Integer)); var y : Integer; begin f(y); Writeln (y); end; { proc3 } { Example with Procedural Types (Borland-like) } procedure proc4 (f : procType); var y : Integer; begin f(y); Writeln (y); end; { proc4 } procedure Test (var b : Integer); begin b := 2003; end; begin { Both of these call compile and work. Note that the procedure } { "Test" which is passed as argument is in the same unit. Hence, } { there is no need for a typecast (as in the main program). } proc3 (Test); { Procedural parameter example } proc4 (Test); { Procedural type example } end. --------------------------------- mainprg1.pas ---------------------- program Mainprg1; uses u4; procedure pp (var k : Integer); begin k := 120469; end; { pp } begin { Below the procedure passed as argument (pp) resides in another } { module than proc3/proc4. The code will only compile when there } { is a type cast. This applies both to procedural parameters } { (Standard Pascal) and types (Borland-like). } { These lines do not compile } proc3 (pp); { Line 18 } proc4 (pp); { Line 19 } { With the typecast everything works OK! Even in the standard } { Pascal version (proc3) which does not use the type "ProcType". } proc4 (ProcType (pp)); { Bug work-around for Borland-like example } proc3 (ProcType (pp)); { It also works for Standard Pascal example } end. ------------------------------------------------------------------------ I compile with gpc -o mainprg1.exe mainprg.pas --automake Compiler output: mainprg1.pas: In function `program_Mainprg1': mainprg1.pas:18: too few arguments to function `Pp' mainprg1.pas:18: invalid use of void expression mainprg1.pas:19: too few arguments to function `Pp' mainprg1.pas:19: invalid use of void expression (same error for procedural types and parameters). When line 18 and 19 is deleted, the program compiles correctly (because of the typecast bug work-around), and outputs (as intended) 2003 2003 120469 120469 The first two lines are from the start up code (procedural argument Test in unit u4), the third and fourth from "pp" in the main program. Finally (for the record), I use GPC version 970714 (beta), DJGPP precompiled binary. Sincerely, Jesper Lund

1 0

AW: Looking for some random-functions ...
by Achim Kalwa 19 Sep '97

19 Sep '97

Christian Bockermann wrote: > My actual problem is that I don't find any procedures of functions to get > randomized numbers. I tried "randomize" and "random(n)" as in Turbo Pascal, > but it didn't work. :-) > Is there any unit perhaps, which includes such functions in GPC ? Is there > perhaps something like the "CRT"-unit ? You can use the following external function declaration: FUNCTION Rand : Integer; C; and do the following example: FOR i := 1 TO 10 DO WriteLn(Rand); Alternatively, there is a random number generator unit called "Rand" written by Frank Heckenbach (heckenb(a)mi.uni-erlangen.de) To Frank: Would you post your unit again, please? Im interested, too. Achim

1 0

Re: Bug report (incompatible pointers)
by Peter Gerwinski 18 Sep '97

18 Sep '97

According to Jesper Lund: > [...] > This is my first mail to the list, so first of all: THANKS for a GREAT > pascal compiler! Thanks for the feedback! Getting e-mails like this is highly motivating. :-) > However, the current version (970714; DJGPP version) cannot compile > (correctly) some programs with user-defined types. [...] > > There is a similar (related) problem with procedural parameters (and types). > [...] I could reproduce both bugs and fix them in my current development snapshot. A new beta release is :(still): in preparation. Thanks for the report and for the helpful example programs. > mainprg.pas: In function `program_Mainprg': > mainprg.pas:14: warning: passing arg 1 of `Proc2' from incompatible pointer > type > > It is "only" a warning, and an .exe file is produces, but somestimes the > program crashes (not here, though). This is unrelated; the warning can be safely ignored. The bug causing the crash must be somewhere else in your program. Good luck with it! ;-) Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Bug report (incompatible pointers)
by Jesper Lund 17 Sep '97

17 Sep '97

Dear GPC developers: This is my first mail to the list, so first of all: THANKS for a GREAT pascal compiler! However, the current version (970714; DJGPP version) cannot compile (correctly) some programs with user-defined types. The problem occurs in the following situation: - Unit "u1" defined a type (say, myType) - Another unit, "u2", has a procedure with a parameter of type myType - The main program calls the procedure in "u2" (after having defined a variables of type myType). I am sorry if this sounds cryptic (I tried to be precise), but there is an example below. Now, this example/setup works if myType is a pointer to a built-in type, or an array of built-in types (ex: pointer to an array of doubles), but it does NOT work if myType is more "complicated", e.g. a pointer to a record type [as in the example below]. There is a similar (related) problem with procedural parameters (and types). I have included a simple example (below) which demonstrates the bug, and I hope you are able to reproduce it. Note that the program consists of two units (u1, u2), as well as the main program. Command line invoking GPC: gpc -o mainprg.exe mainprg.pas --automake Compiler output: mainprg.pas: In function `program_Mainprg': mainprg.pas:14: warning: passing arg 1 of `Proc2' from incompatible pointer type It is "only" a warning, and an .exe file is produces, but somestimes the program crashes (not here, though). Sincerely, Jesper Lund jel(a)hha.dk P.S. If you respond to the list, please include a CC to me (I may not have been added the list yet). Thanks. ------------------------------------------------------- program Mainprg; uses u1, u2; var y : RecPtr; begin New (y); Proc2 (y); { This call results in an incompatible pointer call } end. { Note that proc2 is in u2, where as recPtr is } { defined in u1. } ----------------------------------------------------------------- unit u1; interface type rec = record a, b : Integer; end; recPtr = ^rec; procedure Proc1 (x : recPtr); implementation procedure Proc1 (x : recPtr); begin { Do nothing } end; begin end. { u1 } ------------------------------------------------------------ unit u2; interface uses u1; procedure Proc2 (x : recPtr); implementation procedure Proc2 (x : recPtr); begin Proc1 (x); { This call is OK -- no compiler errors! } end; begin end. { u2 } ----------------------------------------------------------------

1 0

Re: Problems with the gcc patch
by Peter Gerwinski 15 Sep '97

15 Sep '97

According to Robert Ketzscher: > > I am now trying to install the beta-version gpc-970714 > I seem to fall at the very first hurdle: > After I downloaded and extracted both gpc and gcc (2.7.2.1) > I did as I was told in the README of gpc above. > I get the message: > I can't seem to find a patch in there anywhere. > when entering the patch command. What exactly did you type? The following is known to work on Linux and DEC-OSF: cd /where/ever/it/is/gcc-2.7.2.1 # This must contain a `p' subdirectory patch -p1 < p/patches/gcc-2.7.2.1.patch # The following commands may have more options ./configure make LANGUAGES=pascal Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

2 2

Problems with the gcc patch
by Robert Ketzscher 15 Sep '97

15 Sep '97

Hi, I am now trying to install the beta-version gpc-970714 I seem to fall at the very first hurdle: After I downloaded and extracted both gpc and gcc (2.7.2.1) I did as I was told in the README of gpc above. I get the message: I can't seem to find a patch in there anywhere. when entering the patch command. Any ideas? Thanks in advance Rob

1 0

Re: Overflow in implicit constant conversion
by Peter Gerwinski 14 Sep '97

14 Sep '97

According to Robert Ketzscher: > > first of all I hope this is the right address to pose my > problem. It is. Welcome to the GNU Pascal mailing list! > I get the message > Overflow in implicit constant conversion > at the end of the interface part (i.e. where implementation starts). > I only use a handful constants and even after I commented them out > I got the same message. I wrote a small unit typedefs as follows: > > unit typedefs; > > interface > > type longint = __long__ Integer; > byte = __byte__ Integer; > extended = __long__ Real; > word = __short__ Integer; > longstring = String[255]; > shortint = __byte__ Integer; > > implementation > > begin > end. Is this the unit which causes problems? It compiles well with all versions of GPC I have at hand. Which version do you use? If not, I only can guess that your problems come from initialized `Byte' variables (typed constants) initialized with values above 127 because you define `Byte' as a signed type. To get an unsigned `Byte', use Type ByteInt = __byte__ Integer; Byte = __unsigned__ ByteInt; If you have more problems and you are using gpc-2.0 or earlier, you should upgrade to a more recent beta version of GPC, available at ftp://agnes.dida.physik.uni-essen.de/gnu-pasal/beta/. The latest official beta release is gpc-970714; the next one is in preparation. This new GPC has the following types - and more - built in: Type LongInt = __long__ Integer; (* 64 bits *) ShortInt = __short__ Integer; (* 16 bits; `Integer' has 32 *) ByteInt = __byte__ Integer; (* 8 bits *) LongWord = __unsigned__ LongInt; (* 64 bits, unsigned *) Word = __unsigned__ Integer; (* 32 bits, unsigned *) ShortWord = __unsigned__ ShortInt; (* 16 bits, unsigned *) Byte = __unsigned__ ByteInt; (* 8 bits, unsigned *) Extended = __long__ Real; (* 80 bits *) Hope this helps, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Re: demo for using of qsort from lib and a little problem with it
by Frank Heckenbach 14 Sep '97

14 Sep '97

Peter Gerwinski wrote: > > function CompNum(var e1, e2: TestType):Integer; > > Var > > r : Real; > > begin > > r := e1 - e2; > > CompNum := Round(r); > > end; > > Consider this with "TestType = Byte", then in `CompNum' we are subtracting > two `Byte' variables from each other. GPC chooses the result type to be > `Byte' again, so the result is never negative. > > When I convert them to `Integer' by writing > > r:= Integer ( e1 ) - Integer ( e2 ); > > it works. (First it did not work because of a bug in conversions among > integer types, but I could fix this.;-) > > However, is this the correct behaviour? I think it is because... > Or should the result type of a > subtraction be the "nearest" signed integer type - `ShortInt' in this > example? Then, what to do when subtracting two `LongestCard's, especially > in cases like "$FFFFFFFFFFFFFFFF - 2" where the result does not fit in > `LongestInt'? That's the problem. Also, this problem is basically the same as a multiplication of two Integers resulting in a LongInt. GPC (and BP) do not do any automatic conversion there, either. IOW, the programmer is responsible for chosing the right types and converting when necessary. The best the compiler can do (and will do hopefully soon) is range checking. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

3 2

Overflow in implicit constant conversion
by Robert Ketzscher 14 Sep '97

14 Sep '97

Hi, first of all I hope this is the right address to pose my problem. If it is not then I apologise for wasting your time. I recently came across GPC and I am now trying to convert a huge Turbo Pascal program (15000 lines total in various units) to a UNIX executable. I thankfully wrote the code fairly modular so I did not expect many problems. However, already the first few units containing all type definitions seem to cause problems. I get the message Overflow in implicit constant conversion at the end of the interface part (i.e. where implementation starts). I only use a handful constants and even after I commented them out I got the same message. I wrote a small unit typedefs as follows: unit typedefs; interface type longint = __long__ Integer; byte = __byte__ Integer; extended = __long__ Real; word = __short__ Integer; longstring = String[255]; shortint = __byte__ Integer; implementation begin end. The interface part of the failing unit contains a few hundred type definitions and various variables all using those types (longint,bytes etc.). Is that what the problem is and if yes how can I avoid it? Any info much appreciated Robert Ketzscher

1 0

Re: Standardized Pascal class library
by Peter Gerwinski 12 Sep '97

12 Sep '97

Hi, Johan! Hi, everybody! According to Johan Larsson: > [...] > I am writing to you since I am trying to get in contact with people who > can and want to > port my works for the Borland dialect of Pascal to other languages such > as Delphi, > FPK and GNU Pascal -- and any other language which could profit by > getting a > standardized class library. > [...] (* Johan, better break your lines at column 72; otherwise it will get hard to read after the mailers will have done it for you. ;*) This approach (writing for more than one Pascal compiler) has obvious advantages, but also the disadvantage that you cannot use the full power of any of the compilers. For instance, you cannot use function over- loading (available in FPK Pascal), operator overloading (available in GNU Pascal), or object properties (available in Delphi). So the common denominator will probably be the language of Borland Pascal 7.0. It should not be too hard to port a program written in this language to GNU Pascal (speaking of recent beta versions, not of gpc-2.0). If you encounter any serious problems (for instance, GPC does not yet support `Block[Read|Write]'), be invited to report them here, so we can improve the GNU Pascal compiler until it compiles EFLIB without major changes to the source. > Why choose EFLIB? First of all, EFLIB will be distributed freely with > source and all - > that is, as soon as the juridical details have been worked out by > Swedish layers (within a > week or maybe a month). > [...] Why don't you choose the GNU LGPL as the distribution conditions? While I am not content with *all* points in the LGPL, it's not good to increase confusion by writing yet another license for Free Software. > EFLIB can thus be used by any Pascal programmer > with > non-commercial objectives. Read: You want to charge for commercial applications of EFLIB? > [...] Finally, EFLIB > is well- > documented since almost 50% of the source code is source code comments. Do you mean ordinary comments in the source, or do you use some system to write the documentation into the source next to the function, so you can extract it using another program? Good luck, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970714] - http://home.pages.de/~gnu-pascal/ [970125]

1 0