- Gpc - gnu.de

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

10 Oct '97

On Fri, 10 Oct 1997 00:21:00 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: > >> 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). > >...which is a nice example for the fact that testing alone doesn't prove >correctness... ;-) You are right here! > >First of all, there is a problem if s has full length, and "s+Chr(0)" would >overflow s. Currently this is not noted (a bug in GPC), but when the bug is >fixed, it will either trigger a runtime error or cut the result, i.e. not >append the #0. True :-( > >In BP (which doesn't have this bug and always cuts strings), the routine >indeed behaves wrong is this situation. See the following program: > >program x; > >Function Str2pChar ( Var s : String ) : pChar; >Var >x : String; >Begin > x := s; > s := s + Chr ( 0 ); > Str2pChar := @s [1]; > s := x; >End; {* str2pChar *} > >const > s:string=' '+ > ' '+ > ' '+ > ' '+ > ' '#13#10'This program is OK.'; > t:string=#8#8#8#8'wrong, sorry.'#0; > >var p:pchar; > >begin > p:=str2pchar(s); > writeln(p); >end. Yes, the program shows the bug :-( > >Secondly, you copy back the old value of s back afterwards. This only works >because GPC copies only Length(x) characters. If this behaviour would be >changed to copy more characters (of course not more than x.Capacity), your >code would break. (Such a change might be done for efficiency, e.g. by >rounding up to a multiple of 4, and though I don't think it's likely to >be changed, the change would be valid, I disagree that it would be valid. >AFAIK, since the characters after Length(x) in a string are undefined.) Which is why you should only copy to length(s). If I do "str1 := str2" , I do not expect an optimiser to make it into; "str1 := str2 + any junk after the length of str2, up till str2.capacity". > >A possible "fix" for the second problem (not the first one, though the >appearance of the problem will be different then) would be >"s[Length(s)+1]:=#0" (also, it's much more efficient). I am not sure how this solves the problem. >But don't worry too much about these functions. Sooner or later, such >functionality will be built-in into GPC... That will be good. The compiler can better cater for some things. However, I have a version of Str2pChar which deals with this bug, but it would require the user to dispose of memory afterwards - which means it cannot be used in an expression (which is what I want it for). I have added this version to system.pas, but commented it out. I have also noted the "full length string bug" in the sources. This is the fixed version, which seems to work okay. Any comments? program x; uses strings; Function Str2pChar ( s : String ) : pChar; Begin Str2pChar := StrNew ( StrCopy ( @s [1], @s[1] ) ); End; {* str2pChar *} const s:string=' '+ ' '+ ' '+ ' '+ ' '#13#10'This program is OK.'; t:string=#8#8#8#8' wrong, sorry.'#0; var p:pchar; begin p:=str2pchar(s); writeln(p); StrDispose(p); { need to dispose of the memory! } end. BTW: "const t:string=#8#8#8#8' wrong, sorry.'#0;" doesn't compile under GPC ! 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

String constants #f#0#0'bar' (was: New GPC beta: gpc-971001)
by Peter Gerwinski 10 Oct '97

10 Oct '97

According to The African Chief: > BTW: > "const t:string=#8#8#8#8' wrong, sorry.'#0;" doesn't compile > under GPC ! It does under my version of gpc-971001, under DJGPP as well as under Linux. 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: Another compiler error ...
by Peter Gerwinski 10 Oct '97

10 Oct '97

According to Christian Bockermann: > > chris@bockermann:/home/chris/programs/pascal/indent > gpc --automake wort.p > module.c:1334: failed assertion `0' > [...] This is a problem with the GPI format. It should vanish if you remove all `.gpi' files and then try again. The GPI file format changes with each version of GPC. I hope that we will be able to fix this somewhere in gpc-2.2. If the problem does *not* vanish when you rebuild all `.gpi' files, you have discovered a bug in GPC. In that case, please report it here. 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/ [971005] maintainer GNU Pascal [971001] - http://home.pages.de/~gnu-pascal/ [971005]

1 0

Re: New GPC beta: gpc-971001
by Frank Heckenbach 10 Oct '97

10 Oct '97

The African Chief wrote: > 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). ...which is a nice example for the fact that testing alone doesn't prove correctness... ;-) First of all, there is a problem if s has full length, and "s+Chr(0)" would overflow s. Currently this is not noted (a bug in GPC), but when the bug is fixed, it will either trigger a runtime error or cut the result, i.e. not append the #0. In BP (which doesn't have this bug and always cuts strings), the routine indeed behaves wrong is this situation. See the following program: program x; Function Str2pChar ( Var s : String ) : pChar; Var x : String; Begin x := s; s := s + Chr ( 0 ); Str2pChar := @s [1]; s := x; End; {* str2pChar *} const s:string=' '+ ' '+ ' '+ ' '+ ' '#13#10'This program is OK.'; t:string=#8#8#8#8'wrong, sorry.'#0; var p:pchar; begin p:=str2pchar(s); writeln(p); end. Secondly, you copy back the old value of s back afterwards. This only works because GPC copies only Length(x) characters. If this behaviour would be changed to copy more characters (of course not more than x.Capacity), your code would break. (Such a change might be done for efficiency, e.g. by rounding up to a multiple of 4, and though I don't think it's likely to be changed, the change would be valid, AFAIK, since the characters after Length(x) in a string are undefined.) A possible "fix" for the second problem (not the first one, though the appearance of the problem will be different then) would be "s[Length(s)+1]:=#0" (also, it's much more efficient). But don't worry too much about these functions. Sooner or later, such functionality will be built-in into GPC... Frank -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

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