Gpc

gpc@gnu.de

5400 discussions

Re: Problem
by Peter Gerwinski 05 Nov '97

05 Nov '97

According to sam.littlewood(a)quantel.com: > > Using gpc-971001, The code below fails to compile with errors ' prior > parameter's size depends on ...'': |-O Gnuuuaaaaah! 8-( This was one of the most weird errors in earlier versions of GPC, and now IT'S BACK ... =8-O > Is this a known problem, and how might I go about fixing it? Well ... it's known - and solved - for other situations such as "ordinary" undiscriminated schemata as reference parameters. I will try to fix it until the next beta ... 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: Hex output.
by Peter Gerwinski 05 Nov '97

05 Nov '97

According to richard.kerry(a)quantel.com: > > Does gpc have a built-in mechanism for converting a number to hexadecimal, > for use in write(ln) or just as a number to string conversion ? No(t yet;-). > Oregon Pascal uses a negative field width to denote hex output (which I > believe is sometimes also used to denote left justification), and Vax > Pascal has a built-in 'hex( num, width )'. I do not think it's good to use negative field widths for this purpose (except, perhaps, for compatibility reasons). The Vax syntax, OTOH, seems quite nice for me. Right now we are still trying to finish up gpc-2.1, but we might take this into account for gpc-2.2. Hmm ... what about something like `NumBase ( base, num, width )' to allow for arbitrary bases like in `2#101010'? 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: BP PChar compatibility
by Peter Gerwinski 05 Nov '97

05 Nov '97

According to The African Chief: > > [...] Why does the following program behave differently > under BP and GPC? > [...] > StrDispose(p1); > if assigned(p1) then p2 := strnew(p1); > Writeln(p2); {GPC writes the full string; BP writes "Fred"} If `StrDispose' does what the name promises, `writeln ( p2 )' should produced *undefined* behaviour. Since BP writes "Fred" instead of producing a runtime error, BP obviously passes `p1' by *value* just like GPC. Since `p1' is a *pointer* to the actual chars, the *string* is always passed by reference - both in BP and in GPC. > StrDispose(p2); > StrDispose(p2); {should cause a runtime error - but doesn't > under GPC} This is incorrect, indeed. After the first `Dispose', the pointer should have an undefined value, so the second `Dispose' normally should crash. But in fact is is also correct "undefined" behaviour simply to ignore the second `Dispose' ... 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

Hex output.
by richard.kerry＠quantel.com 05 Nov '97

05 Nov '97

Hello, Does gpc have a built-in mechanism for converting a number to hexadecimal, for use in write(ln) or just as a number to string conversion ? Oregon Pascal uses a negative field width to denote hex output (which I believe is sometimes also used to denote left justification), and Vax Pascal has a built-in 'hex( num, width )'. Thank you in advance .. Richard.

1 0

Problem
by sam.littlewood＠quantel.com 05 Nov '97

05 Nov '97

Using gpc-971001, The code below fails to compile with errors ' prior parameter's size depends on ...'': Is this a known problem, and how might I go about fixing it? -----8<----- program prog(input,output); var v1 : array [1..10] of integer; #if 1 procedure p1(a1 : array [lo .. hi : integer ] of integer ) ; external ; { This fails } #else procedure p1(a1 : array [lo .. hi : integer ] of integer ) ; begin end; {This works } #endif begin p1(v1); end. -----8<----- Thanks. SamL

1 0

Re: Trapping I/O runtime errors in GPC
by Frank Heckenbach 05 Nov '97

05 Nov '97

Bill Currie wrote: > Actually, I meant there's no problem changing the name. That's the > advantage of a function call: the RTS implementation gets hidden > properly. It might be an advantage, but since InOutRes is documented in BP, it should be the same in GPC. Therefore, I see no problem making inline code to check InOutRes. -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

2 1

Re: File Handling
by chris＠bockermann.ping.de 03 Nov '97

03 Nov '97

Hello ! I'm very sorry for my last e-mail concerning this subject ! I had a little error with my mail-system > I don't speak Dutch, what do you mean bis den? :-) It has nothing to do with Dutch. It's German for 'Good bye' ! My mailer simply sent only the signature file (as you see, it is not inter- national, I'll change this) and forgot the Body of my mail. Ok, I'll try it once again : program file_test; var f : TEXT; { same as FILE OF CHAR, I think } begin assign(f,'filename'); { connect virtual f to physical file on disk } rewrite(f); { CREATE f or overwrite an old file with the same name as f } writeln(f,'This is a test-string'); { insert 'This..' in f and append CR } close(f); { write virtual f into 'filename' on disk and close file } end. If you want to access a file, which already exists use reset(f) instead of rewrite(f). Hope it is helpful... --Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

2 2

Re: BPCOMPAT v1.10 -released!
by Frank Heckenbach 03 Nov '97

03 Nov '97

I found another little problem in strings.pas while testing the example program from <SIMEON.9710101739.A@@muahost.cc.keele.ac.uk>: Since StrNew uses C's strdup() which in turn uses malloc(), you can't use Freemem in StrDispose. Using free() instead works. (There may be other places where such a change is necessary.) Frank -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

2 1

Re: gpc on Windows NT
by Peter Gerwinski 03 Nov '97

03 Nov '97

According to Jim Brander: > The executable gpc1.exe included in the Cygwin32 release 18 falls over > with an exception without doing anything. Its date is 19/12/96, whereas the > gcc compiler in the same release is dated 15/4/97. Does this mean that Cygnus did include a binary distribution of GPC into their CygWin32 distribution? > The source to allow recompiling and debugging gpc for NT is not included in > the Cygwin cdk source. The GPC online documentation (info -f gpc -n "Windows 95/NT") says: Windows NT and Windows 95 with cygwin32 --------------------------------------- cygwin32 is a project to make it easy to port UNIX applications to machines which run an OS which supports the Win32 API--i.e. Microsoft Windows 95 and Windows NT. Currently, cygwin32 is in beta stage; it is available from `ftp://ftp.cygnus.com/pub/gnu-win32/' Don't use gcc sources from the cygwin32 distribution. These are not just modified from FSF `gcc-2.7.2.1' to support the Windows 95/NT target, they are the "current development release", and too different from FSF GCC to be compatible with GNU Pascal, which is based on FSF sources. Instead, apply `config/cygwin32/gcc-2.7.2.1.cygwin32-beta17.diff' to FSF `gcc-2.7.2.1' to add cygwin32 platform support to GCC. The GNU pascal sources already have the cygwin32 support, so no further patching of gpc is needed Currently, cygwin32 is not self-hosting: the preferred way to build the cygwin32-gpc binary is to use a UNIX system with a cygwin32 targeting cross-compiler. *Note Crossbuilding:: > You do not provide binary for Intel-Windows NT at your ftp site. Please also try ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/beta/binary/ Another port of GNU compilers to Windows 95/NT besides CygWin32 is in preparation: mingw32. Check out http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32.html 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: Trapping I/O runtime errors in GPC
by Frank Heckenbach 02 Nov '97

02 Nov '97

The African Chief wrote: > > Actually, that's almost exactly what my mods do. If IO checking is > > enabled ( {$I+} ), a proceedure taking no parameters is called that > > would check the InOutRes state (though I used a different name) and > > if it's set dumps a dirty message and aborts the program. > > For compatibility with BP, you would need to call the variable > "InOutRes", and it should be exported, so that programmers can > set it manually if they want (this feature of BP might be > considered to be a bug by some, but I have found great use for it > ...). I've made use of it, too. Since there's no proper way to raise an I/O error, setting InOutRes seems to next best thing to do. Therefore, we'll call it InOutRes in GPC as well. Exporting it will be no problem. One little question is its type: should it be Integer as in BP, or Integer(16) (which the BP Integer is in GPC)? I'd prefer Integer as that's more natural and easier to handle in the RTS functions written in C. I hope there aren't BP programs that rely on its exact size (e.g. by passing it VAR to a procedure expecting a 16 bit Integer). Bill Currie wrote: > Good point. If I leave the check as a function call, there's no > problem, but if I go to inline code I will use InOutRes. And as long as it's a separate RTS function, I will use InOutRes, too... :-) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de http://home.pages.de/~fjf/links.htm

3 2

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