Gpc

gpc@gnu.de

5400 discussions

Re: prior parameter's size depends on `foo'
by david＠tcs01.demon.co.uk 11 May '99

11 May '99

In message <19990511213235.C1105(a)esmeralda.gerwinski.de> Peter Gerwinski writes: > > You probably stumbled about a bug in GPC. > > To help us to fix GPC it would be best if you reduced the > problem to a program `david1.pas' which > > * is as short as possible, > > * reproduces the bug, > > * and is intended to writeln 'OK' if no bug > occured and something else otherwise. The problem is at compile-time, attached is a small module which exhibits this behaviour. My system is Red Hat Linux release 5.2 (Apollo) running kernel 2.0.36 on an i586. I've built gcc-2.8.1 and gpc 19990118. gpc -v gives the following output ----------------------------------------------------------------- Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 ----------------------------------------------------------------- Compiling the following module with gpc -c dajmod.p gives the output shown below file dajmod.p: ----------------------------------------------------------------- module dajmod1 interface; export dajmod = (str_tail); procedure str_tail(protected source:string;protected i:integer;var dest:string); end. module dajmod1 implementation; uses gpc; var s1,s2:string(255); i:integer; procedure str_tail; var s2:string(255); begin (*str_tail*) if (length(source)=0) or (i<1) or (i>length(source)) then dest:='' else begin moveleft(source[length(source)-i+1], s2[1], i); (*$x+*) setlength(s2,i); (*$x-*) dest:=s2; end; end; (*str_tail*) end. ----------------------------------------------------------------- Output from compiler: dajmod.p: In function `Str_tail': dajmod.p:9: prior parameter's size depends on `Source' ----------------------------------------------------------------- There may well already be a provided routine to do this (return the last i characters of a string), and if there is, I'd be grateful for a pointer to it, but even so I think I'd still like to be able to write similar procedures/functions. -- David James mailto:david@tcs01.demon.co.uk

2 1

Re: Fw: gcc-19990330
by Frank Heckenbach 11 May '99

11 May '99

J. David Bryan wrote: > > > > p.s. think "Trim" should trim both spaces and tab chrs > > > > ( now only spaces) low priority wish list > > > > What does the standard say about this? (`Trim' is a predefined > > function of the standard, so we have to care about the standard > > here.) > > Section 6.7.6.7 (String functions) in ISO 10206 (Extended Pascal) says for > "Trim": > > ...the function shall yield the value of substr(sv,1,p-1), where p is > the least value in the closed interval 1..n such that each component of > sv[p..n] is the char-type value space. > > So "Trim" only trims spaces. > > > > Alternatively (if the standard wants only spaces), we could also make a > > different routine for spaces and tabs... > > A different function would be the proper implementation. I just noticed that the (non-standard) GPC procedures TrimLeft/TrimRight/TrimBoth and the equivalent functions TrimLeftStr/TrimRightStr/TrimBothStr do trim both spaces and tabs. So I suppose they can be used here. Or are there any votes for making them trim only spaces like Trim does? BTW, the same effect (trim all leading "space characters" (spaces and tabs)) could also be realized by: uses GPC; const NoSpaceCharacters = [Low (Char) .. High (Char)] - SpaceCharacters; ... foo := Copy (s, CharPos (NoSpaceCharacters, s)) Frank -- Frank Heckenbach, frank(a)fjf.gnu.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: bash
by Frank Heckenbach 11 May '99

11 May '99

Russ Whitaker wrote: > hi frank > > i'm not a bash expert either: it took me 2 hours to come up with the > following > > enter the following 6 lines of code in a file called test > > #!/bin/sh > if [ $1 = $2 ]; then > echo "ok" > else > echo "oops" > fi > > next, chmod 777 test > then try it: > ./test 1 1 > and > ./test 1 2 > > now go back and change the = to == and try it and you get > > ./test: [: ==: binary operator expected > oops With my bash, it always reacts correctly, regardless whether I call it as `bash' or `sh'. > note: bash is from slakware 3.5 Which version is this (try `bash --version')? Not that it's really important for GPC, but I always like to find out the reasons for problems. Frank -- Frank Heckenbach, frank(a)fjf.gnu.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: bash
by Russ Whitaker 11 May '99

11 May '99

hi ls -l /bin/sh gives lrwxrwxrwx ... /bin/sh ->bash bash -version give GNU bash, version 1.14.7(1) guess it's about time for me to update thanks Russ ---------- > From: Nick Burrett <nick.burrett(a)btinternet.com> > To: gpc(a)gnu.de > Subject: Re: bash > Date: Tuesday, May 11, 1999 4:19 AM > > > I tried this with bash 2.02 and there is no problem since = and == are > interpreted the same in this case. > > Are you sure you are executing the script with `bash' and not `sh' ? > The first line would seem to suggest `sh' which may be the cause of > the problem. > > Nick.

1 0

prior parameter's size depends on `foo'
by david＠tcs01.demon.co.uk 11 May '99

11 May '99

I'm seeing the error message "prior parameter's size depends on `foo'" whilst trying to compile an extended pascal module. I'm finding it difficult to strip this down to a really small example which shows the behaviour, but it is associated with a var parameter which is typed as string. Before I spend a lot more time trying to make a very small example of this - anyone have any suggestions as to what I might be doing wrong? -- David James mailto:david@tcs01.demon.co.uk

2 1

Enhancing gdb for GNU Pascal
by Tranter, Jeff 11 May '99

11 May '99

We're looking at using GNU Pascal to replace a proprietary Pascal compiler developed internally. One of the issues with the users is debugging. They would like good source-level debugging capability. GDB seems to work quite well with GNU Pascal but it could be enhanced. I propose to make some changes to it to better support Pascal debugging: - a real Pascal mode, which would be associated with Pascal source file extensions so the debugger would automatically do into Pascal mode when debugging .pas or .p files - evaluation of Pascal expressions (initially I would just copy the modula-2 mode expression parser). The main features here are proper array subscripting and pointer expressions. I plan to add support for sets. - look at making matching of identifiers case-insensitive, so for example, the user could set a breakpoint on a routine called "FOO", "foo", or "Foo" and have it match with what the compiler generated symbol was. - look at allowing the user to set a breakpoint on a program's begin...end block, i.e. have the debugger know that program "FOO" starts at label "program_Foo". Similarly, handle the pseduo-variable used for function return values from the debugger expression evaluator. Currently the user needs to know that for function "FOO" the return value variable is called "retval_Foo". Would these changes be worthwhile? Is anyone already working on them? Are there any other debugging features that would be useful?

2 1

Two GNU Pascal ideas
by Tranter, Jeff 11 May '99

11 May '99

Two thoughts on GNU Pascal to discuss: Based on previous experiences with another Pascal system, one of the most useful features was run-time checking (array bounds, sub-ranges, enumerated types, etc.). This often found problems in code without much effort. It could also be selectively be turned off for efficiency. With GNU Pascal we have C-style run-time checking (i.e. essentially no run-time error checking unless a wild pointer causes some type of exeception). I'm wondering: 1. Would people find this a useful feature for GNU Pascal? 2. Would it be feasible to implement it in the compiler? -------------------------------------- GNU Pascal converts the case-insensitive Pascal identifiers to symbols that are lower-case with the first letter capitalized. This has two implications: - in gdb you need to use the capitalized identifier which is not intuitive to users - you cannot call C routines that do not match the capitalized naming scheme. The first issue can presumably be fixed in the debugger, but the second is more of a problem because I'd like to be able to call C code directly. I can see several approaches to solve this: 1 Make Pascal case sensitive (probably not an option since it would presumably not match the language spec) 2. Convert Pascal symnbols to all lowercase. You could then call C routines if they were all lowercase (which is the most common). 3. Have some extension to indicate C linkage (like C++ and some C compilers do). Maybe an extension or alternative to the EXTERNAL keyword. Note, a side effect of capitalizing all identifiers in the lexical analyzer is that currently the compiler may report an error such as foo.pas:1: parse error before `Error' when the source code actually used the string 'ERROR'.

2 1

Re: bash
by Nick Burrett 11 May '99

11 May '99

"Russ Whitaker" <russwhit(a)mind.net> writes: > hi frank > > i'm not a bash expert either: it took me 2 hours to come up with the > following > > enter the following 6 lines of code in a file called test > > #!/bin/sh > if [ $1 = $2 ]; then > echo "ok" > else > echo "oops" > fi > > next, chmod 777 test > then try it: > ./test 1 1 > and > ./test 1 2 > > now go back and change the = to == and try it and you get > > ./test: [: ==: binary operator expected > oops I tried this with bash 2.02 and there is no problem since = and == are interpreted the same in this case. Are you sure you are executing the script with `bash' and not `sh' ? The first line would seem to suggest `sh' which may be the cause of the problem. Nick.

1 0

bash
by Russ Whitaker 11 May '99

11 May '99

hi frank i'm not a bash expert either: it took me 2 hours to come up with the following enter the following 6 lines of code in a file called test #!/bin/sh if [ $1 = $2 ]; then echo "ok" else echo "oops" fi next, chmod 777 test then try it: ./test 1 1 and ./test 1 2 now go back and change the = to == and try it and you get ./test: [: ==: binary operator expected oops note: bash is from slakware 3.5 thanks russ

1 0

Re: Fw: gcc-19990330
by Frank Heckenbach 10 May '99

10 May '99

Once upon a time ago, Russ Whitaker wrote: > > near the end of make LANGUAGES=pascal there is a number of "if" > > statemnets followed by the message > > > > /bin/sh: [: ==: binary operator expected Unless this has already been solved, can you give more information where this accurs (perhaps a log of the make run)? > > p.s. think "Trim" should trim both spaces and tab chrs > > ( now only spaces) low priority wish list What does the standard say about this? (`Trim' is a predefined function of the standard, so we have to care about the standard here.) Technically, of course, it would be easy to do it. Alternatively (if the standard wants only spaces), we could also make a different routine for spaces and tabs... Frank -- Frank Heckenbach, frank(a)fjf.gnu.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

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