Gpc October 1997

gpc@gnu.de

31 participants
158 discussions

Another compiler error ...
by chris＠bockermann.ping.de 09 Oct '97

09 Oct '97

Hello everybody ! As I slowly make my program work, another compiler error appearce on my screen : chris@bockermann:/home/chris/programs/pascal/indent > gpc --automake wort.p module.c:1334: failed assertion `0' gpc: Internal compiler error: program gpc1 got fatal signal 6 gpc1: gpc exited with status 1 gpi-hash.c:321: failed assertion `ss.key == -DEBUG_HASH_KEY' gpc: Internal compiler error: program gpc1 got fatal signal 6 Does anybody know what that means ? Thanks a lot, Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

1 0

Re: Writeln and longint
by Frank Heckenbach 09 Oct '97

09 Oct '97

Kevin A. Foss wrote: > Hello, > In my process of getting gpc to compile under OS/2, I've been > trying some example code and Peter recommended trying stuff like > writing longints to see if the new features in 971001 were working. > Well, I tried the following: > -=-=-=-=- > program testlongint(output); > > Var > i : longint; > > begin > i := 1; > writeln(i); > end. > =-=-=-=-= > It compiles fine, but for output I get simply: > > [C:\kevin\pascal\gpc-test]longint > qd > > Any ideas as to what might be going wrong? From looking through the > new RTS code, 'qd' is the format that is used for longints, > (RTS-WRTI.C) but I don't know what the 'q' is supposed to do as it > isn't a standard printf() style format (AFAIK) and I don't see code to > parse 'q' in vasprintf.c either -- which I believe is the function that > eventually gets called. I feared this would cause problems somewhere... obviously there isn't a portable way to write "long long"s in C. :-( I'll see what I can do about it. In the worst case, I'll have to rewrite the output of integers completely which I planned to do (later) anyway... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: "Segment fault" error :-(
by Frank Heckenbach 09 Oct '97

09 Oct '97

Christian Bockermann wrote: > (By the way, if you have suggestions for a better style of programming > this copy-function, please let me know, I'm already learning ... :-) In this case, there is quite an easy option: you can use EP(Extended Pascal)'s SubStr function. Incidentally, I just wrote a Copy function on Monday, including some checks for strange situations. Here it is (as in your example, TStr can be any string[n], but not string): function Copy(const s:String;Index,Count:Integer):TStr; begin if Index<1 then begin Dec(Count,1-Index); Index:=1 end; if (Index>Length(s)) or (Count<=0) then Copy:='' else if Index+Count-1>Length(s) then Copy:=SubStr(s,Index,Length(s)-Index+1) else Copy:=SubStr(s,Index,Count) end; Frank -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Writeln and longint
by Peter Gerwinski 09 Oct '97

09 Oct '97

According to Kevin A. Foss: > In my process of getting gpc to compile under OS/2, I've been > trying some example code and Peter recommended trying stuff like > writing longints to see if the new features in 971001 were working. > Well, I tried the following: > [...] > It compiles fine, but for output I get simply: > > [C:\kevin\pascal\gpc-test]longint > qd Ah! The occurrence of this error means that you successfully installed gpc-971001 including the new RTS. :-)-: > Any ideas as to what might be going wrong? From looking through the > new RTS code, 'qd' is the format that is used for longints, > (RTS-WRTI.C) but I don't know what the 'q' is supposed to do as it > isn't a standard printf() style format (AFAIK) As far as I can look up from the Linux on-line C documentation, `qd' is a standard format. Some C compilers comply to this standard, while others use `lld' or `Ld' for putting out `long long int'. GCC should support all of these variants, so I wonder what is going wrong on EMX. The same problem holds, BTW, for the DEC Alpha. :-( If anybody knows a portable way to output `long long in' in C, please let us know, so we can improve GPC's RTS. (I know, I am asking this question to the wrong mailing list ...) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: New GPC beta: gpc-971001
by The African Chief 09 Oct '97

09 Oct '97

On Wed, 8 Oct 1997 20:19:36 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >Maurice Lombardi wrote: > >> There is another error in this initialization part (which presumably has >> nothing to do with the crash of the compiler). >> The variable ppJunk is New'ed, used to fill CmdLine, which is a pointer >> of pChar type, Then Dispose'd. So the memory to which CmdLine points is >> reputted into the heap, and can be overwrited by subsequent instructions >> in the main program. Fixed! > >Unfortunately, there are similar bugs (at least) in the functions Str2PChar >(in System.pas) and Int2PChar (GPCUtil.pas). I hope they will be fixed in >the next release. I can see the problemwith Int2pChar (I have fixed it now, by copying the string to the result ( with "StrNew()" ) instead of just assigning it (the user has to free the memory afterwards - with "StrDispose()"). However, I fail to see the problem with Str2pChar. It works correctly in all my tests (at least, under BP7, BPW, Delphi 1 and Delphi 2). Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)keele.ac.uk

1 0

Writeln and longint
by Kevin A. Foss 09 Oct '97

09 Oct '97

Hello, In my process of getting gpc to compile under OS/2, I've been trying some example code and Peter recommended trying stuff like writing longints to see if the new features in 971001 were working. Well, I tried the following: -=-=-=-=- program testlongint(output); Var i : longint; begin i := 1; writeln(i); end. =-=-=-=-= It compiles fine, but for output I get simply: [C:\kevin\pascal\gpc-test]longint qd Any ideas as to what might be going wrong? From looking through the new RTS code, 'qd' is the format that is used for longints, (RTS-WRTI.C) but I don't know what the 'q' is supposed to do as it isn't a standard printf() style format (AFAIK) and I don't see code to parse 'q' in vasprintf.c either -- which I believe is the function that eventually gets called. But I imagine I just have some problem somewhere in my port... so any ideas what would cause this? -Kevin -- Kevin A. Foss --- kfoss(a)mint.net --

1 0

Re: Problems with file-handling an new GPC Beta
by Peter Gerwinski 09 Oct '97

09 Oct '97

According to Jesper Lund: > > You need to close the file before calling reset. If you add > > close(f) > > just before > > reset(f) > > your program works fine. Whether this is a *feature* or a *bug* depends on > the definitions of reset/rewrite in the (various) Pascal standard(s). [...] I agree. However when we want to claim some compatibility to Borland Pascal, GPC must also support this feature/bug. So I must consider this failure a bug in GPC. Thanks, Christian, for finding it out! :-) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: "Segment fault" error :-(
by Peter Gerwinski 09 Oct '97

09 Oct '97

According to Christian Bockermann: > chris@bockermann:/home/chris/programs/pascal/indent > a.out > Segmentation fault This means that you have written to some memory where you were not allowed to write to. In this case it means that you have filled the string beyond its capacity. Let's see why: > program test; > > type tstr = string[30]; > > var s_test : tstr; > > function copy (s : tstr; p1 : integer; p2 : integer ) : tstr; (* Here you can save some typing by writing "p1, p2: Integer". *) > var > i : integer; > buf : tstr; > begin > for i:=p1 to p2 do What you mean is: "for i:= p1 to p2 + p1 do". > buf[i]:=s[i]; > copy:=buf; Here is the problem: You have assigned some characters to the string, but not a length. Now, "copy:= buf" assigns a string of *random* length to the variable `buf' with a capacity of 30 which causes the crash. > end; > > begin > s_test:='Dies ist ein Test-string'; > writeln(copy(s_test,5,4)); > end. To solve the problem you can either directly assign a length to the string - which is currently only possible by using some more-or-less dirty tricks - or you do it this way: buf:= ''; for i:= p1 to p1 + p2 do buf:= buf + s [ i ]; copy:= buf; BTW (= by the way), your procedure does not check whether `p1 + p2' or even `p1' is in the range of the string `S'. > (By the way, if you have suggestions for a better style of programming > this copy-function, please let me know, I'm already learning ... :-) You mean: You are *still* learning. :-) No problem with this - your style is very good. I have seen a much worse programming style from people who consider themselves "computer freaks". (I may say it here because noone of them is on this list (hopefully).;-) 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/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: Problems Building Latest GPC Beta
by Peter Gerwinski 09 Oct '97

09 Oct '97

According to Phil Robertson: > Has anyone seen or have any ideas about this problem with > building the latest Beta: > [...] > include/string.h:127: conflicting types for `perror' > include/errno.h:54: previous declaration of `perror' This looks like broken system header files for me. Sorry, but I have no better suggestion than to look into those header files and see why the declarations conflict. 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/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: New GPC beta: gpc-971001
by Peter Gerwinski 08 Oct '97

08 Oct '97

According to Maurice Lombardi: > > There is another error in this initialization part (which presumably has > nothing to do with the crash of the compiler). > The variable ppJunk is New'ed, used to fill CmdLine, which is a pointer > of pChar type, Then Dispose'd. So the memory to which CmdLine points is > reputted into the heap, and can be overwrited by subsequent instructions > in the main program. This is an error in `system.pas', not in GPC, so I can relax. :-) (* But it's easy to fix: Just remove the line `Dispose ( ppJunk )'. *) Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

← Newer
1
...
9
10
11
12
13
14
15
16
Older →

Jump to page:

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