Gpc

gpc@gnu.de

5400 discussions

Test
by Frank Heckenbach 25 Oct '01

25 Oct '01

My apologies, I know one shouldn't send test messages to mailing lists, but I've been having severe problems with the list software and I just have to check that everything's working again as far as I'm concerned. Frank

1 0

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

24 Oct '01

Sorry if I wasn't clear ... when I said "my understanding is ...", what this meant (and BTW, I thought this would be clear from the subject being discussed) was "my understanding of the standard(s) is ...". So, if you have specific areas where you believe that I have contradicted the standard(s), please indicate the particulars, so we can both double-check it. BTW, you should note that we are in agreement that a program without a parameter list is perfectly legal. As to whether such a program is "pointless", please note that any such inference (which arose when I semi-quoted Peter Grogono), was nothing more than a bit of humour. Now, specific to your situation, a very quick check of the ISO-10206 standard revealed the following : Technical development section : d) Binding of variables. -A variable may optionally be declared to be bindable. Bindable variables may be bound to external entities (file storage, real-time clock, command lines, etc.). Only bindable variables may be so bound ... 6.2.3.5 section : .... Each variable contained by an activation of a block or module, unless it is a program-parameter or module-parameter, shall be created not bound to an external entity .... 6.7.5.6 section : Binding procedures ... {stuff about "bind" ...} I'm sure there's plenty of other stuff in the standard relevant to this, of course. Like I said, this was just a quick check ... Joe. > -----Original Message----- > From: J. David Bryan [SMTP:dbryan@bcpl.net] > Sent: Tuesday, October 23, 2001 1:26 AM > To: GNU Pascal List > Subject: Re: Errors and Standards (was: compiler bug) > > On 22 Oct 2001, at 15:43, da Silva, Joe wrote: > > > On the topic of "binding" variables, my understanding is... > > It is not my intent to argue simply for the sake of arguing. Honestly! > But if we're going to decide Pascal issues on the basis of understandings > and beliefs, then why have standards? > > I have found over time that many of my understandings as to how things > work > turn out to be wrong when I examine the systems in detail. Here, > fortunately, we do not have to decide how Pascal works by trial and error. > > We have a standard that says explicitly how things are supposed to work. > > I plead that we cannot make GPC standards-compliant if we base its > operation on our belief and assumptions. Instead, we must structure GPC's > > operation strictly according to the semantics outlined in the relevant > standards -- at least, we do if we want to claim compliance. > > > > ...this variable could not have any other binding - it is simply a > normal > > variable and must behave as such! > > Can you support the "must" with a citation from the standard? > > I work with embedded systems, i.e., microprocessor-based controller cards. > > I develop these "bare board" controllers using Pascal, specifically, on an > > HP development system. On that system, the Pascal compiler separates the > program code and static data (i.e., main block-level data). It does this > so that the code may be burned into ROM. > > The particular processor that I target, the Motorola M68K family, has no > I/O instructions. All I/O is memory-mapped, i.e., I/O is performed by > normal reads and writes to address locations that are mapped to specific > hardware registers instead of RAM. Because there is no controlling > operating system on these boards, there is no implementation of program > parameters (because there is nothing "outside" of the program). > > So in this application, I/O devices are represented in the Pascal programs > > as main block-level variables. A serial port configuration register might > > be mapped to an "integer" variable, for example. The actual mapping of > variables to devices is done by the linker, which allows the specification > > of the addresses at which the variables are to be assigned. > > So the programs that control these boards have no program parameters and > no > "read" or "write" calls; they control the machines in which they are > embedded through the mechanism of variable mapping. These programs cannot > > be classified as "pointless." > > But are they legal Pascal? That is, do they conform to the syntax and > semantics of the standard? > > They conform to the syntax, surely (e.g., GPC compiles them without > complaint). As far as I can determine, they conform to the semantics as > well, i.e., they obey all of the rules in the standard. The standard > requires certain semantics for, e.g., integer variables (scope rules > followed, arithmetic behaves as expected, etc.), and all of those rules > are > followed by the hardware as well. I do not see anything in the standard > that precludes the implementation of variables in hardware devices, rather > > than in RAM, as long as the semantics listed in the standard are obeyed. > > As I've noted, I would be pleased if someone could cite a section of the > standard that says that a Pascal program constructed as above is illegal. > > My "understanding" is that my program is legal, but with such a citation, > I > would withdraw that assertion. But I regret that simply saying that such > a > program seems to be illegal, or isn't normal, or ought to be prohibited, > just isn't good enough if the goal here is to make GPC conform strictly > with the ISO standards. > > And that's the only point I'm trying to make: whether you or Frank or I > believe that a given program is "pointless" isn't the issue. The only > issue is whether the standard prohibits it, and the standard itself is the > > only authority on that matter. Any discussion of what GPC must or must > not > do has to be supported by the standard. > > -- Dave

2 1

Typecasting
by ANURADHA Srinivasan 24 Oct '01

24 Oct '01

Hello , Is typecasting like MyType(Myvar); not allowed? How do i do something like the following? ------------------------------------- p:pointer; mytype=record ..... end; with mytype(p^) do begin ..... end; ----------------------------------------- Here i cannot use another temporary variable also. Thanks & Regards, Anuradha

3 3

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

24 Oct '01

As far as I know, this was simply an oversight, since it was Wirth himself that requested this to be changed, when the standard was being formulated. Also AFAIK, this particular problem was first highlighted by Lecarme and Desjardins, in their paper "More comments on the programming language Pascal", "Acta Informatica", 4, 231-243, 1975 (quoted by J. Welsh, W.J. Sneering, and C.A.R. Hoare, in their 1977 paper "Ambiguities and insecurities in Pascal", "Software Practice and Experience", reprinted in "Pascal - The Language and its Implementation", Barron, 1981). Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Tuesday, October 23, 2001 1:42 PM > To: gpc(a)gnu.de > Subject: Re: Errors and Standards (was: compiler bug) > > da Silva, Joe wrote: > > > Oops! I'm sorry, the example I gave wasn't quite right! :-( > > > > Below is a corrected example, which I hope is both correct (per > > J&W) and illustrates why this insecurity was changed when > > Pascal was standardized : > > > > program test; > > .... > > procedure fred (function smith : integer); > > var > > dummy : integer; > > begin {fred} > > dummy := smith('A') > > end; {fred} > > .... > > function one (x : boolean) : integer; > > .... > > function two (x, y : integer) : integer; > > .... > > begin {test} > > .... > > fred(one); > > .... > > fred(two); > > .... > > end. {test} > > > > As you can see, when the procedure "fred" is compiled, the > > compiler does not know how many parameters "smith" has, > > nor what type they are. This makes it difficult for the compiler > > to validate the program, and just imagine what will happen to > > the stack - yuck! <g> > > Oh dear, then it's really as bad as I'd feared. So I think we won't > introduce `--wirth-pascal' in GPC anytime soon. ;-) > > Does anyone know why this was so? Wirth must certainly have noticed > the problem. Was he just afraid of the nested parentheses in a > SP-like declaration with parameters? > > 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

1 0

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

23 Oct '01

Oops! I'm sorry, the example I gave wasn't quite right! :-( Below is a corrected example, which I hope is both correct (per J&W) and illustrates why this insecurity was changed when Pascal was standardized : program test; .... procedure fred (function smith : integer); var dummy : integer; begin {fred} dummy := smith('A') end; {fred} .... function one (x : boolean) : integer; .... function two (x, y : integer) : integer; .... begin {test} .... fred(one); .... fred(two); .... end. {test} As you can see, when the procedure "fred" is compiled, the compiler does not know how many parameters "smith" has, nor what type they are. This makes it difficult for the compiler to validate the program, and just imagine what will happen to the stack - yuck! <g> Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Monday, October 22, 2001 11:03 PM > To: gpc(a)gnu.de > Subject: Re: Errors and Standards (was: compiler bug) > > da Silva, Joe wrote: > > > 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. > > Do you mean the parameters given to the inner function (one, two) > are already specified when calling the outer one (fred)? In this > case, it's not much different than making smith type Integer, and > passing the function result to fred. (Sure, there could be a > difference in when and whether at all one/two are called, but unless > they have side-effects, the result will be the same.) > > 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

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

22 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

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