Gpc November 2006

gpc@gnu.de

14 participants
15 discussions

Incorrect scoping of object/class field and method formal parameter identifiers
by Gale Paeper 08 Nov '06

08 Nov '06

While assisting in porting MacPascal Object Pascal code to GPC, I encountered a bug in GPC's scope rules implementation for object field and method formal parameter identifiers. The same bug also exists with the OOE objects implementation. The follow examples (one for mac-objects and one for ooe-objects) along with the respective GPC compilation error demonstrate the bug: {$ooe-objects} program ClassScopeBug(output); type Tclass = class x: integer; procedure y(x: real); { Should be legal} end; procedure Tclass.y(x: real); begin end; begin writeln('OK'); end. ClassScopeBug.pas:8: error: formal parameter `x' of method `y' conflicts with field or method {$mac-objects} program ObjectScopeBug(output); type Tobj = object x: integer; procedure y(x: real); { Should be legal} end; procedure Tobj.y(x: real); begin end; begin writeln('OK'); end. ObjectScopeBug.pas:8: error: formal parameter `x' of method `y' conflicts with field or method Both the MacPascal Object Pascal object and the Object-Oriented Extensions for Pascal class have the same 6.2.2 Scopes requirements extensions in this area. Although stated informally; implied through syntax extensions; and informal behavioral descriptions, the formal-parameter-list of a method heading is a separate scope region for which 6.2.2.5 scope exclusion requirements apply. The "Object-Oriented Extensions for Pascal" Technical Report in paragraph 6.5.4 "Implicit References" also states in part: "...Therefore, a parameter identifier or a local variable with the same spelling as a name brought in will hide the name brought in. A name so hidden can be accessed by explicit use of the class name and qualification." Therefore, there is no conflict between formal parameter `x' of method `y' and object/class field `x' since object/class field `x' is excluded from the scope of method `y' 's formal-parameter-list and method body. Since there is no violation of either object models' requirements, GPC should compile both of the example programs without any errors. The GPC I'm using is built from Adriaan's Mac OX X GPC sources distribution which I've upgraded to use Waldek's gpc-20060325 snapshot GPC sources. The specs are: Reading specs from /Developer/Pascal/gpc345u2d1/lib/gcc/powerpc-apple-darwin8/3.4.5/specs Configured with: ../gcc-3.4.5/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --build=powerpc-apple-darwin8 --prefix=/Developer/Pascal/gpc345u2d1 Thread model: posix gpc version 20060325, based on gcc-3.4.5 Gale Paeper gpaeper(a)empirenet.com

1 0

Re: Internal compiler error with non-matching method signatures
by Waldek Hebisch 08 Nov '06

08 Nov '06

Gale Paeper wrote: > Since the 20051116 workaround for the bug is to use the legal code > construct needed for a successful compile anyway, I don't have a presing > need for a 20051116 fix. Just reporting a bug to ensure it got fixed if > it hadn't already been taken care of in one of the later snapshots. > Thanks for the report. As I wrote it should be fixed in newer versions (unless the testcase hits two bugs and one is Mac specific). -- Waldek Hebisch hebisch(a)math.uni.wroc.pl

2 1

Bit setting operations
by Contestcen＠aol.com 07 Nov '06

07 Nov '06

And I'm curious wheteher there are bitsetting operations ... Thanks - Thurs, The Pascal Macro Compiler has a full set of bit operations. You compile first with the Macro Compiler, and then compile the generated Pascal code with whatever Pascal compiler you customarily use. The bit operations are described on the Master Software website at pasbit.htm with an example at pasbit2.htm Frank Rubin

1 0

Using gpc and the Dev-Pas IDE in cygwin
by Brian Keener 03 Nov '06

03 Nov '06

Well the subject sort of says it all. I wonder if this is possible. I tried the Dev-Cpp IDE for C++ in Cygwin and it appears that it works and is smart enought to deal with the Windows path and of the file name and compiler program and still act like it wasd running in a Unix environment but... If I try the same thing in Dev-Pas in Cygwin and gpc when I try to compile the tetris example it seems the it finds windres properly but the file name for input gets jumbled because of windows slashes vs unix slashes: Compile lo tab Building resource file... C:\cygwin\bin\windres -i C:\dev-pascal\examples\tetris\rsrc.rc -o c:\dev-pa~1\examples\tetris\rsrc.o Resource Tab gcc: C:dev-pascalexamplestetrisrsrc.rc: No such file or directory gcc: warning: `-x c' after last input file has no effect gcc: no input files /usr/bin/windres: no resources This is probably OT for this group but I thought maybe since the Chief is involved in both I might sneak through. Any suggestion on this will be greatly appreciated. bk

2 1

SDL and GNU Pascal
by Andreas K. Foerster 01 Nov '06

01 Nov '06

Hello sdl4fp-users, As some of you might remember, I wanted to use the SDL also with GNU Pascal in my project AKFQuiz. I tried to fiddle with the source code of SDL4Freepascal. But there was too much code to change just to find out how it works... So I decided to leave SDL4fp away and implement the few things I need from scratch. My project now is fully functional with GPC and SDL. It is not yet in the released version, but you can check out the CVS as described on the homepage (see link at the end of this mail). Now I want to share my findings with you, so probably you can use it for SDL4Freepascal... First of all, the types for variables are very different. SDL4fp uses "LongInt" for what is "int" in C - because LongInt happens to be 32Bit wide in FPC. But in GPC a LongInt is "at least" :-) 64bit wide! So it doesn't fit. Older versions of GPC intentionally kept the variable types compatible to their counterparts in C. Newer versions broke with that and introduced speacial types, like CInteger or CLongInt. Another difference to FPC is, that in GPC you have a more fine grained access to determine attributes, so you have really control about the size of variables. Here is the code snipplet for the types (from my "qsys.pas"): ----------------------------------------------------------------------- {$IfDef __GPC__} type Uint8 = Cardinal attribute (Size = 8); Uint16 = Cardinal attribute (Size = 16); Sint16 = Integer attribute (Size = 16); Uint32 = Cardinal attribute (Size = 32); Sint32 = Integer attribute (Size = 32); pByte = ^Uint8; {$if __GPC_RELEASE__ < 20041218} type CInteger = Integer; {$EndIf} { __GPC_RELEASE__ } {$Else} { not __GPC__ } type CInteger = LongInt; { @@@ for 32-Bit systems } CString = PChar; Uint8 = byte; Uint16 = word; Sint16 = SmallInt; Uint32 = cardinal; Sint32 = LongInt; pByte = ^Uint8; {$EndIf} { not __GPC__ } ----------------------------------------------------------------------- Note that you have to change "LongInt" to "CInteger" and "PChar" to "CString" in SDL4fp. SDL4fp links to the library by using the name 'SDL' after the "external" modifier. This doesn't work in GPC (yet). In GPC you have to use the compiler directive "{$L SDL}". In FPC there's also a possability to use it in a similar way with "{$LinkLib SDL}"... well it works, but not in every situation. So I decided to keep the name after the external clause, but with "IfDef"s around it. GPC compiles it without the IfDef, but there are lot of warning messages then. In FPC you must use the modifier "cdecl". In GPC that is the default, so you don't need it there. You can however declare it with "attribute(cdecl)", so you can simply write a macro to modify the "cdecl": "{$Define cdecl attribute(cdecl)}". C is case sensitive, while Pascal is not. So in GPC all Pascal identifiers are converted to lowercase at an early stage, this includes the procedure names. So you have a problem when your C identifiers need uppercase letters. This can only be solved by using an attribute which mentions the name again with its capitalisation: "name 'Example'". This name isn't converted to lower case, since it's a string-constant. FPC doesn't need that, but it doesn't harm there either. putting everything together it looks like in this example: procedure SDL_WM_SetCaption(title, icon: CString); cdecl; external {$IfDef FPC}'SDL'{$EndIf} name 'SDL_WM_SetCaption'; Well I still have a problem with CString parameters. FPC needs a type cast, while GPC doesn't accept a type cast here. I "solved" it again with "IfDef"s. Does anybody know a better solution? Please have a look at my source code for more information: http://cvs.sv.nongnu.org/viewcvs/akfquiz/srcbin/?root=akfquiz The relevant units are "sdlgrph.pas" and "sdlsnd.pas". The type definitions are in "qsys.pas". If you use my findings in SDL4fp, it would be nice, if you would mention me there as "AKFoerster". Related Links: GNU Pascal: http://www.gnu-pascal.de/ Free Pascal: http://www.freepascal.org/ SDL: http://www.libsdl.org/ SDL4Freepascal: http://sdl4fp.sourceforge.net/ AKFQuiz: http://akfquiz.nongnu.org/ -- AKFoerster

4 15

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 November 2006