Gpc

Download

gpc@gnu.de

July 1997

22 participants
111 discussions

bugs, incompatibity, function attributes
by Jan-Jaap van der Heijden 01 Jul '97

01 Jul '97

Hello, First: this is a small change to lang-specs.h to correctly pass directives from "specs" to gpc-cpp. GPC skips half of them. --- lang-specs.h.orig Mon Jun 2 02:01:51 1997 +++ lang-specs.h Tue Jul 1 00:00:18 1997 @@ -32,7 +32,7 @@ %{C:%{!E:%eGNU Pascal does not support -C without using -E}}\ %{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\ -undef -D__GNUC__=%v1 -D__GPC__=%v1 -D__GNUC_MINOR__=%v2\ - %{!undef: %P}\ + %{!undef: %p %P} \ %c %{O*:%{!O0:-D__OPTIMIZE__}} %{traditional} %{ftraditional:-traditional}\ %{traditional-cpp:-traditional} %{trigraphs}\ %{g*} %{W*} %{w} %{pedantic*} %{H} %{d*} %C %{D*} %{U*} %{i*} %Z\ Then, I'm trying to get a somewhat borland-compatible syntax for external functions. GPC requires that the full declaration of a function is repeated, combined with the directive 'external': ----------------------------------------- unit Foo; interface function Bar(var i: integer): integer; implementation function Bar(var i: integer); integer; external; end. ----------------------------------------- Borland does it like this: ----------------------------------------- unit Foo; interface function Bar(var i: integer): integer; implementation function Bar; external; end. ----------------------------------------- ISO only mentions that "many processors provide, as an extension" 'external', but doesn't require it, let alone define the syntax to be used. Then, and this is a bug, GPC accepts this: ----------------------------------------- unit Foo; interface function Bar(var i: integer): integer; implementation function Bar(var i: integer); integer; external; attribute(stdcall); end. ----------------------------------------- The "attribute" part should be in the first declaration, not the second. The same error for other the "asmname" directive. Although it accepts the input, GPC doesn't do anything with the directives. (function attributes not surviving the GPI mechanism is a long-standing bug, but the "asmname" is silently ignored). To add to the confusion, this is how delphi declares a win32 API function imported from a DLL: ----------------------------------------- unit Foo; interface function Win32apiFunction(var i: integer): integer; stdcall; implementation function Win32apiFunction; external DLLfile name 'RealName'; end. ----------------------------------------- DLLfile is the name of the DLL (i.e. kernel32.dll), RealName need not be the same as Win32apiFunction: for 'MessageBox' the real name is 'MessageBoxA', to name one. A complete function declaration is not repeated, and while one attribute is in the declaration ('stdcall'), the other is in the implementation. GPC has no equivalent for the "DLLfile". But, if implemented, the automake mechanism could add an option "-lDLLfile" to the linker command line, something you have to do manually now. This is useful for all platforms, not just windows DLL's BTW. So: 1. Are there any reasons not to change the "external" declaration, at least for "borland" mode? 2. Any objections against allowing (working, that is) function attributes in the implementation part? Greetings, JanJaap --- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925.

1 0