Gpc October 1997

gpc@gnu.de

31 participants
158 discussions

Built-in string functions (was: New GPC beta: gpc-971001)
by Peter Gerwinski 14 Oct '97

14 Oct '97

According to Frank Heckenbach: > > It could also be a switch. But wouldn't it be "cleaner" to write it as a > function? "CStrFunc (Str2CStr (StrVar))" or so... Ah - you are referring to parameter passing. Yes, this will be built-in, so you can just write "CStrFunc ( StrVar )". > > What functions do you mean? Built-in replacements for BP's functions from > > the `Strings' Unit? > > Of course, they could be external functions as well. It's no problem to > implement them in Pascal. But I think in the long run, all such standard > functions will be built-in. You are right that it would be easy to provide these functions as built-in features once we have solved this problem for parameter passing. Since there already is a de-facto standard in BP how to name these functions we should use that. Everything okay, 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: Problem building New GPC beta: gpc-971001 for DJGPP v2.1
by Peter Gerwinski 14 Oct '97

14 Oct '97

According to Maurice Lombardi: > > I have tried to build gpc-971001 from the zip sources for DJGPP v2.01 > I use plain DOS with or without bash shell: > > -unzip fresh new gcc-2721 in directory %DJDIR%\gnu\ > -unzip gpc sources to %DJDIR%, then put the p\ tree as subdirectory > of gcc-2721 > > then follow instructions contained in p\config\msdos\readme2.dj. > > It builds gcc, but then stops without building gpc ? Strange. :-( Anyway, when you have reached this step, the following is known to work: `cd' to `\djgpp\gnu\gpc\p' and do `make ../xgpc', `make ../gpc1', `make ../gpc-cpp', and `make ../libgpc.a' from there. This builds the respective `.exe' files, although we do *not* specify the extension `.exe'. After that, move the `.exe's to `\djgpp\bin', and `libgpc.a' to '\djgpp\lib' to install. > Other problems found: > > 1- the p\config\msdos\configur.bat must be in dos format > (return-linefeed) to run in plain dos [...]. Fixed. > 2- there is a problem with backward slashes \ in the makefile in lines > like > ./bi-arity < $(srcdir)\bytecode.def >tmp-bc-arity.h > (three times). Seems to come from the application of > gnu\gcc-2721\config\msdos\top.sed and is already present in the > compilation of gcc alone. I have filed a bug report to dj delorie, > and fixed it manually after running configure go32 which produces this > makefile. So there is nothing we could do about that ... may I ask you to document it in `README2.DJ'? > 3- [`.gdbinit' vs. `_gdbinit'] Okay. It will be fixed in the next `.zip' release. Thanks for your cooperation, 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]

2 1

Re: Strings and PChars
by Frank Heckenbach 13 Oct '97

13 Oct '97

The African Chief wrote: > Now, that is the interesting bit. Both permutations give a wrong result > in BP (DOS real mode and DOS DPMI), but give correct results in > BP (Windows) and GPC (DJGPP). Shouldn't they all behave the same? Not really. Since they're relying on more or less undefined things (such as the contents of the stack area next to some parameter), the behaviour can easily be different on different platforms. It could even be different on the same platform (e.g. in Dos when loaded at different addresses -- or under a debugger). That's the kind of bugs that's hard to track. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

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

13 Oct '97

Peter Gerwinski wrote: > > - One that always makes a copy on the stack and copies the string into it. > > That's the secure way, but inefficient with very long strings. > > Concerning CStrings? You mean a switch? It could also be a switch. But wouldn't it be "cleaner" to write it as a function? "CStrFunc (Str2CStr (StrVar))" or so... > > - One that allocates the memory on the heap. This is needed when the > > resulting CString is to be used outside of the current scope (when it's > > not only passed to a function). > > > > - One that copies the string in a buffer allocated by the programmer (this > > is perhaps only for compatibility with BP's StrPCopy). > > What functions do you mean? Built-in replacements for BP's functions from > the `Strings' Unit? Of course, they could be external functions as well. It's no problem to implement them in Pascal. But I think in the long run, all such standard functions will be built-in. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: Strings and PChars (Was: New GPC beta: gpc-971001)
by The African Chief 13 Oct '97

13 Oct '97

On Mon, 13 Oct 1997 02:36:00 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >> >> Str2pChar := StrNew ( StrCopy ( @s [1], @s[1] ) ); >> > >> >I don't understand this line. What do you expect "StrCopy ( @s [1], @s[1] )" >> >to do? AFAICS, it copies a string into itself!? >> >> More or less. Since it is already itself, nothing really should happen, >> but the side effect is that it provides the input for StrNew to work with, > >You could just write "Str2pChar := StrNew ( @s[1] );" True. >which gives the same (wrong) result in BP. Now, that is the interesting bit. Both permutations give a wrong result in BP (DOS real mode and DOS DPMI), but give correct results in BP (Windows) and GPC (DJGPP). Shouldn't they all behave the same? 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

Re: Strings and PChars (Was: New GPC beta: gpc-971001)
by Frank Heckenbach 13 Oct '97

13 Oct '97

The African Chief wrote: > No, it shouldn't. Maybe we are at cross purposes here. My original > meaning was: if I write "str1 := str2", that is precisely what I should > get - no more, no less. I should get in "str1" the exact number of > characters that are in "str2", in the exact order - no more, no less. > If an optimiser gives me that, I don't really care what else it does ... Exactly. The number of characters is given in the length. Anything beyond the length (such as the #0 terminator in your first version) is undefined. > Okay, I understand that now ;-). However, this solution will not > work if there is a maximum length for the string, and the string > that is passed to the function has already reached that length. True. For (long) string, we can solve this by implicitly making the schema bigger by 1 char than declared, but for short strings, this is not possible without breaking BP compatibility, so we need to copy them. (OTOH, it's not so bad there, since they can be only 255 chars long, so there isn't too much overhead.) > >> Str2pChar := StrNew ( StrCopy ( @s [1], @s[1] ) ); > > > >I don't understand this line. What do you expect "StrCopy ( @s [1], @s[1] )" > >to do? AFAICS, it copies a string into itself!? > > More or less. Since it is already itself, nothing really should happen, > but the side effect is that it provides the input for StrNew to work with, You could just write "Str2pChar := StrNew ( @s[1] );" which gives the same (wrong) result in BP. > >OTOH, if you're using the strings unit anyway, is there anything wrong with > >StrPCopy? > > If I used this routine in the system unit, I would not be using the > strings unit there - but I can import "strcpy" from the C library, > and call it "StrCopy". Perhaps something like (NOT tested): Function Str2pChar ( s : String ) p : pChar; begin GetMem (p, Length(s) + 1); Move (s[1], p^, Length(s)); p[Length(s)] := #0 end; -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

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

13 Oct '97

I wrote: > 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 > > 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... OK, that's what I did now. I re-wrote the outputting of integers and reals in Pascal now. So this program should work with the next GPC version. However, especially the writing of reals has many special cases, so there may be some bugs left. So please, everyone who's interested in this, write some test programs, and submit them (!) -- preferably with (what you think are) "special cases". It's better if the author doesn't do this himself because he'll usually have handled those special cases that he thinks about... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

subscription
by Peter W. Schnoor 12 Oct '97

12 Oct '97

subscribe gpc pwsch(a)nephro.uni-kiel.de

1 0

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

12 Oct '97

According to Frank Heckenbach: > > (* Peter, was this what we intended to do, or did I confuse anything? ;*) I am not sure. ;-) > Actually, for sometime later we have planned to build the following functions > into the compiler: > > - One that just appends the #0 and returns the addres of the first character > of the string (solves problem 2; not 3; problem 1 will be solved by making > strings internally bigger than declared by 1 char). For short strings (when > they will be introduced), this function will make a temporary copy on the > stack (because they must be BP compatible so there will not always be space > for the #0 in the string). Yup. > - One that always makes a copy on the stack and copies the string into it. > That's the secure way, but inefficient with very long strings. Concerning CStrings? You mean a switch? > - One that allocates the memory on the heap. This is needed when the > resulting CString is to be used outside of the current scope (when it's > not only passed to a function). > > - One that copies the string in a buffer allocated by the programmer (this > is perhaps only for compatibility with BP's StrPCopy). What functions do you mean? Built-in replacements for BP's functions from the `Strings' Unit? 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 11 Oct '97

11 Oct '97

On Sat, 11 Oct 1997 01:23:15 +0200 Frank Heckenbach <heckenb(a)mi.uni-erlangen.de> wrote: > >The African Chief wrote: [...] >> >AFAIK, since the characters after Length(x) in a string are undefined.) >> >> Which is why you should only copy to length(s). > >You probably should, but (AFAIK) you don't have to. Agreed. >> 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". > >Not "str2 + any junk", it's still only "str2", according to the definition >of (this kind of) strings. Generally, a string always contains "junk" after >the length till the capacity, and you shouldn't rely on anything about this >junk. No, you shouldn't. >(E.g., I recently modified the WriteStr procedure so that it will >not fill a (normal) string with spaces, #0's or whatever as it did before. >Only arrays of char are padded with spaces, unless treated as CStrings. >I don't think such a change should matter to any "good" program.) No, it shouldn't. Maybe we are at cross purposes here. My original meaning was: if I write "str1 := str2", that is precisely what I should get - no more, no less. I should get in "str1" the exact number of characters that are in "str2", in the exact order - no more, no less. If an optimiser gives me that, I don't really care what else it does ... >> >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. > >When you explicitly write a #0 into the "junk" area, you can be sure that >it will be there (because you don't use any string functions, such as >assignments between strings). And it's more efficient because you don't >have to copy the contents of the string (twice) and don't need any temp >variables. Therefore, you don't have to limit the length of the string >(in system.pas it's limited to 255 chars). Okay, I understand that now ;-). However, this solution will not work if there is a maximum length for the string, and the string that is passed to the function has already reached that length. >> program x; >> >> uses >> strings; >> >> Function Str2pChar ( s : String ) : pChar; >> Begin >> Str2pChar := StrNew ( StrCopy ( @s [1], @s[1] ) ); > >I don't understand this line. What do you expect "StrCopy ( @s [1], @s[1] )" >to do? AFAICS, it copies a string into itself!? More or less. Since it is already itself, nothing really should happen, but the side effect is that it provides the input for StrNew to work with, and it also saves on using another temporary variable. Perhaps this is a misguided saving? >OTOH, if you're using the strings unit anyway, is there anything wrong with >StrPCopy? If I used this routine in the system unit, I would not be using the strings unit there - but I can import "strcpy" from the C library, and call it "StrCopy". Even if I wanted to use StrpCopy, I would still need 2 variables - and you would also need more code. But if I used this in the system unit, I would not need >> 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. > >This program does not work correctly in my BP. It works correctly under my BP (BPW) and also under GPC. >It might seem to work for you because you pass s by value now, >so now there will not be t after s in memory (on the stack), but >something else. Okay. I will do more tests then! 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

← Newer
1
...
7
8
9
10
11
12
13
...
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