Gpc

gpc@gnu.de

5400 discussions

Bug: error in writeln output
by Ian Thurlbeck 01 Dec '01

01 Dec '01

Dear All I've found a simple case of a bug in writeln(): program sumbug(input,output); begin writeln(10.0*0.01); writeln(100.0*0.001); writeln(1.0*0.1); end. All should print 0.1 I guess, but I get: % ./bug :.000000000000000e-02 :.000000000000000e-02 1.000000000000000e-01 Interestingly ':' is the next character after '9' in the ASCII table, so it appears to be trying to print out the ASCII chacter for '10' (ten). 10.0e-02 is 0.1 after all ! This happens with the latest gpc-20011123 and also gpc-20010512 (that's all I've tested). Many thanks Ian -- Ian Thurlbeck http://www.stams.strath.ac.uk/ Statistics and Modelling Science, University of Strathclyde Livingstone Tower, 26 Richmond Street, Glasgow, UK, G1 1XH Tel: +44 (0)141 548 3667 Fax: +44 (0)141 552 2079

3 2

GPC/Solaris2.7 installation problem
by Mirsad Todorovac 30 Nov '01

30 Nov '01

Hi, all! On sparc-sun-solaris2.7, with gpc-20011123 / gcc-2.95.3 I've had the problem that patching failed (in line 447 of diff file). The problem proved to be the following: I've had /usr/bin{/patch} in path before /usr/local/bin{/patch} ; and it appears that Sun's original patch utility doesn't understand GPC's .diff format. I can't tell for sure, but it seems to me that this problem didn't occur with gpc-20010924 / gcc-2.95.2 ??? (Or I would remember it I guess). After linking /usr/local/bin/patch to ~/bin (which *was* in path before /usr/bin) everything went fine - but for a moment I was really confused. Mirsad -- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.

2 1

Re: dostest crash with djgpp
by Maurice Lombardi 30 Nov '01

30 Nov '01

Frank Heckenbach wrote: >>After that there is no more error, and I have uploaded the resulting bin to agnes. >> > > I just discovered a pretty stupid bug I made recently. Though the > fix will be uploaded soon via Peter as usual, I'm sending it to you > already because you might want to rebuild the binary before too many > people get it. > > Frank Done. It is uploaded to agnes as gpc-20011130-gcc-2953.i586-pc-msdosdjgpp.zip and available as usual under the link ftp://agnes.dida.physik.uni-essen.de/home/maurice/gpc2953b.zip Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

1 0

test results
by Russell Whitaker 30 Nov '01

30 Nov '01

Hi After editing diff file ( thanks, Maurice ), Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.3/specs gpc version 20011123, based on 2.95.3 20010315 (release) test results: # of GPC tests 2159 # of GPC tests passed 2158 # of GPC tests skipped 1 # of GPC tests failed 0 Russ

1 0

dostest crash with djgpp
by Maurice Lombardi 30 Nov '01

30 Nov '01

Hi all, I have compiled the last alpha (20011123) under DJGPP When running the test suite there is a weird crash in readb10.pas and friends (endless loop of SIGSEGV), due to a too small default stack size. The following diff to increase the stack solves the problem: --- read1.inc.orig Mon Nov 26 16:07:20 2001 +++ read1.inc Thu Nov 29 20:07:10 2001 @@ -1,5 +1,9 @@ uses gpc; +{$ifdef DJGPP} +const MinStackSize: Cardinal = $200000; asmname '_stklen'; {2 MB} +{$endif} + var dialect:string(100)='Unspecified dialect'; rangecheck :Boolean=(*@@not implemented yet True*)False; After that there is no more error, and I have uploaded the resulting bin to agnes. Maurice -- Maurice Lombardi Laboratoire de Spectrometrie Physique, Universite Joseph Fourier de Grenoble, BP87 38402 Saint Martin d'Heres Cedex FRANCE Tel: 33 (0)4 76 51 47 51 Fax: 33 (0)4 76 63 54 95 mailto:Maurice.Lombardi@ujf-grenoble.fr

2 1

Re: investigating a core dump...
by da Silva, Joe 29 Nov '01

29 Nov '01

I have a vague recollection (from previous discussions on the list) that this sort of problem only occurred if debugging was enabled, or am I thinking of some other problem? Joe. > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, November 29, 2001 4:20 AM > To: gpc(a)gnu.de > Subject: Re: investigating a core dump... > > Stephan Eickschen wrote: > > > > This might be a case of a known GPC problem that causes a stack > > > overflow if the loop runs very often. If it's that, than the crash > > > should occur sooner or later depending on the stack limit set. > > > > > > A work-around in this case could be to assign the loop condition > > > (substr(zeile2,1,ls)=suchstr) to a Boolean variable and test this in > > > the `until'. > > Thanks a lot! The program seems to work now... > > Fine. The GPC bug might be fixed in the not too distant future, but > I don't want to promise too much. > > 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

3 2

Re: GRX 2.4.4 pre-release
by da Silva, Joe 29 Nov '01

29 Nov '01

Yep! (Hey, it's all part of the Wirth family, right?;-) Joe. > -----Original Message----- > From: marcov(a)stack.nl [SMTP:marcov@stack.nl] > Sent: Thursday, November 29, 2001 10:16 AM > To: gpc(a)gnu.de > Subject: Re: GRX 2.4.4 pre-release > > > "Pointers: the GOTO of data structures" --- P.J. Moylan. > > Isn't Peter a Modula-2'er :-)

1 0

Re: GRX 2.4.4 pre-release
by da Silva, Joe 29 Nov '01

29 Nov '01

"Pointers: the GOTO of data structures" --- P.J. Moylan. Joe. ;-) > -----Original Message----- > From: Frank Heckenbach [SMTP:frank@g-n-u.de] > Sent: Thursday, November 29, 2001 2:13 AM > To: gpc(a)gnu.de; grx(a)gnu.de > Subject: Re: GRX 2.4.4 pre-release > > Maurice Lombardi wrote: > > > Mariano Alvarez Fernandez wrote: > > > > > GrSaveContextToJpeg is a new function, the old SaveContextToJpeg lived > in the addon subdir, and I > > > didn't know if we can change it, so I had write a new one and his > pair: GrLoadContextToJpeg. Can > > Shouldn't this be `From' rather than `To'? > > > > you add it to grx.pas? > > > > OK. > > To check I have also written a demo program which is the exact > translation to pascal of > > jpgtest.c > > In doing this I have noticed a problem in the translation of passing > GrContext parameters > > to procedures/functions. In C they are passed as pointers. In Pascal the > best solution is > > usually to pass them as "var" parametrers, and this had been done > previously. > > However there is a trick in grx that when passing a NULL pointer instead > of a > > GrContext pointer, an internal GrContext is created and/or used. This > trick is > > very frequently used for the current context, and is done several times > in the > > demo program. But I know no way in Pascal to pass a nil pointer as a var > parameter. > > Null. :-) (This was introduced for exactly this purpose.) > > > So either one discards this possibility or pass the parameters as > pointers > > GrContextPtr like in C. This is not a natural way of doing in pascal but > it works. > > So we can do it with var parameters. However, I'm wondering if we > should do it. I'm not very familiar with using contexts in GRX, but > if the usual way to create them is via functions like > GrCreateContext that return pointers, then there is no disadvantage > in using pointers (in fact, it saves a `^'). But if there a > regularly situations where you have a real GrContext variable, then > it's better to use var parameters than have to use `@'. > > 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: gpc-test-suite+rhide problems
by Per Persson 28 Nov '01

28 Nov '01

Frank Heckenbach wrote: >All RHIDE can really do is call GPC with different options (or >*perhaps* environment variables, but I don't think so). Try to see >which options it uses (don't know if/how this is possible from >within RHIDE -- if nothing else helps, you could temporarily install >in place of gpc a little script that just dumps its options). OK the problem was the option -ggdb Now it works (though rhide crashes sometimes). Thanks Per _________________________________________________________________ HÃ¤mta MSN Explorer kostnadsfritt pÃ¥ http://explorer.msn.se

1 0

investigating a core dump...
by Stephan Eickschen 28 Nov '01

28 Nov '01

Hi all, I am a little bit in trouble with gpc on solaris >gpc -v Reading specs from /home/GFZS1/gnu/gpc/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/specs gpc version 20010924, based on 2.95.2 19991024 (release) >uname -a SunOS aida3 5.8 Generic sun4u sparc SUNW,Ultra-5_10 The program is compiled and linked without any problems. >gpc -g -o antdb3 antdb3.pas But running it yields to core dumps... I tried to investigate on it with ddd but unfortunatly, I get stucked right after the starting shot. I have to mention, that I did not write the program on my own - and I am not a pascal hacker. I used to code in pascal some years ago, but "switched" to C. Maybe some of the wizards out there is able to help me to find the "malicious" code? As far as I know, the program was original written for BorlandPascal and then transferred to AIX using "extended syntax" (?). I tested it at home on ly linux box with gpc and everything works fine. So I installed gpc on our sun's but now I am in trouble... ############################### DDD 3.0 (sparc-sun-solaris2.5.1), by Dorothea Luetkehaus and Andreas Zeller. Copyright (c) 1998 Technische Universitaet Braunschweig, Germany. (gdb) file /home/AIDA102/eicksch/bin/antdb3 Reading symbols from /home/AIDA102/eicksch/bin/antdb3...done. (gdb) set args (gdb) run Starting program: /home/AIDA102/eicksch/bin/antdb3 warning: Unable to find dynamic linker breakpoint function. warning: GDB will be unable to debug shared library initializers warning: and track explicitly loaded dynamic code. Program received signal SIGSEGV, Segmentation fault. 0x52bb8 in Kludgestreq (S1=0xff3f00c8, L1=10, S2=0xa49b8, L2=10) at /home/AIDA301/eicksch/gpc/gcc-2.95.2/gcc/p/rts/string.pas:813 (gdb) ---- snip: string.pas ------------------------------------- 807 function KludgeStrEQ (s1: PCharsKludge; l1: Integer; s2: PCharsKludge; l2: Integer): Boolean; asmname '_p_eq'; 808 function KludgeStrEQ (s1: PCharsKludge; l1: Integer; s2: PCharsKludge; l2: Integer): Boolean; 809 var c1, c2: Char; 810 begin 811 { @@ kluuuuuudge } if l1 < 0 then begin l1 := 1; c1 := Chr (PtrInt (s1)); s1 := PCharsKludge (@c1) end; 812 if l2 < 0 then begin l2 := 1; c2 := Chr (PtrInt (s2)); s2 := PCharsKludge (@c2) end; 813 KludgeStrEQ := StrEQ (s1^[1 .. l1], s2^[1 .. l2]) 814 end; ---- snap ------------------------------------------------ Any suggestion highly appreciated, 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 ----------------------------------------------------------------------

3 9

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