Gpc

gpc@gnu.de

5400 discussions

Re: BPCOMPAT v1.10 -released!
by Frank Heckenbach 23 Oct '97

23 Oct '97

Some minor comments: Unit system: The type declarations (especially string=bpstring with -D_Borland_Pascal_ should be in system.pas itself (or $included) rather than in a separate unit (gpctypes.pas) so that programs that use only system will see them. My suggestion: remove the "{$W-}". Doing so will reveal a little bug in BinEof (a "=" used instead of ":="), and a lot of problem in FillChar and Move (which are not really portable, anyway). Until a (more optimized) version of them will be built in, here are some replacements (a bit slower, but should be portable and generate no warnings): Procedure FillChar ( Var Dest : Void; Count : Integer; C : Char ); Var z:Integer; begin for z:=0 to Count-1 do TCharArray(Dest)[z] := C end; Procedure Move ( Var Source, Dest : Void; Count : Integer ); Const PtrBitSize = BitSizeOf(Pointer); Type PtrCard = Cardinal(PtrBitSize); Var z:Integer; begin { Avoid overwriting of overlapping memory areas } if PtrCard (@Source) > PtrCard (@Dest) then for z:=0 to Count-1 do TCharArray(Dest)[z] := TCharArray(Source)[z] else for z:=Count-1 downto 0 do TCharArray(Dest)[z] := TCharArray(Source)[z] end; To make it work, you have to remove the (now obsolete) declaration of Cardinal (and perferably ByteInt and Byte as well) from gpctypes.pas. For the other type declarations, I suggest you use the more modern GPC integer types (as invented some months ago), rather than the old style __modifiers__. (Also for real types.) With -D_Borland_16_Bit_, also redeclare Integer to be a 16 bit type, otherwise it'll probably confuse some BP programs. A test program for FillChar and Move: program x; uses system; var a:array[1..20] of char; b:integer; begin a:='foo'; fillchar(a[3],10,'x'); writeln(a); move(a[1],a[10],5); writeln(a); move(a[10],a[2],3); writeln(a) end. The correct output is: foxxxxxxxxxx foxxxxxxxfoxxx ffoxxxxxxfoxxx Procedures assgined to procedural variables can be in the main program now, so you can remove this comment for ExitProc. I think it's not a good idea to declare BP variables like ErrorAddr that are not implemented in GPC. I'd prefer a compile time error when porting a BP program using them rather than possible unexpected problems at runtime. Assign is built-in now, so you can remove it from system.pas. Str, Val, Insert and Delete will be soon... :-), perhaps also Pos, Copy, ParamCount, ParamStr, Int and Frac. Unit Dos: SearchRec, FindFirst, FindNext and GetEnv are not really BP compatible (also note the difference between SearchRec and TSearchRec in BP). SwapVectors should be declared as an empty procedure. Unit Printer: can be written now (at least for DJGPP). -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

2 1

Re: Trapping I/O runtime errors in GPC
by Frank Heckenbach 23 Oct '97

23 Oct '97

Jesper Lund wrote: > Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-} > compiler directive in Borland Pascal? Right now, the program > > var > x : real; > > begin > Readln (x); > end. > > abort with a run-time error if the user enters something that is not a > number. The same applies to ReadStr, BTW, so unless there is such a switch > (hidden) in GPC, we have to call C functions like 'sscanf' or 'atof' to > emulate the Borland 'Val' procedure. There will be a built-in Val procedure in the next beta! :-) > However, ReadStr + trapping runtime I/O > errors would be simpler, IMHO. AFAIK, Bill is working on the {$I+-} switch. (Bill, if you're reading this: The places to trap this particular error are the calls to _p_generic() in rts/rts-rdinc.c -- if you haven't done so already.) >From another mail: > I haven't found any bugs, but I have a suggestion which -- IMHO -- would > improve ValReal (the same applies to ValInteger, etc). Not necessary any more. I just completed the RTS part of the Val procedure, and Peter will build it into GPC. > [code snipped] > > COMMENTS: > > 1) The C library function converting the null-terminated string into a double > checks for errors itself (sscanf returns 0 if the string cannot be converted > to a double; meaning 0 values read from the string), so there is no need to > parse the string (to find the position where the error occurs), unless there > is an error in the string. BTW, this speedup is not possible with atof > because atof returns 0.0 if the string cannot be converted to a double. > That's why I use sscanf instead (sscanf is ANSI C, and must be in any C > library, so no concerns about portability between Linux, DJGPP, etc). > > As an aside, the string '1.1e3', is now converted to 1100.0, which is the > correct behavior. The code checking for errors should really be rewritten to > handle this. For example, the error position for '1.0ef3' is not at position > 4, but the 'f' at position 5. Adding 'e' to the list of admissible chars > would improve things a bit, but still not totally correct. In the built-in version (to come), I hope I've made all the checks at the right places. When it's released, please do as extensive tests as you can, and report any bugs you might find. > 2) The formal parameter S is declared as a string[255], instead of the schema > type 'string' (which has a different meaning than in Borland Pascal, where it > means string[255]). As you add a #0 to the string variable 's', it should be > large enough not to overflow (length gets out of range). > > I don't think the original version would work if called with a string > constant, because S would be a string with the same length as the string > constant, and adding #0 would (should) cause an exception. Yes, we discussed this topic recently. We plan to build in some functions for converting Pascal strings into CStrings easily. > 3) Unless GPC is really good at optimizing string expressions, the "hack" > > s[Length(s)+1] := chr ( 0 ) > > is faster than adding chr(0) to the string variable. Yes, it's faster. GPC is not that good yet, but I hope we'll make it that good (but not until version 2.1)... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

1 0

Trapping I/O runtime errors in GPC
by Jesper Lund 22 Oct '97

22 Oct '97

Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-} compiler directive in Borland Pascal? Right now, the program var x : real; begin Readln (x); end. abort with a run-time error if the user enters something that is not a number. The same applies to ReadStr, BTW, so unless there is such a switch (hidden) in GPC, we have to call C functions like 'sscanf' or 'atof' to emulate the Borland 'Val' procedure. However, ReadStr + trapping runtime I/O errors would be simpler, IMHO. Jesper Lund

1 0

Re: floating point constants
by Peter Gerwinski 22 Oct '97

22 Oct '97

According to The African Chief: > > > > GPC doesn't like the spaces between e and +. Use > > > > 1.79e+308 > > > > instead of > > > > 1.79e + 308 > > You were right. How odd! > > > (I am not sure what the official Pascal standard says about this; > > Me neither. Me neither. It's impossible to understand them, as usual, but I have the impression that they do not want blanks in numbers. PEP does not accept it, so at least the standard does not requiire it. > > Borland Pascal accepts the spaces). > > Then perhaps GPC also should ? I don't think so since I consider this a bug in BP, not a feature. Other opinions? 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

Problems with strings in GPC beta 971001
by Jesper Lund 22 Oct '97

22 Oct '97

I have encountered a couple problems with strings in the most recent GPC beta version. Most of the problems are due to missing range checks, e.g. when assigning a string to a shorter string, or passing a string to a procedure with a shorter string as formal parameter. 1) The program below illustrates some of these problems: program Test5; var s1 : string [500]; s2 : string [10]; type str5 = string [5]; procedure p1 (s : str5); begin Writeln (s.capacity, ' ', Length (s)); end; begin s1 := 'This is a relatively long string'; s2 := s1; { Copies all of s1 to s2; not just the first 10 characters } p1 (s1); { Passes all of s1 to procedure p1 } p1 (s2); end. Before exiting with a SIGSEGV exception (under DJGPP), the program prints 5 32 5 32 2) Another facet of the problem occurs when reading strings from a text file with Read[ln] (F, stringVar). If you call Readln, the program will read from the file until the next CR/LF, no matter the size (length) of stringVar, and try to copy the entire line to the variables stringVar (which will almost surely crash the program somehow; but not necessarily in the call to Readln. The SIGSEGV exception could come later, and with a stack trace which makes no sense). On the other hand, Read (F, stringVar) only reads a maximum of Length(stringVar) characters [as it should]. Jesper Lund

1 0

Re: Uses in implementation part of an unit
by Peter Gerwinski 22 Oct '97

22 Oct '97

According to Jesper Lund: > GPC does NOT allow "uses" in the implementation section of a unit. [...] Fixed: 8< ---- diff for parse.y ---------------------------------------------------- @@ -6123,6 +6136,7 @@ ; unit_implementation: + import_part /* This may be empty */ any_declaration_part optional_init_and_final_part ; 8< -------------------------------------------------------------------------- ... but the Automake mechanism does not handle this correctly. To work around, compile one of the units manually before automaking the program. I will try to fix this for the next beta. > In most (Borland-style) programs, moving "uses b" to the interface part (an > obvious workaround; or *solution* if the current GPC behavior is a feature > and not a bug) should not make a difference, but I imagine that there could > be a few exceptions. Yes - not only a few ones. You cite it: > The Turbo Pascal 7.0 manual says about this: > "[...] It also enables you to construct > mutually dependent units." 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

Uses in implementation part of an unit
by Jesper Lund 22 Oct '97

22 Oct '97

GPC does NOT allow "uses" in the implementation section of a unit. That is, the following piece of code cannot compile. unit a; interface <something> implementation uses b; <something> begin end. In most (Borland-style) programs, moving "uses b" to the interface part (an obvious workaround; or *solution* if the current GPC behavior is a feature and not a bug) should not make a difference, but I imagine that there could be a few exceptions. The Turbo Pascal 7.0 manual says about this: "A uses clause in the implementation section allows you to further hide the inner details of a unit, because units used in the implementation section aren't visible to users of the unit. It also enables you to construct mutually dependent units." Jesper Lund

1 0

Rewrite/Reset with filename as second parameter
by Jesper Lund 22 Oct '97

22 Oct '97

Should GPC allow passing the filename to Rewrite/Reset as the second parameter, rather than calling Assign prior to the call to Rewrite/Reset? (several Pascal compilers outside the Borland family have this feature). Currrently, the the program below compiles correctly, but at run-time it stops with the error message ?GPC runtime error: (gpc-rts) Internal file namei wrong (#700) program Test; var F : Text; begin Rewrite (F, 'test.out'); Writeln (F, 'This is a test ....'); Close (F); end. Jesper Lund

1 0

floating point constants
by The African Chief 22 Oct '97

22 Oct '97

Hi all, Why do these lines not compile? Const MAXDOUBLE = 1.79769313486231570e + 308; Const MINDOUBLE = 2.22507385850720140e - 308; Const MAXFLOAT = 3.40282346638528860e + 38; Const MINFLOAT = 1.17549435082228750e - 38; 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

3 2

Re: Gpc not accepting non-standard (?) systax.
by Peter Gerwinski 21 Oct '97

21 Oct '97

According to richard.kerry(a)quantel.com: > > type > ArgDefs = ArgDefTable value ( > ((' ', 1, 0), 0, OptionalArg, NullArg), > (('Output_File ', 1, 11), 2, OptionalArg, FileArg), > ... ); According to gpc-971001: > test.pas:28: parse error before `Value' > test.pas:29: invalid schema discriminants Uh - sorry, gpc-971001 does not recognize `value' in this context any more. This is connected with the requirement that "value" must be a redefinable identifier according to ISO-7185 Standard Pascal - which was not the case in earlier versions of GPC. A fix follows below. (Due to other changes, the new line numbers are in fact not correct, but `patch' won't care.;-) 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] 8< --------------------------------------------------------------------------- --- gpc-971001/p/parse.y Wed Oct 1 23:32:34 1997 +++ gpc/p/parse.y Tue Oct 21 23:57:02 1997 @@ -1473,12 +1475,15 @@ { if (! flag_what_pascal || (flag_what_pascal & B_D_PASCAL)) lex_const_equal = 1; + enable_keyword ("Value"); } type_denoter absolute_or_value_specification { tree d, init = $8; tree type = TREE_VALUE ($7); + disable_keyword ("Value"); + immediate_size_expand = $<itype>4; lex_caret = $3;

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