Gpc

gpc@gnu.de

5400 discussions

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

SV: EFLIB port to GNU Pascal and FPK Pascal.
by Johan Larsson 11 Oct '97

11 Oct '97

The African Chief wrote: > GPC is in dire need of a complete class library. So, I would be > interested in doing some of the work for porting this to GPC, > if others would also contribute. Any other takers? The library > is big, but many hands make the work lighter. This would also > give us the chance to ferret out any remaining "issues" as far > as BP compatibility is concerned! Sounds good! Those that are interested could take a look at the 5th prototypes source code when released and then send me some reflections. I suggest that the 6th prototype is finished before the porting actually begins. There are certain interface issues to be resolved first. The specification of EFLIB prototype 6 has been sketeched. It's available at http://ftp.sunet.se/EFLIB/Manual/Specifications/ for download as PostScript, PDF and DOC files. A new TPH help file can now be downloaded at http://ftp.sunet.se/EFLIB/Download/. Contact me personally, or write to eflib-developers(a)ts.umu.se (mailing l ist). I welcome everyone to subscribe to the EFLIB mailing lists and to direct questions and make suggestions here, since many people will read the messages. Subscription information is available at http://ftp.sunet.se/EFLIB/Support/, among other places. Best Regards, Johan Larsson E-MAIL jola(a)ts.umu.se HOME http://www.ts.umu.se/~jola/ Also, REMEMBER to check out http://ftp.sunet.se/EFLIB/ for a free application framework - SIMPLY SOPHISTICATED.

1 0

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

11 Oct '97

Hello everybody! A new beta version of GNU Pascal is being uploaded to Agnes: gpc-971001. This is merely a bug fixing release, but there are some now features, too - most of them intended to achieve better compatibility to other compilers. The GNU Pascal development team welcomes two new members: Bill Currie implemented some new built-in functions, and Frank Heckenbach improved the run-time system to deal with non-standard situations. Bug fixes and new compatibility features ======================================== GPI mechanism: * The installation problem caused by a variable `_end' is gone. * Function attributes and schemata containing expressions now survive transport through a GPI file. * Open files now survive transport through a GPI file. Now you can write BP's `Printer' unit in the canonical way. * Some crashes observed with GPI files on Windows 95 should not occur any more. * Pointers should no more lose compatibility to themselves when imported from more than one GPI file. (E.g. when importing objects with the same parent type from different units, you don't get a superfluous warning any more. * Some errors that only occured when a virtual method having an undiscriminated string parameter was transported through a GPI file have vanished. * The temporary `.gpc' file should now be deleted after compilation in all cases. Procedural parameters, variables, and pointers: * Problems with procedures and functions that were called when they should be passed as a parameter or taken the address - or vice versa - should have disappeared now. * Procedures and functions declared in the main program now can be safely assigned to a procedural variable or pointer. * GPC now checks for the erronous assignment of a procedure to a pointer to a procedure. Assign the address instead. * When `foo' is a procedural variable (= reference to a procedure), `@foo' yields a pointer to the procedure, and `@@foo' the address of the procedural variable itself (like in Borland Pascal). Range checking: * In most situations where constant value are involved (assingment of a constant expression to a variable, initialization, ...) GPC now performes range checking. This holds for ordinal values and strings. * Arithmetics with integer constants should no more overflow if intermediate results do not fit in `Integer'. The result is then range-checked. Standard Pascal: * GPC now passes (again) all level 0 PVS conformance tests. Some things are still broken with high optimization levels on the DEC Alpha. For gpc-2.1, we plan to have them fixed and to have level 1 passed as well. * Non-local `goto' targetting the main program works again. (It was broken in some unofficial intermediate releases due to some other improvements.) * Using global variables as `for'-loop control variables in the main program works again. (This was also broken in some unofficial intermediate releases due to some other improvements.) * Comments starting with `{' and ending with '*)' or vice versa still work. (They were also broken ... see above.) * The function `arctan' works again. (It was ... well, you know.) * The transfer procedures `pack' and `unpacked' work again. (They were broken (for obvious reasons) when packed arrays were introduced.) * Non-trivial expressions involving components of packed arrays work now. * Type checking of sets has been improved. * Set expressions ("set constructors") should work in all cases now. * Comparisons of sets of different size (including the empty set) work now. * Subranges are now compatible to their parent type. * Comparisions between char constants are no more warned about in `--standard-pascal' mode. * Parameters of `read' now may be components of packed arrays and records as long as they are aligned on a byte boundary. * Missing program parameters are warned about in `--standard-pascal' mode. This warning does *no more* turn into an error with `--pedantic-errors' because it is valid in ISO Pascal (while useless) to write a program without any input and output. * Tag fields of variant records now can be initialized in `New': Type FooPtr = ^FooRec; FooRec = record case Bar: Boolean of true: ( a: Integer ); false: ( b: Char ); end (* FooRec *); Var p: FooPtr; New ( p, true ); (* Assigns `p^.Bar:= true' *) Extended Pascal: * Undiscriminated strings and schemata passed as function parameters should now work in all cases. * In a schema type declaration, the discriminants now may be part of expressions. Borland Pascal: * GPC now has a built-in `Assign' procedure. * In units and with `external' and `forward' procedures and functions, GPC now checks that the parameter lists match (if the second one exists). * Some bugs with `#$42' char constants (when they appeared in sequence or at the beginning of a line) are fixed now. * GPC now allows to put a variable to specified address with `absolute': "Var foo: Integer absolute 42;". This is only useful on systems without virtual memory - *not* with DOS (DJGPP or EMX). Outside $X+ mode, you get a warning about this use of `absolute'. (Note that GPC uses a flat memory model and thus does *not* define BP's "Var foo: Integer absolute $40:$42;".) * Assignments between object variables are now complained about. GNU extensions: * New built-in types: `MedReal' and `LongestReal'. * `New' with schema pointers now can be called analogously to `New' with object pointers: Type MySchema ( n: Integer ) = array [ 1..n ] of Byte; MySchemaPtr = ^MySchema; Var p: MySchemaPtr; p:= New ( MySchemaPtr, 42 ); * `__volatile__' variables no more become `__external__' automatically. * Machine attributes now also work for variables, not only functions. * Function attributes now can have more than one argument. * The run-time system (RTS) now can handle most non-standard types such as long integers. * Fixed strings ([packed] array of Char) with a lower bound different from 1 are now handled correctly. * `ReadStr' can read from a `CString' (= `PChar') now. * `CString' variables now can be initialized with constants. * Now you can initialize a pointer to a string with a constant: "Var p: ^String value @'Hello, world!';". * Type casts from pointers to integers and between integers of different size and signedness work now. * Taking the address of something not aligned on a byte boundary is now warned about. * A new function `GetFile ( Const F: any File ): Pointer' now returns a pointer to the C `FILE' structure inside a Pascal `File' variable. * Declaring statements are now warned about unless compiling with $X+. * The expression after `absolute' can be an arbitrary expression now: "Var foo: Integer absolute bar^ [ i ].baz;". You can use this to define shortcuts (like macros in C) - use with care. Outside $X+ mode you get a warning if the expression does not reduce to a constant address. * `Inline' now works like promised in the documentation, and it is redefinable. (`__Inline__' still works.) Miscellaneous: * Console I/O under DJGPP now works correctly with certain control characters. * Linking `.a' files with the (*$L /usr/lib/libfoo.a *) directive works now. * Some problems with certain built-in functions (`sqr', `pred', `succ', `min', `max') when applied to integer constants have vanished. * `--pedantic-errors' now has again the same meaning as in GCC. Use `-Werrors' to turn warnings into errors. * If `gpc --automake' is invoked to compile other languages than Pascal, it no more crashes. * The source fo the GNU Pascal compiler itself has been cleaned up significantly. Read and enjoy! Where to get it =============== The source is being uploaded to ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/, files gpc-971001.tar.gz and gpc-971001.zip, together with binaries for DOS (DJGPP), and Linux (ELF). Binaries for DOS and OS/2 (EMX) and FreeBSD will follow as soon as possible. In order to prepare for the release of gpc-2.1, binaries are moved to a subdirectory `binary' of `beta', and some other things are being set up, so don't be confused if some files aren't located any more where they were on the day before. Acknowledgement =============== I have lost overview, but the GNU Pascal development team thanks everybody who helped us by contributing useful code and ideas and reporting bugs. Thanks to all of you! Please go on finding all bugs in gpc-971001! I may have overlooked some you already reported. (If so, please remind me by e-mail.;-) Once GPC is clean, we can release version 2.1 - and face neat new features (e.g. qualified import and identifiers, classes, interfaces, procedure overloading, ...) for 2.2! :) Greetings, The GNU Pascal Development Team

3 4

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

10 Oct '97

The African Chief wrote: > >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). You probably should, but (AFAIK) you don't have to. > 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. (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.) > >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). > 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? Allocating memory and copying the string seems to be the only way possible in Pascal code that really solves all problems. (Including a third one, namely that the resulting CString isn't influenced by modifications of the Pascal string, as one would expect from a function result. However, I guess this is seldom a real problem because of the way the function is used usually.) 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). - 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. - 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). (* Peter, was this what we intended to do, or did I confuse anything? ;*) > 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!? I assume it's meant to add a #0 terminator, but I fail to see how it would do this (unless there is already a #0 somewhere)... OTOH, if you're using the strings unit anyway, is there anything wrong with StrPCopy? > 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. This program does not work correctly in my BP. 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. > BTW: > "const t:string=#8#8#8#8' wrong, sorry.'#0;" doesn't compile > under GPC ! Peter Gerwinski wrote: > It does under my version of gpc-971001, under DJGPP as well as > under Linux. On mine, it works, too, but only once! The program: program x; const t1:string(255)=#8#8#8#8' wrong, sorry.'#0; const t2:string(255)=#8#8#8#8' wrong, sorry.'#0; begin end. gives the error: y.p:3: numeric constant contains digits beyond the radix ^ for the second(!) declaration. Now, that's strange... Anyway, it seems to be realted to the problem reported in <6dRwLb2VlJB(a)rufus.central.de>. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Re: String constants #f#0#0'bar'
by Peter Gerwinski 10 Oct '97

10 Oct '97

According to The African Chief: > > This program; > [...] > produces this output from "redir"; > [...] > aka.pas:21: numeric constant contains digits beyond the radix Fixed. Thanks for the report. :-), 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: String constants #f#0#0'bar' (was: New GPC beta: gpc-971001)
by The African Chief 10 Oct '97

10 Oct '97

On Fri, 10 Oct 1997 10:33:35 +0200 (MEST) Peter Gerwinski <peter(a)agnes.dida.physik.uni-essen.de> wrote: >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. This program; Program aka; uses gpctypes, system, strings; {$X+} Function sspChar ( s1 : String ) : pChar; Begin sspChar := StrNew ( StrCopy ( @s1 [1], @s1[1] ) ); End; {* sspChar *} const s:string=' '+ ' '+ ' '+ ' '+ ' '#13#10'This program is OK.'; t:string=#8#8#8#8' wrong, sorry.'#0; var p:pchar; begin p:=sspChar(s); writeln(p); StrDispose(p); end. produces this output from "redir"; Reading specs from c:/djgpp/lib\specs gpc version 971001(2.7.2.1) c:/gpc/bin\gpc-cpp.exe -lang-pascal -v -nocharescape -undef -D__GNUC__=2 -D__GPC__=2 -D__GNUC_MINOR__=7 -Dunix -Di386 -DGO32 -DMSDOS -DDJGPP=2 -DDJGPP_MINOR=1 -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__DJGPP__=2 -D__DJGPP_MINOR__=1 -D__unix -D__i386 -D__GO32 -D__MSDOS -D__DJGPP=2 -D__DJGPP_MINOR=1 aka.pas c:/temp\ccbaaaaa GNU CPP version [unknown] (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: c:/gpc/include c:/gpc/lang/pascal /include /include /usr/include End of search list. c:/gpc/bin\gpc1.exe c:/temp\ccbaaaaa -quiet -dumpbase aka.pas -version -famtmpfile=aka.gpc -fautomake=--automake -fpack-struct -o c:/temp\cccaaaaa GNU Pascal version [unknown] (80386, BSD syntax) compiled by GNU C version 2.7.2.1. GPC AutoMake: gpc --automake="--automake" --automake --amtmpfile=aka.gpc -M gpctypes.pas -o gpctypes.d GPC AutoMake: gpc --automake="--automake" --automake --amtmpfile=aka.gpc -M system.pas -o system.d GPC AutoMake: gpc --automake="--automake" --automake --amtmpfile=aka.gpc -M gpctypes.pas -o gpctypes.d GPC AutoMake: gpc --automake="--automake" --automake --amtmpfile=aka.gpc -c strings.pas aka.pas:21: numeric constant contains digits beyond the radix 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

EMX binaries on Agnes
by Peter Gerwinski 10 Oct '97

10 Oct '97

Hello! The EMX binaries for gpc-971001 are on Agnes, ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/gpc-971001.i386-emx09c.zip Thanks to Kevin A. Foss for compiling them. :-) I also included the updated `libgpc.a' into gpc-971001.i386-djgppv201.zip. Greetings, 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

Jump to page:

2025

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