Gpc October 1997

gpc@gnu.de

31 participants
158 discussions

Re: Trapping I/O runtime errors in GPC
by Peter Gerwinski 24 Oct '97

24 Oct '97

According to Bill Currie: > On 23 Oct 97 at 10:43, Peter Gerwinski wrote: > > According to Jesper Lund: > > > Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-} > > > compiler directive in Borland Pascal? [...] > > > > Not yet, but it is being worked on. (Interested to take part?;-) > > Agh, does that mean I have to pull my finger out? Of course not. I was referring to your work, and I simply wanted to attract co-workers to your project. (-; > I think I've got the compiler side working in an older beta, but the > rtl has to be modified to support it. > > Problem is, {$I-} could be even longer yet because I'm changing jobs > (cities too) soon and I don't know how long I'll be off the net > (going off shortly before 17 Nov) > > I should at least be able to get some patches relative to the latest > beta (I think I still have to download it) before then. This would mean that it would be in the next beta and in gpc-2.1 - which would be a good thing. Thanks in advance, 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: BPCOMPAT v1.10 -released!
by Peter Gerwinski 24 Oct '97

24 Oct '97

According to The African Chief: > > Any thoughts on whether the system unit should now export this > AddNull function so that it can be available globally? This would > introduce something which is not in the BP system unit. I would suggest to export it on request if an "extensions too" switch has been (*$define*)d. 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

Re: Trapping I/O runtime errors in GPC
by Peter Gerwinski 24 Oct '97

24 Oct '97

According to Jesper Lund: > Is there a (simple) way of trapping runtime I/O errors in GPC, like the {$I-} > compiler directive in Borland Pascal? [...] Not yet, but it is being worked on. (Interested to take part?;-) > [...] to emulate the Borland 'Val' procedure. `Val' is being worked on as well. 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]

2 1

Error while compiling simple Pascal-Program
by chris＠bockermann.ping.de 23 Oct '97

23 Oct '97

Hello all there ! I have installed version 2.3 of the gnu assembler (gas) but now I get an error when compiling my pograms. I wrote a little test program like this : program test; var ch : char; begin ch:='x'; writeln(ch); end. and the error I get is : chris@bockermann:/home/chris/programs/pascal/test-prgs > gpc --automake test.p /tmp/cca00462.s: Assembler messages: /tmp/cca00462.s:4: Error: Unknown pseudo-op: `.local' /tmp/cca00462.s:5: Error: Rest of line ignored. First ignored character is `,'. /tmp/cca00462.s:6: Error: Unknown pseudo-op: `.local' /tmp/cca00462.s:7: Error: Rest of line ignored. First ignored character is `,'. /tmp/cca00462.s:8: Error: Unknown pseudo-op: `.local' /tmp/cca00462.s:9: Error: Rest of line ignored. First ignored character is `,'. /tmp/cca00462.s:10: Error: Unknown pseudo-op: `.local' /tmp/cca00462.s:11: Error: Rest of line ignored. First ignored character is `,'./tmp/cca00462.s:14: Error: Alignment too large: 15. assumed. /tmp/cca00462.s:37: Error: Alignment too large: 15. assumed. /tmp/cca00462.s:50: Error: Alignment too large: 15. assumed. /tmp/cca00462.s:58: Error: Unknown pseudo-op: `.section' /tmp/cca00462.s:61: Error: Alignment too large: 15. assumed. /tmp/cca00462.s:73: Error: Unknown pseudo-op: `.section' /tmp/cca00462.s:78: Error: Alignment too large: 15. assumed. Does anybody know, what's wrong ? -- Bis denn, Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

1 0

Pointer arithmetics (was: BPCOMPAT v1.10 -released!)
by Peter Gerwinski 23 Oct '97

23 Oct '97

According to Frank Heckenbach: > 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): [...] Pointer arithmetics is portable and can be used here to speed it up: Procedure FillChar ( Var Dest: Void; Count: Integer; C: Char ); Var DestArray: tCharArray absolute Dest; z: ^Char; begin (* FillChar *) for z:= @DestArray [ 0 ] to @DestArray [ Count - 1 ] do z^:= C; end (* FillChar *); (Similar for `move'.) BTW, pointer arithmetics ... should GPC allow constructions like (*$X+*) Var p, q: ^Char; p:= q + 42; or only p:= succ ( q, 42 ); ? Personally, I would prefer to allow only the second (Pointer being an ordinal type) and to consider the first (Pointer + Integer) an error, but it's technically easier to allow both, so I ask before I remove a bug somebody might consider a feature. ;-) 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]

2 1

BPCOMPAT v1.10 -released!
by The African Chief 23 Oct '97

23 Oct '97

Hi all I have just uploaded BPCOMPAT v1.10 to agnes (in the contrib directory). You can download it as; ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bpcompat.zip and ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/contrib/bpcompat.txt This version contains some bug fixes, and some stuff to improve portability (especially of the SYSTEM unit). Users of Linux and unix systems should find that the SYSTEM unit will now compile ("__UNIX__" is now predefined for Linux, Solaris, and FreeBSD - other unix users will need to define it manually). There are probably still some remaining bugs, and the package is still not a complete replacement for the BP RTL. However, things are improving. The ZIP file has been restructured (with a directory tree) so that the files are easier to locate and manage. The package needs improvement, and all contributions are welcome! BUGS ---- If you find bugs, please try to fix them - but please report them to me as well. If you fix them, please let me have a copy of the fix. Happy coding! Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Author of: Chief's Installer Pro 4.01 for Win16 and Win32: Winner of PC PLUS Magazine Gold Award (April 1995 U.K. edition) http://ourworld.compuserve.com/homepages/African_Chief/ ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/chief/pro/chief401.zip

2 2

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

← Newer
1
...
4
5
6
7
8
9
10
...
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