Gpc

gpc@gnu.de

5400 discussions

`IN' operator warning
by GPC on Ken Linder's Linux Box 05 Sep '99

05 Sep '99

I have the following simple program: program fooin; var s1, s2, s3 : integer; begin s1 := 1; s2 := 3; s3 := 5; if 10 in [s1, s2, s3] then writeln('OK') else writeln('not OK') end. The code itself executes ok but at compilation gives this warning: fooin.pas:8: warning: constructing limited integer set '0..255' Does this mean I can compare a single ordinal (LHS) to a set with a maximum number of elements of 255 (RHS) ? TNX Ken Linder http://kc7rad.lvcm.com/

2 1

Unsubscribe
by John Herbster 05 Sep '99

05 Sep '99

I wish that you were a NEWSGROUP instead of just a mailing list. I =would have read a lot more of the messages. John Herbster, Herbster Scientific, 12807 Park Royal, Houston, TX w077-2249, Phn:281-531-4423, herb-sci(a)swbell.net, Elders Unite Against =Ignorance and Stupidity

2 1

Help! Nothing runs
by John L. Ries 05 Sep '99

05 Sep '99

I installed the latest GPC beta (gpc-19990118) on a DEC3000/800 (Alpha) running Digital UNIX 4.0B and was able to compile and install without difficulty. However, anything I compile gives me the following error message when run: internal error: duplicate constructor No coredump or anything else is produced. I compiled on top of GCC 2.8.1. 128 MB of RAM is installed. I uninstalled the DEC Pascal runtime to insure no conflict. John L. Ries System Administrator Salford Systems Phone: (619) 543-8880 x25 Fax: (619) 543-8888 E-Mail: jries(a)salford-systems.com

2 2

GNU pascal installation problem
by Konstantin R.Beliaev 05 Sep '99

05 Sep '99

Hello! I'm trying to install the GNU pascal (version gpc-19990118 + gcc-2.8.1) on FreeBSD 2.2.8, but without success. The installation stops when I "make LANGUAGES=pascal" with message "`all' not remade because of errors". The latest command the script executes is "gcc -DIN_GCC -g -DHAVE_CONFIG_H obstack.o ` case "gcc" in "cc") echo "" ;; esac ` -o c++filt cxxmain.o underscore.o getopt.o getopt1.o" Please, HELP ! Reply to my e-mail: konst(a)RL7.bmstu.ru With hope, Konstantin

2 1

Re: gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Nick Burrett 05 Sep '99

05 Sep '99

Alexandre Oliva <oliva(a)dcc.unicamp.br> writes: > On Aug 31, 1999, Nick Burrett <nick(a)dsvr.net> wrote: > > > Alexandre Oliva <oliva(a)dcc.unicamp.br> writes: > > >> +++ gcc/p/rts/file.c Sun Aug 29 15:56:11 1999 > >> @@ -887,7 +887,7 @@ > >> _p_f_write (File, Buf, Size) > [snip] > >> - ssize_t result = > >> + size_t result = > [snip] > >> - if (result < 0) > >> + if (result == (size_t)-1) > > > You cannot do this. size_t may be unsigned. > > That's the reason why I'm explicitly casting -1 to that type. > > > Also fwrite returned zero on error > > That's not covered in the original code. Since I've never heard of > fwrite returning less than -1, I think it is as correct as the > original code. I'm suggesting that perhaps you stumbled across a proper bug. According to the man pages fwrite returns 0 on error and >0 on success. This is why I originally suggested that your fix may be not quite correct. We'll come up with a proper solution if you want. Cheers, Nick.

1 0

Re: option for file name input supression
by Tom Schneider 05 Sep '99

05 Sep '99

Peter: For folks on the mailing list, the issues I'm concerned with are: 1. Gpc asks for file names. I have some 200 pascal programs http://www.lecb.ncifcrf.gov/~toms/delila/delilaprograms.html and each uses as many as 10 file names. Typing all this is a waste of my time. No other compiler I've encountered (Sun, vax, CDC Cyber (!)) does this. So I'm suggesting that there be an option on gpc to simply use the file name given in the header line of the program. 2. When gpc asks for the file name, it capitalizes it. On Unix file names are case sensitive, so this is setting up for confusion and ambiguity. So I am suggesting that file names be left alone. No changing of case from what the user does. ... > > I can't do this because it would force my 200 programs to become compiler > > specific. No compiler I have encountered in the past 15 years ever forced me > > to do this. > > So all standard Pascal compilers use the same mechanism to > derive the external file name from the variable name? > Interesting. If so, GPC should do the same. Well, I don't know about ALL or how standard they are. I am currently working on Sun's rather stable complier (but hey, I found bugs in it too!! ;-). The CDC Cyber - an ancient beast running an OS called Kronos - had a really neat feature that I was sorry to see go when I went to Unix. One would type the program name followed by a series of file names: for program x(a,b,c,d,output); one could type x,1,,2,3 Kronos would: map 1 to a use file b for b map 2 to c map 3 to d That was rather handy and very quick to type. Such an option - in which if one didn't type anything at all one would get all file names to default - would be VERY handy. > How do they deal with inconsistent capitalization? Sun flags it as an unidentified symbol: program x(output); var a: integer; begin A := 5; end. 4 A := 5; E 18420---------^--- Undefined variable In program x: E 18240 A undefined on line 4 So it evidently just treats "a" and "A" as different symbols. program x(output); var a: integer; A: char; begin a := 5; A := '!'; end. I tried that and it compiled just fine. > > Is it really that difficult to have an option to just use the name as given > > in the header line? [...] > > The only problem is the capitalization issue; see below. > > > While it may be true that Pascal is supposed to be case-insensitive, it turns > > out that under Solaris it is case sensitive. This has already forced me to > > be *consistent* with the names I use, which is not unreasonable. > > Yes, I am also consistent with capitalization of my Pascal > sources, but the compiler must not depend on this. This is a matter of standards. It actually scares me that one can have that second program above and not realize the situation! However, I DO like the idea of being consistent throughout the program: either A or a, but not both. I do not like the idea of the program changing the capitalization that I set. > > It seems to me that you must have put a mechanism IN to capitalize the first > > letter. All I'm saying is that it would be best simply to remove that > > mechanism. It would be simpler, cleaner and never confusing. > > It would make user identifiers crash with libc functions while > linking. Oy. I had this problem when I first started working with Sun. It is irritating!!! In Pascal I used to have my main procedure named ... main of course. Well that is illegal because it conflicts with the underlying C compiler! (I renamed them 'themain', ugh.) What's really annoying is that I could easily have a variable named main inside the procedure, since its scope would be protected. *************************************************************** * SCOPE SOLUTION: * * Why can't the concept of symbol scope be applied to the * * entire program? Then there would be no conflict at all and * * Pascal names would be independent of the damn C complier * * names!!! * *************************************************************** On the Sun compiler, this code compiles just fine: program x(output); var a: integer; A: char; procedure x(z: char); procedure main(j: char); begin writeln(output,j); end; begin main(z); end; begin a := 5; A := '!'; x(A); end. Though the following compiles, it fails rather weirdly: program x(output); var a: integer; A: char; procedure main(z: char); procedure themain(j: char); begin writeln(output,j,' in themain'); end; begin writeln(output,z,' in main'); themain(z); end; begin a := 5; A := '?'; main(A); end. gives: ----- in main in themain ---- So using the word 'main' messes up the variable transfer. If I change the name to xmain, it works ok: ---- ? in main ? in themain ---- > What we could do is to keep the capitalization of the first > occurrence of each identifier for use with the option you are > suggesting. My initial suggestion was that if you are going to ask for file names, the string you should give should match the name in the pascal program header. *Anything* *else* is setting up for confusion on the part of the user! > It would also be a good thing for error messages and such. No, it would lead to confusion on operating systems like Unix which are case sensitive for file names. Just leave the names alone, don't modify them. > For public names however, we must use something that > does not overlap with the name space of the C library. See above scope suggestion. > Introducing this would be non-trivial. It would also be > possible (and much easier) to put the identifier into lower case > in order to derive the file name. If you make *ANY* changes in the name, you are setting it up to cause trouble at some point. I would think that ignoring the case would be simpler. > Since the discussion is now about suggested changes to GPC, > I think it's really time to move it to the GPC mailing list > <gpc(a)gnu.de>. Be welcome to forward or cite my mail there. Ok, here goes! Hmm. Thats funny. On http://agnes.dida.physik.uni-essen.de/~gnu-pascal/support.html#archives it gives gpc(a)hut.fi. as the mailing list name. Which is correct? (While we are at it, would you mind removing the periods at the ends of emails and urls on that page? They make it harder to cut and paste. Thanks.) > Thanks for your thoughts, You're welcome. > Peter > > -- > Peter Gerwinski, Essen, Germany, http://home.pages.de/~Peter.Gerwinski/ > Maintainer GNU Pascal - http://home.pages.de/~GNU-Pascal/ - gpc-19990118 > PGP key on request - 6C 94 45 BE 28 A4 96 - 0E CC E9 12 47 25 82 75 > *** Vote against SPAM! ********* http://www.politik-digital.de/spam/ *** 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/

1 0

Re: gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Alexandre Oliva 05 Sep '99

05 Sep '99

On Aug 31, 1999, Nick Burrett <nick(a)dsvr.net> wrote: >> That's not covered in the original code. Since I've never heard of >> fwrite returning less than -1, I think it is as correct as the >> original code. > I'm suggesting that perhaps you stumbled across a proper bug. According > to the man pages fwrite returns 0 on error and >0 on success. Indeed. So you (we, if you will :-) don't even need ssize_t, size_t and `== 0' will do. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){dcc.unicamp.br,guarana.{org,com}} aoliva(a){acm.org,computer.org} oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

1 0

GPC-19990813 AND DJGPP
by Andris Pavenis 05 Sep '99

05 Sep '99

Hi! Browsed source archive of GPC 19990813 alpha version. There is one problem with building binaries for DJGPP to be used with GCC-2.95.X: gpc-cccp.c doesn't still support 2 directory separators (DIR_SEPARATOR, DIR_SEPARATOR_2) and corresponding static function is_dir_separator() like in cccp.c in GCC-2.95. As result I'll not build GCC-2.95.1 together with GPC yet as I did it for egcs-1.1.2 in March (when releasing DJGPP port of egcs-1.1.2) Andris PS. Please answer me also directly as I'm not subscribed to GPC mailing list

2 1

Re: CStrings getting corrupted on return from Modules.
by Russ Whitaker 05 Sep '99

05 Sep '99

Hi Kevin Your program is doing exactly what you told it to do You defined a CString which begins byte1 = H, byte 2 = e, etc., disabled error detection with {$X+} and then called it a string: first 4 bytes is capacity, next 4 bytes current length, then the string bytes As far as I know the only time you'll need {$X+} is for a wrapper around function setlength() ( remember to also use {$X-} ) So take out the {$X+} and use functions CString2String and String2CString where you need them. Also noticed the function twine in the interface doesn't match function twine in the implementation. It didn't trigger an error message but I don't know if that's a bug or a extended pascal "extension". In the rewrite which follows couldn't return a CString so changed it to a string. Think this is a language restriction. ( However it could be me ) Type string25 appears twice becaue the implementation section din't see it in the interface section. I think that's a bug. Hope this helps Russ <russwhit(a)mind.net> {---------------------------------------------------------} Module FOO interface; Export FOO = (twine); type String25 = String(25); function twine( foobar: CString ): String25; end. {interface} Module FOO implementation; type String25 = String(25); function twine( foobar: CString ): String25; var local : string25 value 'oops'; begin writeln('In Module: ', CString2String( foobar)); writestr(local, CString2String( foobar), chr(0)); writeln('In Module(2): ', local); twine := local; end; {twine} end. {-----------------------------------------------------} program KFoss( input, output ); import foo; var foobaz : CString; begin foobaz := "Hello there."; writeln('Main Loop: ', CString2String( foobaz)); writeln('After Module: ', twine( foobaz )); end. ---------- > From: Kevin A. Foss <kfoss(a)mint.net> > To: gpc(a)hut.fi > Subject: CStrings getting corrupted on return from Modules. > Date: Sunday, August 29, 1999 9:36 AM > > Hi, > I'm having a problem where strings seem to get corrupted when > they are returned as a CString from a module. > > It is certainly possible that this is a problem on my end as I may be > illegally modifying strings in someway, as I am mixing EP string() > type variables and CStrings, as well as using {$x+} features. Is > there a good guide on how to use/convert the different string > types? I know this code used to work with older versions of gpc -- > trying to move my Pascal code from OS/2 to Linux (more on that in next > message) caused me to find this. > > Anyways here is a sample run of the code included below: > > Main Loop: Hello there. > In Module: Hello there. > In Module(2): Hello there. > After Module: x)@xY@ere. > > I replaced the high ASCII with an x to avoid mailer mangling. > > I'm using the latest version of gpc (compiled for gcc-2.95) available > as a Debian package. It claims to be 19990610, but someone said that > the latest snapshot misreports? -- so I think it is the latest version. > If I'm wrong, sorry. > > The code follows below: > foo.pas: > > Module FOO Interface; > > Export > FOO = (twine); > > function twine(foobar : CString): CString; > > end. { Interface } > > Module FOO Implementation; > > type > String25 = String(25); > function twine; > {$x+} > var > local : String25; > > begin > writeln('In Module: ', foobar); > writestr(local, foobar, chr(0)); > writeln('In Module(2): ', local); > twine := local; > end; { twine } > > end. { FOO } > > test.pas: > program test(input, output); > > import foo; > > var > foobaz : Cstring; > > begin > {$x+} > foobaz := "Hello there."; > writeln('Main Loop: ', foobaz); > writeln('After Module: ', twine(foobaz)); > end. > > Thanks, > -Kevin > -- > Kevin A. Foss ---- kfoss(a)mint.net >

3 3

gpc-19990813+gcc-2.95.1/alphaev56-dec-osf4.0d => failure
by Alexandre Oliva 05 Sep '99

05 Sep '99

I've been trying to build gcc 2.95.1 with gpc 19990813 on a couple of platforms. I had to apply the attached patch in order to get them to build xgpc and gpc1 in stage2, but this was useless on at least one platform (alphaev56-dec-osf4.0d), in which that gpc1 would print: ../../xgpc -B/n/gnu/gcc-2.95.1-gpc-19990813-libg++-2.8.1.3-libgcj-2.95.1/alphaev56-dec-osf4.0d/bin/ -B../../ -c -I. -Wall -Wpointer-arith -Wmissing-prototypes -Wmissing-declarations -O4 -DBSD_RTS=0 `if [ x@with_shared@ = xyes ] ; then echo -fPIC; fi` --unit-path=/usr/local/tmp/install-gnu-gcc-2.95.1-gpc-19990813-libg++-2.8.1.3-libgcj-2.95.1-bela-8709/libg++-2.8.1.3/gcc/p/rts --automake heap.pas error.pas: In function `Geterrormessage': error.pas:362: Internal compiler error in `copy_to_mode_reg', at explow.c:669 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/faq.html#bugreport> for instructions. gpc1: ../../xgpc exited with status 1 heap.pas:30: module/unit `error' could not be compiled It is worth noting that the directory pointed to by the first -B argument does not exist yet, so it is definitely using the just-built gpc1. If you need further informations, I'd be glad to provide, but make sure you Cc:me, since I'm not subscribed in this list. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il oliva(a){dcc.unicamp.br,guarana.{org,com}} aoliva(a){acm.org,computer.org} oliva(a){gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org} ** I may forward mail about projects to mailing lists; please use them

3 3

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