Gpc October 2001

gpc@gnu.de

45 participants
80 discussions

Cygwin build...
by Preben Mikael Bohn 31 Oct '01

31 Oct '01

Hi all I have just tried to build gpc on a cygwin installation on my Windows machine. Usually I fire of the following commands on a Linux-box and it works like a charm. cd /home/prb/program/gpc tar xzf gpc-20010924.tar.gz tar xzf gcc-core-2.95.2.tar.gz cd gpc-20010924 mv p ../gcc-2.95.2/gcc/ cd .. mkdir gpc-build cd gpc-build /home/prb/program/gpc/gcc-2.95.2/configure --enable-languages=pascal --prefix=/home/prb/program/gpc/ make cd gcc make pascal.install However on my cygwin installation, the make command fails with an error: test x"no" != xyes || \ gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I/home/prb/program/gpc/gcc-2.95.2/libiberty /../include /home/prb/program/gpc/gcc-2.95.2/libiberty/strerror.c -o pic/strer ror.o gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I/home/prb/program/gpc/gcc-2.95.2/libiberty/. ./include /home/prb/program/gpc/gcc-2.95.2/libiberty/strerror.c /home/prb/program/gpc/gcc-2.95.2/libiberty/strerror.c:461: conflicting types for `sys_errlist' /usr/include/sys/errno.h:23: previous declaration of `sys_errlist' make[1]: *** [strerror.o] Error 1 make[1]: Leaving directory `/home/prb/program/gpc/gpc-build/libiberty' make: *** [all-libiberty] Error 2 Can anyone tell me what I'm doing wrong? 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.

2 3

Re: Typecasting
by Anuradha 30 Oct '01

30 Oct '01

Hello, Sorry for the wrong sample program and a silly doubt.The problem is we have large codes already written and we work in the support department that converts these sources to executables runnable on unix and i cannot change much of the code. This time i have analysed more and am attaching a code that works fine in BP and doesnot work in GPC.It is something to do with the pointers. Can you kindly tell me what the problem is? ---------------------------------- program typcast1; {type word=word(16);} type Mytype=record c:char; end; var p:pointer; begin getmem(p,sizeof(mytype)+2); word(p):=sizeof(mytype); p:=pchar(p)+2; mytype(p^).c:='h'; writeln(mytype(p^).c); end. ---------------------------------- thanks and regards, Anu Frank Heckenbach wrote: > Anuradha wrote: > > > It is not a typecasting error.It's probably fillchar question.I find the > > following sample program ending in a "segmentation fault -core dump" , i > > think because of doing a fillchar of a record which has a member that's > > a pointer . > > > > -------------------------------------- > > program a; > > type > > myrec=record > > x:^integer; > > end; > > var > > ptr :^myrec; > > > > begin > > getmem(ptr,sizeof(myrec)); > > fillchar(ptr^,sizeof(myrec),0); > > ptr^.x^:=5; > > write(ptr^.x^); > > end. > > -------------------------------- > > Well, sure it crashes. You set ptr^.x to nil (by filling it with > 0's), and then dereference it (ptr^.x^). Dereferencing nil pointers > is one the most obvious bugs one can make with pointers, and it > crashes on any Pascal compiler (except BP under Dos which will > instead overwrite the system IRQ tables ;-). > > Please don't take the following personal, but I'd really suggest > people not to use such low-level features (like GetMem, FillChar, > etc.) unless they really understand what they do. Pascal is a > high-level language and has plenty of "clean" features to use > instead -- e.g., a simple `New (ptr)' instead of the GetMem line, > and instead of the FillChar, either `ptr^.x := nil' or > `New (ptr^.x)' -- depending on what you really mean (the latter will > work correctly in the program above, the former will at least make > it quite clear why it crashes). > > Rant over. ;-) > > 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 -- S.Anuradha Generic Data Tools, Alcatel Chennai. Alcanet : 2-757-7123

2 1

Problems on Solaris 8 (secure)
by Serafim Dahl 30 Oct '01

30 Oct '01

The program below is implemented with the sole intention to show how to use procedures as parameters to procedures. However, it works when compiled with SUN Workshop Pascal but not when compiled with GNU Pascal. When trying to start it when compiled with GNU Pascal (version 20010623 on a Solaris 8, Ultra 5) I get the following error message: Oct 26 17:05:11 serafim.nada.kth.se genunix: NOTICE: test[4264] attempt to execute code on stack by uid 1167 Segmentation Fault Here is the program: -------- PROGRAM test(input,output); CONST low = 1; high = 10; TYPE index = low..high; natural = 0..Maxint; item = natural; intTable = ARRAY [index] OF item; VAR table : intTable; PROCEDURE doToEach(VAR t: intTable; PROCEDURE toDo(VAR i: item)); PROCEDURE iter(n: index); BEGIN toDo(t[n]); IF n < high THEN iter(Succ(n)) END; BEGIN iter(low) END; FUNCTION sum(VAR t: intTable): item; VAR tmpSum: item; PROCEDURE addItem(VAR i: item); BEGIN tmpSum := tmpSum + i END; BEGIN tmpSum := 0; doToEach(t, addItem); sum := tmpSum END; PROCEDURE readTable(VAR t: intTable); PROCEDURE readItem(VAR i: item); BEGIN Read(i) END; BEGIN doToEach(t, readItem) END; BEGIN Write('Enter ten numbers '); readTable(table); Writeln('The sum is ', sum(table):1); END. ------------- Now to my questions: 1. Is it the case that code actually executes on the stack? 2. If you say yes to 1., is it possible to compile GPC in a way that avoids this? The systems group at my job is not likely to back on security issues. The 'noexec_user_stack' flag is set on all computers in the network. I hope that it is possible as I am using GPC in a course and I don't like to go back to SUN Pascal, which I consider as inferior to GPC. Regards, Serafim Dahl Dept. of Comp.Sci. at The Royal Institute of Technology in Stcokholm.

2 1

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

26 Oct '01

Well, it's nice to see we are now in agreement in most areas. BTW, in case there is any remaining doubt, let me make it clear that I have never myself regarded a program without a parameter list as "pointless". I'm glad you liked those ISO-10206 citations, too. Even if you want to limit yourself to ISO-7185, the EP standard is still a useful guide to the interpretation of ISO-7185, since it builds directly upon this, but takes a broader view of the application of Pascal in the real world. You are correct that ISO-7185 only defines ONE mechanism by which program variables can be bound to external entities - via the program parameter list! Any other mechanism, which may be employed by a particular implementation, is a non-standard extension (well, by definition, all extensions are non-standard;-)! Joe. > -----Original Message----- > From: J. David Bryan [SMTP:dbryan@bcpl.net] > Sent: Thursday, October 25, 2001 2:01 AM > To: GNU Pascal List > Subject: Re: Errors and Standards (was: compiler bug) > > On 23 Oct 2001, at 11:44, da Silva, Joe wrote: > > > 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 ...". > > I understood what your understanding was. ;-) My assertion is that > understandings of the standard don't count, only statements from the > standard do. > > > > 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. > > I can't, because I believe that you have asserted a restriction that is > not > in the standard (but see my comment about "the standard" below). I can't > cite a passage from the standard that specifically allows linking of non- > program-parameter, main-block variables to external entities, because the > standard says nothing about such linking (allowed or disallowed). Can you > > cite a passage that disallows such use? > > > > BTW, you should note that we are in agreement that a program without a > > parameter list is perfectly legal. > > Duly noted! ;-) > > > > 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. > > The issue for me is not whether certain programs are or are not pointless. > > My contention is broader, specifically, that any such assertion must be > supported by the standard and not simply by "common sense." The Pascal > standards are written in horribly arcane language to ensure that they are > not open to such interpretations, i.e., that everything stated is > unambiguous. We shouldn't have to argue about whether a given program is > or is not legal (or pointless), because the standard should either > prohibit > it or not. > > Given the choice, I would much rather decide things on the basis of > opinions and common sense, as reading the standards always gives me a > severe headache. But I believe that we cannot do that, if GPC is to claim > > adherence to those standards. If there is disagreement over positions > that > GPC should take, then the choice of position must be the one that is > supported by citations from the standards. > > > > Now, specific to your situation, a very quick check of the ISO-10206 > > standard revealed the following... > > Ah, but the assertion regarding "pointlessness" (i.e., that a program > without program parameters could have no side effects) was made in the > context of ISO 7185. Frank allowed that ISO 10206 programs could have > side > effects without program parameters (and is supported by the passages you > cite). > > I concur completely with your citations in the context of ISO 10206. > > However, ISO 7185 mentions binding to external entities only with > reference > to program parameters (section 6.10). I contend that 6.10 applies only to > > main block variables that are also program parameters and therefore is not > > applicable to (and therefore does not restrict) other main block variables > > being bound by some other mechanism external to the language. > > -- Dave

3 4

Failed tests for GPC
by arvid.herzenberg 26 Oct '01

26 Oct '01

The GPC Test Suite in section 11.7 of the GNU Pascal Manual gives me 29 failed tests. This is 1.6% of the total of about 1800 tests; except for the 29 failures, the other tests all give 'OK'. I would like your opinion whether I should simply ignore the 29 failures. Or do you want me to e-mail the titles of the 29 failed test to you? My operating system is SUSE Linux 7.1 (Professional). The computer is a 450 Mc/s Windows machine. There are two hard discs: One is completely devoted to Linux, and the other handles all of Windows. There does not seem to be any interference between the two discs. In trying out GPC, I have so far completely failed to get an answer to the GPC demo-program 'pi.pas'. All pi.pas gives me is an error message to say that linking was not possible. I presume that the answer should have been 3.14159... I desperately need a decent Pascal compiler. and I still have not given up hope that GPC yet be successful. My name is Arvid Herzenberg. My e-mail address is arvid.herzenberg(a)yale.edu I am looking forward to a reply from you.

3 2

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

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