Gpc July 1997

gpc@gnu.de

22 participants
111 discussions

Files
by berend＠beard.nest.nl 01 Feb '02

01 Feb '02

* Moved (from: gpc) by Berend de Boer using timEd 1.10.b3+. Peter Gerwinski wrote in a message to Berend de Boer: PG> I tried to use Extended Pascal "binding" to assign a file PG> variable to an external -- existing -- file. I just copied PG> the "Assign" pro- cedure by Berend as published in PG> borland2ep.doc. It does not always work: I often get a PG> runtime error saying that the file did not exist. If you can repeat it, compile with another Extended Pascal compiler, for example Prospero's one. If that fails too, there is really something wrong with the code. But I suspect gpc. You're using which OS? Groetjes, Berend (-: fido: 2:281/527.23 email: berend(a)beard.nest.nl

4 3

Re: gpi-hash.c segfaults
by Peter Gerwinski 31 Jul '97

31 Jul '97

According to Bill Currie: > > I'VE FIXED IT!! The problem was caused by a negative index into the > hash table. Congratulations and thank you! > To fix it change the line (gci-hash.c:122): > > (((((char *)(NODE))-(char *)0) >> 2) % MAX_HASH_TABLE) > > to: > > (((((unsigned long)(NODE))-(unsigned long)0) >> 2) % MAX_HASH_TABLE) Since pointers and `long' integers don't have the same size on some sytems (I know it for the Alpha), I think this should be changed to something like `(unsigned size_t)'. > [...] > Well, anyway, maybe now this bug can be laid to rest... I hope so, too. Having this, it's realistic to have the next beta release within the next days ... Yours, 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]

3 2

pointer-compatibile integers (was: gpi-hash.c segfaults)
by Peter Gerwinski 31 Jul '97

31 Jul '97

According to Frank Heckenbach: > > While we're at it: would it be possible to have predefined Pascal types > as size_t and ptrdiff_t (and maybe other types?) so that such > calculations can be done in Pascal? Not enough integer types yet? ;-) This can be be implemented with Type PtrInt = Integer ( BitSizeOf ( Pointer ) ); Is this sufficient? Since GPC fully supports pointer arithmetics, I don't see too much applications for this. If not ... what about `PtrInt', `PtrCard', and `PtrWord'? Greetings, Peter (* For those who have not followed the recent discussion about integer types in GPC, here is some background: Besides `Integer' (signed), GPC supports `Cardinal' (unsigned) and `Word' (don't care about signedness, in fact unsigned). These types exist in several sizes which guarantee compatibility to GNU C and introduce some portability to other Pascal compilers: GNU Pascal GNU C ByteInt signed char ShortInt short int Integer int MedInt long int LongInt long long int There are also `*Card' and `*Word' versions of these, yielding a total of fifteen basic integer types. Besides this, GPC supports a synonym `LongestInt' for `LongInt' which guarantees the longest possible integer type (for the case that GNU C introduces `long long long int' which we would implement as `LongLongInt'); same with `LongestCard' and `LongestWord'. Eighteen. Compatibility to Borland Pascal and Delphi requires `Comp' (same as `LongInt' and `SmallInt' (same as `ShortInt' in GPC). Twenty. Okay? Good. Now it *really* begins. Like all Pascal compilers, GPC supports subranges like `1..42'. This adds 2 * sqr ( 2 pow 64 ) more possible integer types to our zoo. The `2' comes from signed and unsigned variants ... let's speak of "20 + two classes" of integer types. As an extension, GPC allows these subranges to be `packed' (i.e. allocate only one byte for `packed 1..42'; the default of allocating four bytes results in faster code) which leaves us with 20 + four classes of integer types. In low-level programming you often have the situation that you want to know exactly how many bits a variable occupies. While this could be done with packed subranges, it is more comfortable to have an extended syntax for `Integer'. In GPC, `Integer ( 42 )' yields a 42-bit integer. Depending on the machine (which might not have 42-bit registers) this will probably be stored in a 64-bit word, except in packed records; however on those machines where you need, say, `Integer ( 8 )' for your low-level stuff, you can be sure that the hardware supports it. Having this for `Cardinal' and `Word' as well yields 20 + 7 classes. Adding `Ptr[Int|Card|Word]' as suggested above would make it 23 + 7 classes of integer types. Well, no big deal. I know this is a great source of confusion, but the discussion convinced me that all these integer types have their place where they are important. 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

Re: gpi-hash.c segfaults
by Frank Heckenbach 31 Jul '97

31 Jul '97

Jukka Virtanen wrote: > In ANSI C the result of (ptr - ptr) is of type ptrdiff_t, > which in the alpha is (signed long). > Using cast (unsigned size_t) might not be a good idea, at least > I do not know if Ansi C quarantees that size_t always > is as large as ptrdiff_t. While we're at it: would it be possible to have predefined Pascal types as size_t and ptrdiff_t (and maybe other types?) so that such calculations can be done in Pascal?

1 0

Re: More crashing in gpc (970727)
by Peter Gerwinski 31 Jul '97

31 Jul '97

According to Bill Currie: > > Sigh, got gpi-hash fixed and now this :( > > At least it's easy to reproduce, I just have absolutly no > understanding of what's going on. > > Just compile with `gpc -O2 -c system.pas'. Reproducible. :-) > A warning is given (doesn't make sense to me yet) You commented out the definition of `LongInt' to be `Integer' (32 bits), so GPC used its built-in `LongInt' (64 bits), whereas pointers on iX86 processors only have 32 bits. > and then the call > to `convert' in `build_c_cast' (line 5316 in gpc-typeck.c) goes > bananas (infinite(?) recursion). This happens in fillchar (line 178) > [...] Fixed. :-) Patch for `gpc-typeck.c' below. > There's also a strange bug where an untytped constant that's declared > in one unit that's used by onother and both of those are used by a > third gets lost to the third unit if the second unit is `used' after > the first. Unfortunatly, I have yet to reproduce this in small > files. And unfortunately, I cannot reproduce it by myself. :-( But I don't expect this to be as weird as the "hashing" bug you just fixed. :-) 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] 8< ---- gpc-typeck.c.diff ---------------------------------------------------- @@ -5303,7 +5308,9 @@ pedwarn ("constant out of range - truncated"); } - if (TREE_UNSIGNED (type) != TREE_UNSIGNED (TREE_TYPE (value)) + if (TREE_CODE (type) != POINTER_TYPE + && TREE_CODE (TREE_TYPE (value)) != POINTER_TYPE + && TREE_UNSIGNED (type) != TREE_UNSIGNED (TREE_TYPE (value)) && TYPE_PRECISION (type) != TYPE_PRECISION (TREE_TYPE (value))) { /* Do the conversion in two stages, e.g.

1 0

Re: Linking error
by Peter Gerwinski 30 Jul '97

30 Jul '97

According to Joao Miguel: > > I'm trying to compile the system.pas unit (contained in bpcompat.zip) with > my program. The compiler gives the error: > > "system.o: Undefined symbol `__fmode' referenced from text segment" > > I'm using Free-BSD 2.1. [...] I am afraid this system Unit is not {yet} very portable. It is known to run under DJGPP (DOS), but to make it usable for FreeBSD, probably some work will be necessary. AFAIK, `FMode' is responsible for write access when `reset'ting a file; to get the same functionality without this variable you can use `update' instead of `reset'. 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: Pascal Compiler
by Peter Gerwinski 30 Jul '97

30 Jul '97

According to Tsee Lee: > > I saw on the web site that there is a version for Win95, but can't find > it on the ftp server. Is ther really such a version? Thanks. Yes: Look out for the `cygwin32' binaries. You will probably need more CygWin32 stuff for program development under Windows 95 with GNU Pascal. You can look for it at ftp://ftp.cygnus.com, but somebody else on this list can probably tell you more about that. 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

Linking error
by Joao Miguel 30 Jul '97

30 Jul '97

Hi, I'm trying to compile the system.pas unit (contained in bpcompat.zip) with my program. The compiler gives the error: "system.o: Undefined symbol `__fmode' referenced from text segment" I'm using Free-BSD 2.1. Can anyone tell me what is the name in BSD of the symbol referenced in the source: "FMode : AsmName '_fmode' integer;" Best regards Joao Domingos

1 0

More crashing in gpc (970727)
by Bill Currie 30 Jul '97

30 Jul '97

Sigh, got gpi-hash fixed and now this :( At least it's easy to reproduce, I just have absolutly no understanding of what's going on. Just compile with `gpc -O2 -c system.pas'. A warning is given (doesn't make sense to me yet) and then the call to `convert' in `build_c_cast' (line 5316 in gpc-typeck.c) goes bananas (infinite(?) recursion). This happens in fillchar (line 178) Oh well, here's my version of system.pas (a few functions added and fillchar's parameter changed to Byte) There's also a strange bug where an untytped constant that's declared in one unit that's used by onother and both of those are used by a third gets lost to the third unit if the second unit is `used' after the first. Unfortunatly, I have yet to reproduce this in small files. Bill -- Leave others their otherness. The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any another MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: system.pas Date: 30 Jul 1997, 18:27 Size: 8054 bytes. Type: Program-source

1 0

gpi-hash.c segfaults
by Bill Currie 30 Jul '97

30 Jul '97

I'VE FIXED IT!! The problem was caused by a negative index into the hash table. To fix it change the line (gci-hash.c:122): (((((char *)(NODE))-(char *)0) >> 2) % MAX_HASH_TABLE) to: (((((unsigned long)(NODE))-(unsigned long)0) >> 2) % MAX_HASH_TABLE) (patch attached) Now for the explanation: when gcc subtracts pointers, a SIGNED integer is produced and all further operations on that value used the signed versions (eg cwd,idiv to get the modulus). The reason this showed up for me and not Peter is djgpp's sbrk algorithm mixed with window's memory allocation: sbrk allocates separate dpmi memory chunks each time it is called and under windows (3.x or 95), the allocated memory can very easily come from BELOW the beginning of the program. This will result in pointers in the range 0xfxxxxxxx. As to the reproducability: it all depends on the fragmentation of dpmi memory under windows (cwsdpmi doesn't seem to have this problem, and nor does dosemu I suppose). Well, anyway, maybe now this bug can be laid to rest... Bill -- Leave others their otherness. *** gpi-hash.c~ Tue Jul 22 14:04:30 1997 --- gpi-hash.c Wed Jul 30 16:04:00 1997 *************** *** 119,125 **** #define HASH_FUNC(NODE) \ ! (((((char *)(NODE))-(char *)0) >> 2) % MAX_HASH_TABLE) /* return pointer to a node uid field */ int * --- 119,125 ---- #define HASH_FUNC(NODE) \ ! (((((unsigned long)(NODE))-(unsigned long)0) >> 2) % MAX_HASH_TABLE) /* return pointer to a node uid field */ int *

1 0

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 July 1997