Gpc

gpc@gnu.de

5400 discussions

Re: Avoiding warning message
by Oldham, Adam 01 Nov '01

01 Nov '01

gpc -w should omit warnings liek that Adam -----Original Message----- From: Preben Mikael Bohn [mailto:preben_bohn@yahoo.com] Sent: Thursday, November 01, 2001 9:41 AM To: gpc(a)gnu.de Subject: Avoiding warning message Hi all.. Is there any way to avoid the warning message " warning: missing string capacity - assuming 255" (other than correcting the problem, that is :-))? 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.

1 0

not used or set
by toms＠ncifcrf.gov 01 Nov '01

01 Nov '01

Folks: I am compiling my programs with both GPC and Sun's compiler. A service that the Sun compiler provides is to check that a variable is actually used or set. For example, it will say: pc0: WorkShop Compilers 4.2 01/04/00 Pascal 4.2 patch 104632-11 Wed Oct 31 08:05:05 2001 numcode.p: In procedure checkcount: w 18260 variable f is neither used nor set This would be a very useful feature to have as it allows one to remove unused or leftover variables. In this case I was using a global (output) when I should have been using the locally defined file! Tom Dr. Thomas D. Schneider National Cancer Institute Laboratory of Experimental and Computational Biology Frederick, Maryland 21702-1201 toms(a)ncifcrf.gov permanent email: toms(a)alum.mit.edu http://www.lecb.ncifcrf.gov/~toms/

2 1

Probs building gpc on sparc/solaris
by Stephan Eickschen 01 Nov '01

01 Nov '01

Dear List, May be it's an OT but I couldn't find anything matching in the archives or at google. I downloaded gpc-20010924.tar.gz gcc-core-2.95.2.tar.gz unpacked them, followed the instructions in INSTALL (...) configure --enable-languages=pascal (...) executed a gmake and get: > cd /home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/doc/en/info && makeinfo -I .. -I ../.. -I ../../generated -o gpc.info gpc.texi > Making info file `gpc.info' from `gpc.texi'. > ../install.texi:143: Unknown command `smallformat'. > ../install.texi:145: Unmatched `@end'. > ../install.texi:155: Unknown command `smallformat'. > ../install.texi:158: Unmatched `@end'. > ../reference.texi:8587: itemize requires an argument: the formatter for @item. > ../reference.texi:8599: itemize requires an argument: the formatter for @item. > makeinfo: Removing output file `gpc.info' due to errors; use --force to preserve. > gmake[1]: *** [/home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/doc/en/info/gpc.info] Error 2 > gmake[1]: Leaving directory `/home/AIDA301/eicksch/gpc/build/gcc' > gmake: *** [all-gcc] Error 2 uname -a SunOS aida3 5.8 Generic sun4u sparc SUNW,Ultra-5_10 Any suggestion / help??? Best regards, Stephan -- ---------------------------------------------------------------------- Stephan Eickschen Tel. : +49 (0)8153 28-1351 GeoForschungsZentrum Potsdam (GFZ) Fax. : +49 (0)8153 28-1207 Division 1, Section 1.2 c/o email: eicksch(a)gfz-potsdam.de DLR Oberpfaffenhofen www : http://op.gfz-potsdam.de Box 1116 82234 Wessling Germany ----------------------------------------------------------------------

2 1

Re: Typecasting
by da Silva, Joe 31 Oct '01

31 Oct '01

I hope when you say "change p:=pchar(p)+2; to p:=pchar(p)+4;", you also change "getmem(p,sizeof(mytype)+2);" to "getmem(p,sizeof(mytype)+4);"! <g> I'm sure we all agree that this is very ugly, dangerous coding, but that's not the point. You are trying to "stretch the boundaries" of the compiler, to see how it behaves and to find out if there are any areas which may in practice cause problems with porting other code, right? Well, to be honest, I can't see what the problem is here, although it must have something to do with 32 bit alignment. As far as I can see, the two lines "fillchar(p^,sizeof(mytype)+2,0);" and "word(p^):=sizeof(mytype);" are irrelevant. All you are doing is allocating 2 extra bytes of memory than your record type ("Mytype") needs, then offsetting a pointer to this by 2 bytes, thereby forcing the compiler to address the record (and in particular, the pointer "c" within the record) on a 16 bit boundary. That's as far as I can analyse the situation, based simply on the source code presented. Since I don't know the "inner workings" of the compiler myself, perhaps someone else can comment further about this apparent alignment issue. Joe. > -----Original Message----- > From: Anuradha [SMTP:anuradha@adcc.alcatel.be] > Sent: Wednesday, October 31, 2001 10:19 AM > To: gpc > Subject: Re: Typecasting > > Hello, > > I am really sorry for having missed a ^ in the program but you see , > the > program really worked in BP and not in GPC.But i do know that it is > stupid to > manipulate some parts of the pointer.kindly delete the previous mail. > It is this program that i have problems in. > ----------------- > program typcast1; > const ct :char='h'; > type > Mytype=record > i : integer; > c:^char; > end; > var > p:pointer; > begin > getmem(p,sizeof(mytype)+2); > fillchar(p^,sizeof(mytype)+2,0); > word(p^):=sizeof(mytype); > p:=pchar(p)+2; > mytype(p^).c:=@ct; > writeln(mytype(p^).c^); > end. > ------------------------ > > But if i change p:=pchar(p)+2; to p:=pchar(p)+4; then it works.Is it > something to do with the word-boundaries? > > Thanks and regards, > Anuradha > > > Marco van de Voort wrote: > > > > What is the purpose of these two lines : ? > > > word(p):=sizeof(mytype); > > > > In real mode TP it sets the offset of the segment:offset pair to 1. > > > > Probably it originally was meant as a simple inc(p); > > > > The problem it expects that the offset part of a newly allocated block > is > > always zero, which is afaik not true. (real mode TP allocates per half > > segment). > > > > > p:=pchar(p)+2; > > > > inc(p,2); or p:=@p[2]; > > > > The overall effect therefore is inc(p,3); or p:=pchar(p)[3]; > > -- > S.Anuradha > Generic Data Tools, > Alcatel Chennai. > Alcanet : 2-757-7123

1 0

Re: Typecasting
by da Silva, Joe 31 Oct '01

31 Oct '01

What is the purpose of these two lines : ? word(p):=sizeof(mytype); p:=pchar(p)+2; Joe. > -----Original Message----- > From: Anuradha [SMTP:anuradha@adcc.alcatel.be] > Sent: Tuesday, October 30, 2001 8:54 AM > To: gpc > Subject: Re: Typecasting > > 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 > >

4 3

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

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