Gpc November 1997

gpc@gnu.de

32 participants
113 discussions

BP string compatibility
by Frank Heckenbach 18 Nov '97

18 Nov '97

The African Chief wrote: > Problem: > Under BP, one can do; > Var S:String; > Count:Integer; > .... > Dec(S[0], Count); > > This does not compile under GPC, but "Dec(Length(S), Count)" > compiles, and seems to work okay. Then I think this is a bug in GPC, and must be prevented. The Length field of a string should only be accessible read-only. However, there is (in the current developer version, not yet in the last beta) a built-in function AssignLength which is the proper way to directly wirte to the length field of a string (if messing with the length can be called proper at all... ;-) > Observation: > This is an incompatbility b/w BP and GPC - probably > because of the way strings are implemented under GPC. Right. > Questions: > 1. Is GPC ever going to support the BP syntax "Dec(S[0], Count);" > ? Short answer, yes, sometime. More details can be found in some other discussions in the list. > 2. Is it desirable to do so ? Yes. Mainly for the reason you described. > (obviously this would entail changes to the internal GPC string > format ???) Not changes to the "real" Pascal strings; rather, it would mean introducing a new string type with automatic conversions as far as possible. -- Frank Heckenbach, Erlangen, Germany fjf(a)gmx.de http://home.pages.de/~fjf/links.htm

2 1

BP string compatibility
by The African Chief 18 Nov '97

18 Nov '97

Hi all Problem: Under BP, one can do; Var S:String; Count:Integer; .... Dec(S[0], Count); This does not compile under GPC, but "Dec(Length(S), Count)" compiles, and seems to work okay. Observation: This is an incompatbility b/w BP and GPC - probably because of the way strings are implemented under GPC. Questions: 1. Is GPC ever going to support the BP syntax "Dec(S[0], Count);" ? 2. Is it desirable to do so ? (obviously this would entail changes to the internal GPC string format ???) Best regards, The Chief -------- Dr. Abimbola A. Olowofoyeku (The African Chief) Email: laa12(a)keele.ac.uk Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ Author of: Chief's Installer Pro 4.01 for Win16 and Win32: http://www.simtel.net/pub/simtelnet/win3/install/chief401.zip

1 0

None
by Jim Brander 18 Nov '97

18 Nov '97

Further to the previous message about a problem with sets in the cygwin version. The following program causes the compiler to crash in construct_set. The crash does not occur if the set definition is directly in the program rather than imported. The crash occurs whether the interface is in the same or separate files. # 1 "/Orion/pas/creatvar.pas" module data1 interface; export data1_interface = (usage1); type usage1 = (sysusage,sysgen,syscopy,master); end. module creatvar; export creatvar_int = (create_var); import data1_interface; procedure create_var(use1:usage1);C; end; procedure create_var; var i,j,k,l:integer; begin if not (use1 in [syscopy,sysgen]) {<<<<<<<<<-------<} then begin end; end; end. In addition, the module abc interface; end. module abc implementation; end. style of unit seems to have problems in carrying simple definitions forward, whereas the alternative style module does not. Regards Jim Brander

1 0

Assign statements in GNU Pascal
by Badri Gomatam 18 Nov '97

18 Nov '97

Hello all: I am new to gnu pascal, so this is a newbie question: I have a _ton_ of code written ca. 1992/3 on Borland Pascal 5.0 which for various reasons I need to port to a Unix environment: the present version runs on DOS: I downloaded the binary for linux-(i386) and installed on my linux box..no problems (at least, not yet:) (i have gcc 2.7.2)...thinking "i'll just do gpc on these files and all will be OK "...:) when i compiled one of the (several hundred) files i have in my legacy code (for which the programmer has left and gone to a better life on another planet) I got errors involving the following: 1. ASSIGN statement appears as undeclared identifier (use this function first.. sounds like a gcc type error for undeclared function identifiers) isn't this a "standard" pascal fn? if not, what do i do now? 2. all directives were flagged as errors e.g {$O+ foo) was unrecognized ($I+ foo) was OK, complained couldn't open the file foo.pas (which turned out to be right).. so the syntax of {$xx} appears to work basically i don't really know what the $O+ does..besides being called an overlay: this entire body of code apparently has to be compiled in Borland Pascal with "Overlay ON"... does anybody know what that means, and how I could move to gpc smoothly: is there a list of stuff in BP5.0 that's NOT in GPC and vice versa? am i in trouble with many other built in functions..e.g I do need the DELAY function (i think it's built in) to wait a given delay time is this available in gpc? many thanks ( and i have a feeling i'll be posting many msgs to this forum) badri

1 0

Re: undeclared identifiers
by Peter Gerwinski 17 Nov '97

17 Nov '97

Hi, Tom! Hi, all! According to Tom Dye: > > A while back I forwarded a bit of extended Pascal code that I thought > should compile with gpc, but doesn't. > [...] > I suspect that I have found something that gpc does not do correctly, ... Indeed, but I have posted a patch to `module.c' at this list on 10 November that fixes the problem (and causes some others which are fixed meanwhile in my development version;-). Your example modules work fine on my Linux box. > ..., but I am far from confident that my suspicion is correct. > Here are my other suspicions: > > a) I don't have gpc built correctly. I had some problems getting gpc to > compile on my Linux box and can't really say what I did to make it > compile--that is which change really made a difference. Could I be having > problems with an incorrectly built gpc? Did you apply the patch from 10 November? (But don't throw your working GPC away because the patch causes other problems which will be fixed in the next beta release.) > b) the code in examples 1) and 3) relies on a feature of extended Pascal > that gpc does not yet implement. I am relatively new to gpc and to > extended Pascal and can't answer this one myself. Does the code in > examples 1) and 3) fail because of an unimplemented feature of extended > Pascal? No. The last of the features needed to compile 3), export renaming, was implemented into GPC somewhere in spring 1997. 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

None
by chris＠bockermann.ping.de 17 Nov '97

17 Nov '97

Subject: Re: Dodgy email To: richard.kerry(a)quantel.com Date: Mon, 17 Nov 1997 15:14:18 +0100 (MET) From: "Christian Bockermann" <chris(a)bockermann.ping.de> Cc: gpc(a)hut.fi In-Reply-To: <80256552.00422CA2.00(a)buffer1.quantel.com> from "richard.kerry(a)quantel.com" at Nov 17, 97 12:08:55 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 826 Hello ! Richard.Kerry(a)Quantel.com wrote : > > Does anyone recognize any of the names in the following extract : > > ------------------------- Could not deliver Message to > ------------------------- > CN=??r J Rodriguez/O=almenna kerfisfraedistofan@almenna kerfisfraedistofan > > User ??r J Rodriguez/almenna kerfisfraedistofan@almenna kerfisfraedistofan > not > > ------------------------- > > I am getting this whenever I send a message to the mailing list. I am told > that the names are not in the list explicitly. Does anyone have them in a > sub-list ? Or recognize them from anwhere else ? Yes ! I get the same error-message when sending e-mail to the list ! I also do not know why ... :-( -- Chris e-mail > chris(a)bockermann.ping.de ____________________________________ (subject "send pgp-key" for pgp-key)

1 0

Re: `case' statments: `default' and `others'
by richard.kerry＠quantel.com 17 Nov '97

17 Nov '97

Peter Wrote: According to richard.kerry(a)quantel.com: > [`begin/end' after `otherwise' ...] > [...] > Oh, and the lack of trailing colon is easier as that's the way Oregon has > it. Again, if it's optional it doesn't matter. Just to be sure that I have understood everything correctly: It is okay for you if we drop the colon after `otherwise' (i.e. forbid it) as long as we do not forbid a `begin/end' pair after `otherwise'? ------- That is correct. Oregon has no colon, and has 'statement' not 'statement-list' ie. it requires begin/end if there is more than one statement. It always has the Otherwise after all the cases. Richard.

1 0

Dodgy email
by richard.kerry＠quantel.com 17 Nov '97

17 Nov '97

Does anyone recognize any of the names in the following extract : ------------------------- Could not deliver Message to ------------------------- CN=??r J Rodriguez/O=almenna kerfisfraedistofan@almenna kerfisfraedistofan User ??r J Rodriguez/almenna kerfisfraedistofan@almenna kerfisfraedistofan not ------------------------- I am getting this whenever I send a message to the mailing list. I am told that the names are not in the list explicitly. Does anyone have them in a sub-list ? Or recognize them from anwhere else ? Richard.

1 0

Re: `case' statments: `default' and `others'
by Peter Gerwinski 17 Nov '97

17 Nov '97

According to richard.kerry(a)quantel.com: > [`begin/end' after `otherwise' ...] > [...] > Oh, and the lack of trailing colon is easier as that's the way Oregon has > it. Again, if it's optional it doesn't matter. Just to be sure that I have understood everything correctly: It is okay for you if we drop the colon after `otherwise' (i.e. forbid it) as long as we do not forbid a `begin/end' pair after `otherwise'? So it will be correct to write case foo of 1: writeln ( 'foobar!' ); otherwise writeln ( 'foo?' ); writeln ( 'bar!' ); end (* case *); as well as case foo of 1: writeln ( 'foobar!' ); otherwise begin writeln ( 'foo?' ); writeln ( 'bar!' ); end (* otherwise *); end (* case *); but GPC will reject case foo of 1: writeln ( 'foobar!' ); otherwise: writeln ( 'foo?' ); writeln ( 'bar!' ); end (* case *); or case foo of 1: writeln ( 'foobar!' ); otherwise: begin writeln ( 'foo?' ); writeln ( 'bar!' ); end (* otherwise *); end (* case *); or case foo of otherwise: begin writeln ( 'foo?' ); writeln ( 'bar!' ); end (* otherwise *); 1: writeln ( 'foobar!' ); end (* case *); 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: `case' statments: `default' and `others'
by richard.kerry＠quantel.com 17 Nov '97

17 Nov '97

Peter Wrote : I am currently fixing the bug with `otherwise' in `case' statements. While the ISO 10206 Extended Pascal standard wants case foo of (* 1 *) bar: writeln ( 'foobar!' ); otherwise write ( 'The answer is: ' ); writeln ( answer ); end (* case *); GPC implemented case foo of (* 2 *) bar: writeln ( 'foobar!' ); otherwise: begin write ( 'The answer is: ' ); writeln ( answer ); end (* otherwise *); end (* case *); which is simply wrong. Okay - when I fix it, does anybody want to keep an optional colon after `otherwise'? Or after `else' in the Borland syntax? (I would prefer if *not*.) --------- surely, since you need begin/end in : case foo of (* 1 *) bar: begin writeln ( 'foobar!' ); writeln ( 'again' ); end; you should need them in : otherwise: begin write ( 'The answer is: ' ); writeln ( answer ); end (* otherwise *); Having said that, it doesn't matter unless you explicitly stop them being usable there, but since you'd be making it accept statement-list rather than statement it'll still be usable. (I have three-hundred plus modules to convert so I look very carefully at suggestions to restrict the syntax accepted.) Oh, and the lack of trailing colon is easier as that's the way Oregon has it. Again, if it's optional it doesn't matter. -------------- Peter Wrote : I also found `default' and `others' as synonyms for `otherwise' which I would like to remove. what about removing `&' as an address operator and to keep only the BP-compatible `@'? -------------- These are ok by me as our Oregon-to-gpc translator can do these either way, and Oregon uses Otherwise. Richard.

1 0

← Newer
1
2
3
4
5
6
7
...
12
Older →

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 November 1997