Gpc

gpc@gnu.de

5400 discussions

Non-local exit out of method
by Peter Schorn 10 Mar '06

10 Mar '06

Dear all, are there any plans to make non-local exits out of a method legal? This works in CodeWarrior Pascal and looks somehow better than a goto. The following program illustrates the issue: I could not find a way to make a non-local exit out of q using the exit statement. program exittest; { compile with gp --nonlocal-exit exittest.pas } type o = object procedure p; end; procedure o.p; procedure q; begin exit(p); { error: invalid argument `p' to `Exit' } exit(o.p); { error: syntax error before `.' } end; begin { o.p } end; begin { exittest } end. Best regards, Peter

5 11

Changing source code
by Prof A Olowofoyeku (The African Chief) 08 Mar '06

08 Mar '06

Hi This isn't strictly a GPC question, but it is related, so I'll ask anyway :| Is there an easy way to change a string in all source files to another string? For example, if I want to change all occurrences of "Type foo = Object (bar)" to "Type Tfoo = Class (Tbar)" in all ".pas" and ".pp" files in a directory tree, is there an easy way to do it, using standard GNU tools? I could of course write a program to do it, but I figured there could be an easier way. Thanks. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

5 6

Re: Changing source code
by Garth Fletcher 08 Mar '06

08 Mar '06

Prof A Olowofoyeku (The African Chief) wrote: > Hi > > This isn't strictly a GPC question, but it is related, so I'll ask > anyway :| > > Is there an easy way to change a string in all source files to another > string? > > For example, if I want to change all occurrences of "Type foo = Object > (bar)" to "Type Tfoo = Class (Tbar)" in all ".pas" and ".pp" files in a > directory tree, is there an easy way to do it, using standard GNU > tools? I could of course write a program to do it, but I figured there > could be an easier way. Thanks. > > Best regards, The Chief > -------- > Prof. Abimbola A. Olowofoyeku (The African Chief) > web: http://www.greatchief.plus.com/ > TextWrangler (the FREE little brother of BBEdit) can be downloaded from <http://www.barebones.com/support/textwrangler/updates.shtml> And it will do multi-file GREP based searches. -- Garth Fletcher

1 0

Re: potential buffer overflow in gpc lexer
by Waldek Hebisch 04 Mar '06

04 Mar '06

Martin Pitt wrote: > Frank Heckenbach [2006-03-02 18:37 +0100]: > > > not sure, if that's actually a problem resulting in the worst > > > scenario, > > > > It might if someone runs the compiler in a server-like scenario. > > (I doubt whether anyone does, and if so, there'd be other security > > questions to consider.) When using the compiler normally, to build > > and then run a program, it's probably less harmful, since "arbitrary > > code execution with crafted pascal source files" is really the > > purpose of a compiler. ;-) > > Not really. You do not want to execute arbitrary code by merely > *compiling* source code. Think of autobuilders of Linux distributions, > etc. Every nontrivial package contains a makefile or a build script, so it executes arbitrary code anyway. The only semi-realistic threat is when somebody sets a teaching site, where anybody can submit a program for syntax checking. > > > anyway regeneration with flex-2.5.33 does fix this bug. > > > > > > * SECURITY UPDATE: Fix arbitrary code execution with crafted > > > pascal source files. > > > * Rebuild gcc/p/pascal-lex.c with the current flex, which fixes a > > > buffer overflow in generated flex scanners. > > > * CVE-2006-0459 > > > > Do I see this right that the bug is in flex, not in GPC itself? > > To be exact, it was in the scanner generated by flex. > > > (I suppose > > https://launchpad.net/distros/ubuntu/+source/flex/+bug/30940 > > but I've always got a 500 on this page so far.) > > Right, it was marked as private so far, but now the bug is public. > > > Is the problem also present in flex-2.5.27? > > I didn't check, but it's highly probable. > Looking at the description I see that the problem is due to line: *YY_G(yy_state_ptr)++ = yy_current_state; similar line is present in flex scanners generated with older flex versions, but only if the scanner uses reject rules. AFAICS GPC scanner do not have this problem: `pascal-lex.c' do not contain `yy_state_ptr'. > > I've now built and tested GPC with flex-2.5.33 as well. No > > regressions apart from a few harmless prototype warnings. So I > > suggest we offically require 2.5.33 from now on. > ATM I see no need. -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 1

Reading source past end of block
by Pascal Viandier 04 Mar '06

04 Mar '06

I encountered an unexpected error with GPC when compiling a Pascal source that contains "some text" (not Pascal code) after the final "End." of the program. GPC tries to compile this extra text and finds syntax errors in it. Although I did not see any reference to this in ISO 10206, I think it could be a nice feature for GPC to ignore everything after the final "End." in a program or a unit since nothing useful for it should be there. I am using gpc 20050331 under Debian Linux X86 and gpc 20051116 on Sparc Solaris 2.6. Kind Regards Pascal Viandier

6 11

GPC with GCC 4?
by Silvio a Beccara 03 Mar '06

03 Mar '06

Dear friends, I haven't been following the list very closely lately, so I'd have a question: is there a version of GPC which is based on GCC 4? I'm asking because I've been told that GCC 4 is much faster than its predecessors, so there could be a significant gain in performances. Thank you, regards Silvio a Beccara Trieste - Italy -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: I migliori giochi Jamba! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=4844&d=3-3

2 2

Re: Expressions with subrange operands
by cbfalconer＠att.net 03 Mar '06

03 Mar '06

Ernst-Ludwig Bohnen <bohnen(a)mail.desy.de> wrote: > ... snip ... > > Simplifying your program I observe the same problem: > > PROGRAM testsubrange; > var > i: ShortInt; {signed 16 bit integer} > j: SizeType; {unsigned 32 bit word} > point : record x,y: real end; {takes 16 bytes} > begin > i:= 3658; > j:= 16; > writeln ('result1 = ', i*j); {58528, OK} > writeln ('result2 = ', i*SizeOf(point)); {-7008, wrong} > end. > > My suspicion is that for calculating the second expression > the compiler uses wrong operand size (16? bit) instead > of 32 (function SizeOf returns a value of SizeType). > BTW: -7008+2^16 = 58528 I believe you are simply caught in the silly C value preserving promotion. C does not preserve unsignedness during integer promotion. This is built into the C standard, and means you will be getting signed values in unexpected places. -- Chuck F (cbfalconer@yahoo.com)(cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!

2 1

Expressions with subrange operands
by Adriaan van Os 02 Mar '06

02 Mar '06

[G5:gpc/testgpc/adriaan] adriaan% cat testsubrange.p program testsubrange; type int16 = integer attribute( size = 16); int32 = integer attribute( size = 32); point = record x,y: real end; var i: int16; procedure P( size: int32); begin writeln( 'size = ', size) end; begin i:= 3658; P( i * SizeOf( point)); end. [G5:gpc/testgpc/adriaan] adriaan% gp testsubrange.p [G5:gpc/testgpc/adriaan] adriaan% ./testsubrange size = -7008 Any comments ? Regards, Adriaan van Os

5 16

Unit name same as exported procedure name not allowed
by lanceboyle＠qwest.net 01 Mar '06

01 Mar '06

I have a unit named Head which exports a single procedure also named Head. In the calling program, the compiler (20050331) generates an error, "statement used as expression." The docs don't seem to say anything about a name limitation. Have my previous two Pascals let me get away with something naughty? Of course, renaming either the unit or the procedure fixes the problem. Jerry

4 4

Re: Debugger problems OS X
by lanceboyle＠qwest.net 01 Mar '06

01 Mar '06

On Feb 27, 2006, at 10:48 PM, lanceboyle(a)qwest.net wrote: > my program doesn't call anything like readline Oops--sorry. It indeed does call a readline. However, that problem notwithstanding, the debugger continues to behave oddly. After the debugger loads, my program takes about 10 seconds before anything appears to happen with it. Then, stepping in/out/over is unreliable, with the "program counter" (the red arrow that indicates which line is about to be executed) pointing to the wrong line. Jerry

2 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