Gpc October 2001

gpc@gnu.de

45 participants
80 discussions

back to strings and fillchar
by Oldham, Adam 23 Oct '01

23 Oct '01

I have been going through some test cases to test some instances of things.... This has led me to another question. It appears that it you define a record with a string in it and then declare it or new it. Both store the capacity of the string in the schema. And Both 0 out the entire string. If the string is going to be zeroed out by default, why not just 0 out the entire data structure? Or all data structures 0'd by default? Adam ----------------------------------------------------------------------- C. Adam Oldham Marconi Commerce Systems Inc. Software Engineer 7300 West Friendly Ave. adam.oldham(a)marconi.com Greensboro, NC 27420-2087 Phone : 336.547.5952 Fax : 336.547.5079 ----------------------------------------------------------------------- This document contains confidential information of Marconi Commerce Systems Inc. In consideration of the receipt of this document, the recipient agrees not to reproduce, copy, use or transmit this document and/or the information contained herein, in whole or in part, or to suffer such actions by others, for any purpose except with written permission, first obtained, of Marconi Commerce Systems Inc., and further agrees to surrender the same to Marconi Commerce Systems Inc. upon demand. -----------------------------------------------------------------------

2 1

problem_with_reset_rewrite_commands
by michael pfeiffer 22 Oct '01

22 Oct '01

I am beginner in pascal programming. I apply the gpc-compiler on a computer at home, running under linux (suse 6.0 distribution). Some self made programs run well, but my problem is application of reset, rewrite commands. Please give me a hint, how to solve it. The situation: With the var g:text;s:string[5] in the main program the sequence s:='alpha'; rewrite(g,s); writeln(g,'test'); . results in a runtime-code a.out (o.k.) When I let run it applying ./a.out the program standing before the above given sequence runs well, but then it stops with ?Gpc runtime error:(gpc-rts)'Internal file namei wrong (#700)'. As a result a file named 'alpha' with zero content is created. Applying the reset(g,s);readln(g,s1); I obtain ?GPC runtime error:File is not open for reading(#14). What is my mistake? I would be highly thankful for a hint to solve the problem. Yours sincerely Michael Pfeiffer

3 2

Re: Errors and Standards (was: compiler bug)
by da Silva, Joe 22 Oct '01

22 Oct '01

Oops! Forgot to fiddle the send address, yet again! :-( Please see below ... Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Saturday, October 20, 2001 7:57 AM > To: gpc(a)gnu.de > Subject: Re: Errors and Standards (was: compiler bug) > > J. David Bryan wrote: > > > On 19 Oct 2001, at 1:33, Frank Heckenbach wrote: > > > > > So, the following program would be allowed to output 0, according to > the > > > standard (because i might be mapped to an I/O address that happens to > > > always yield 0)? I strongly doubt it? > > > > Well, you've caught me without my copy of the standard at hand :-), but > as > > I recall, there is a requirement that operations on integers must follow > > > the rules of integer math. I can't check whether assignment is one of > > those operations listed, but it seems reasonable. So, no, the program > you > > cited wouldn't be a conforming program (pending confirmation from the > > standard). > > I hope so. > > > But how could the compiler possibly enforce this? Binding to RAM vs. a > > mapped I/O port (or to ROM) would be done at link time, so must the > > compiler issue a warning for the "var" statement that variables must be > > bound to RAM? How else can we disallow such a program? > > I think a "processor" according to the standard includes the > compiler as well as the linker. Whether in practice a compiler alone > [Joe da Silva] Yes, in the case of GPC, the "processor" must mean the compiler _and_ linker (it doesn't make sense to talk about just half a "processor" ;-). On the topic of "binding" variables, my understanding is that any variables declared in the "var" block of a program are local to the program and exist only during the execution of the program, unless they are included in the program's parameter list - just like file variables! Suppose there is an implementation-dependent system variable called "user", that contains a string (with the user's name). Now, if the "processor" has a predefined binding for this variable, a program could reference it, _without_ defining it in the "var" block. However, if "user" were defined in the program's "var" block, then this would be a _local_ variable called "user", not the predefined system variable (assuming of course it isn't also included in the program's parameter list)! So, in your previous example, where you defined a variable called "i" and assigned it the value 42, this variable could not have any other binding - it is simply a normal variable and must behave as such! > (such as GPC) that might be used in conjunction with various linkers > could be 100% conforming, is another question (and the answer is > probably no, without making some requirements on the linker and > forbidding the user of linker scripts etc.). > > > > Yes, but some things (like that the program above should write 42, > > > possibly preceded by a number of spaces) are guaranteed, I think. > > > > Unfortunately, what you and I think has no bearing on the matter. Only > > what the standard "thinks" is important! ;-) Cite a passage from the > > standard that states that main program block-level variables may not be > > bound to external entities, and I will concede your point happily. > > I'm just packing my bags and will be gone for the weekend, but I'll > look when I'm back ... > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Errors and Standards (was: compiler bug)
by da Silva, Joe 22 Oct '01

22 Oct '01

On the subject of missing "output" as a program parameter, or in the more general case, where the program header has no parameters at all (assuming of course "input" and "output" are neither explicitly nor implicitly used), Peter Grogono (in his book 'Programming in Pascal') says words to the effect of : It is legal to omit the parameters from the program header, provided neither "input" or "output" is used, however, a program which provides no input or output is generally not very useful. The above has an element of humour in it, but makes it quite clear that it is perfectly legal to omit "input" and/or "output" from the program header if these are not used. Note that the above is not an exact quote, just from memory, however, I could spend a bit of time to locate the exact text, if required. On the subject of standards, please see below ... Joe. > -----Original Message----- > From: J. David Bryan [SMTP:dbryan@bcpl.net] > Sent: Wednesday, October 17, 2001 6:04 AM > To: GNU Pascal List > Subject: Re: compiler bug > > On 16 Oct 2001, at 20:34, Frank Heckenbach wrote: > > > I don't see a big difference between `--standard-pascal' and > > `--iso-pascal'.... > > I don't either, except it removes the possibly misleading word "standard" > (implying that "standard-pascal" is standardized or preferred, whereas > "extended-pascal" is not -- I hope I now take Joe's point correctly :-). > [Joe da Silva] Yes, you do! :-) I find that awareness of the Extended Pascal Standard is unsatisfactory, and in promoting Pascal, we need to improve this. IMHO, we should avoid any inference that ISO-7185 is the only standard, likewise any inference that Extended Pascal is non-standard. > > (EP is also ISO). > > Hence the suggestion of "--iso-extended-pascal". The title pages of the > respective standards say, "Pascal" and "Extended Pascal," so my suggestion > > incorporated those titles in the switch names. > > > > So if anything, I'd tend to `--classic-pascal' or so. > > "Classic Pascal" is meaningless to me (it's actually more suggestive of > some variant with proprietary extensions, as the ISO standard was never > "classic" in the sense that it was the version that everyone used; GPC is > the first Pascal compiler I've used -- and I've used many -- that provides > > a strict ISO 7185 option). > [Joe da Silva] "Classic" is a perfect description of ISO-7185 (thanks, Prospero), since it corresponds exactly (well, with just one change, suggested by Wirth) to the language originally defined in the 'User Manual and Report' published by Jensen and Wirth, in 1974. An alternative description would be "minimalist", but "classic" sounds much nicer! <g> > I'm happy with "--standard-pascal" and "--extended-pascal" if everyone > else > is. > > > > And every user who uses the option would have to change it ... > > Which may be the best argument for leaving it alone. > > -- Dave

4 15

Re: Errors and Standards (was: compiler bug)
by Frank Heckenbach 22 Oct '01

22 Oct '01

(I assume you hit the wrong reply button, and the mail was meant for the list. ;-) > > J. David Bryan wrote: > > > > > But how could the compiler possibly enforce this? Binding to RAM vs. a > > > mapped I/O port (or to ROM) would be done at link time, so must the > > > compiler issue a warning for the "var" statement that variables must be > > > bound to RAM? How else can we disallow such a program? > > > > I think a "processor" according to the standard includes the > > compiler as well as the linker. Whether in practice a compiler alone > > > [Joe da Silva] > > Yes, in the case of GPC, the "processor" must mean the > compiler _and_ linker (it doesn't make sense to talk about > just half a "processor" ;-). So everything the linker does must be according to the standard as well. (Of course, we can't really enforce this in GPC, except telling people, don't use any weird linker scripts if you want to be conformant. ;-) > On the topic of "binding" variables, my understanding is > that any variables declared in the "var" block of a program > are local to the program and exist only during the execution > of the program, unless they are included in the program's > parameter list - just like file variables! > > Suppose there is an implementation-dependent system > variable called "user", that contains a string (with the > user's name). Now, if the "processor" has a predefined > binding for this variable, a program could reference it, > _without_ defining it in the "var" block. However, if "user" > were defined in the program's "var" block, then this would > be a _local_ variable called "user", not the predefined > system variable (assuming of course it isn't also included > in the program's parameter list)! > > So, in your previous example, where you defined a variable > called "i" and assigned it the value 42, this variable could > not have any other binding - it is simply a normal variable > and must behave as such! Then we agree. If I understand you correctly, the following might be valid if `user' is predefined: program Foo (Output); begin WriteLn (user) end. That's no valid SP program because `user' is undefined, but such implementations that define it as an extension would accept it. So, there could be programs with no parameters that "do something" (if the predefined variables are also used for output purposes), but such programs would not be strictly conformant. So, it seems again that a conformant program with no parameters is "pointless". Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ PGP and GPG keys: http://fjf.gnu.de/plan

1 0

Re: Errors and Standards (was: compiler bug)
by da Silva, Joe 22 Oct '01

22 Oct '01

Well, from memory, a procedure or function parameter in J&W looked something like the following example : program test; .... procedure fred (function smith : integer); .... function one (x : boolean) : integer; .... function two (x, y : integer) : integer; .... begin {test} .... fred(one(true)); .... fred(two(1,2)); .... end. {test} Notice how the formal parameter in procedure "fred" is a function ("smith") of known type (integer) but unknown parameters? Dr. Wirth later decided this was unsafe, so when the ISO-7185 standard was formalised, this was changed (now the formal parameter, function "smith", must show it's formal parameters too). This also applies to ISO-10206, of course. Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, October 18, 2001 11:47 PM > To: gpc(a)gnu.de > Subject: Re: Errors and Standards (was: compiler bug) > > da Silva, Joe wrote: > > > Correct. Conformant arrays are optional, so that isn't the > > *real* change to the language ... It is this : > > > > When you have a procedure or function (A), as a formal > > parameter of another procedure or function (B), you must > > declare it's (A) formal parameters (as shown in example > > 6 in section 6.11.6 of ISO-10206; there's probably a similar > > example given in ISO-7185, although haven't looked for it). > > > > This (declaring the formal parameter of a formal parameter ;-) > > wasn't required in the original language definition, in the > > "User Manual and Report". > > What do you mean exactly? Did they allow parameter names to be > omitted (syntax?), or no parameter list at all? The latter would > seem strange to me since it would be type-unsafe. > > Could you give an example of something that's valid in J&W, but not > ISO 7185? > > > "Otherwise" was a common and useful extension to > > the language, but *non-standard*, prior to ISO-10206 (of > > course, Borland recycled the word "else", just to be > > different!). > > ... and to introduce yet another ambiguity into their dialect ... > > Frank > > -- > Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ > GPC To-Do list, latest features, fixed bugs: > http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: Is this a bug that is planning to be fixed (from documentatio
by Oldham, Adam 22 Oct '01

22 Oct '01

Well, Unfortunately, this is bad for us here. SVS and some of the old Oasis Pascal and other Pascal compiler developed back in the mid and early 1980s allowed this split interface/implementation method declaration in different Units. This allows one Unit to act as a sort of header file (like in C) and the other Unit to actually define the function. In this way, you can have a global type repository of Units that only contain Interface declarations. When dealing with an App like ours where you are dealing with 500000 to 900000 lines of code in 200-400 files in 10+ project trees, changing something as simple as this could end up being a hufe proposition. That would be on top of the changes to FILLCHARing records, Strings that aren't of the "BP String" type, and other differences we find. As for Mangled Names? Are you going to move more towards name Mangling much like FPC uses? If so, couldn't create a flag that would just keep all functions from using the Mangled Name? FPC does things much in this way, and I worked on modifying the compiler to allow this method in split interface/implementation type of thing. I ran into other problems getting it to work correctly (I'll spare the list the details) but for the most part, it worked. Adam -----Original Message----- From: Frank Heckenbach [mailto:frank@g-n-u.de] Sent: Thursday, October 18, 2001 7:09 PM To: gpc(a)gnu.de Subject: Re: Is this a bug that is planning to be fixed (from documentatio n)? Oldham, Adam wrote: > So, once this bug is fixed, will function declarations in the interface and > function bodies in implementation sections of different files be allowed, > like they are today? Different files for the same module, yes (unfortunately, since EP more or less requires this, though it doesn't directly talk about source files). Different units/modules, no. > And if not, can the bug sort of be left for > compatibility with other Pascal Languages that do utilize this method? Say > with maybe a command line parameter? Which compiler uses this method? I only know compilers that require such routines to be declared as `external' or similar, and GPC will (continue to) allow this as well. Disabling this check would be easy at first, but once we introduce qualified identifiers, the method won't work, since the implementation would choose another "mangled linker name" (if you don't know what that means, please ignore it) than the interface declaration, and without an explicit specification (such as `external' and/or `asmname'), it won't work. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

Re: installation problems
by Oldham, Adam 22 Oct '01

22 Oct '01

As I stated in my last email, I used the exact same linking command lines, on with -lm, one without. So that is: gcc -static `cat lnk.tmp` -lgpc -lgcc -lpthread -lpanel -lncurses -Xlinker -Map rds.map -and- gcc -static `cat lnk.tmp` -lm -lgpc -lgcc -lpthread -lpanel -lncurses -Xlinker -Map rds.map I also used -v in both command lines without in further useful information being output. Upon further research, libm comes with glibc, or at least the glibc package. I'm going to dive deeper into this and will post my results. Adam -----Original Message----- From: Frank Heckenbach [mailto:frank@g-n-u.de] Sent: Friday, October 19, 2001 10:53 AM To: gpc(a)gnu.de Subject: Re: installation problems Oldham, Adam wrote: > I have added the -lm for the math library to the link statement, no changes > result in my desired output. I tried that yesterday. Then please post the exact command line that you used, including -lm. > Is the Math Library part of the gcclib package that is compiler dependant? As I said, no. Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

--object-destination-path
by Preben Mikael Bohn 21 Oct '01

21 Oct '01

Hi all, I'm trying to use --object-destination-path=obj to place all *.o files in the directory 'obj'. However it won't work... What do I do wrong? The complete line is: gpc --object-destination-path=./obj/ --automake main.pas I'm using version 20010924 and I have placed main.pas and test.pas in the current dir, and their content is (but this probably doesn't matter): program main; uses test; begin writeln('main'); testfunc; end. unit test; interface procedure testfunc; implementation procedure testfunc; begin writeln('test'); end; { testfunc } end. Best regards Preben Bohn ===== The two rules for success are: 1. Never tell them everything you know. ____________________________________________________________ Nokia Game is on again. Go to http://uk.yahoo.com/nokiagame/ and join the new all media adventure before November 3rd.

4 5

Re: installation problems
by Oldham, Adam 19 Oct '01

19 Oct '01

SOrry Frank, I have added the -lm for the math library to the link statement, no changes result in my desired output. I tried that yesterday. Is the Math Library part of the gcclib package that is compiler dependant? Adam -----Original Message----- From: Frank Heckenbach [mailto:frank@g-n-u.de] Sent: Friday, October 19, 2001 8:23 AM To: gpc(a)gnu.de Subject: Re: installation problems Oldham, Adam wrote: > Sorry Frank, here is the complete report: > I link a rather large application (500+ Pascal files with 20 C files) into > one executable. I precompile everything as objects and then perform the > following commands to link: > find /src -name '*.o' -exec echo -n {} " " \; > lnk.tmp > echo -n /src/os/os.a " " >> lnk.tmp\ > touch rds.map > gcc -static `cat lnk.tmp` -lgpc -lgcc -lpthread -lpanel -lncurses -Xlinker > -Map rds.map So, there's no -lm. Just add it. (gpc does this automatically, together with -lgpc, but it you link with gcc, you have to provide both explicitly.) You might have to find the correct library order (porbably -lgpc -lm I think). > Someone needs to write these companies like Mandrake, Redhat, Suse and get > them to stop using these bad compilers. People have been complaining about > this 'v2.96' compiler for 2 years now and they are still distributing them. > It's a real pain and trying procedure to get that compiler off and still > have their stock programs run correctly (because of library dependencies). And I've heard SuSE has a broken GPC installation in their recent distribution again (they had one some years ago, and it took some letters from Peter to make them fix it). Any volunteers? :-/ Frank -- Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/ GPC To-Do list, latest features, fixed bugs: http://agnes.dida.physik.uni-essen.de/~gnu-pascal/todo.html

2 1

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 2001