- Gpc - gnu.de

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