Frank Heckenbach wrote:
I'm not yet changing the fact that `asmname' implies `external' for routines -- this should be done, too, but I'd rather do it together with other incompatible changes later.
However, unless there's heavy resistance, I'd like to deprecate the `c' and `c_language' directives, and drop them in a later release. So,
procedure Foo; c;
should be turned to:
procedure Foo; external name 'foo';
Well, I think it is good use to write preprocessor macros for different cases. So, if the compiler changes, it would be a matter of changing the macro.
What about a plain `external' without `name' or `asmname'? Currently, this keeps the "default" asmname (first letter uppercase, the rest lowercase). Some time in the future, we'll need name mangling (for qualified identifiers and overloading), so the default asmname will be something ugly which one should not have to know about in order to write interfacing C code or such.
Of course, it would be possible to make `external' set the first-uppercase-asmname even then, but I'm not sure how useful this is. (Currently, it's chosen as the default to avoid linker conflicts with "usual" C routines, but with name mangling, this won't be an issue.)
So, to me it seems more reasonable to make a plain `external' set the asmname to all-lowercase (just like `c' and `c_language' do now). Then,
May I suggest a compiler switch --fliteral-asmnames ? It would set the asmname to match the name in the procedure/function header literally. With this switch, in the interface part of a unit the declaration
procedure myProc;
would imply
procedure myProc; asmname 'myProc'; external;
The practical background is interfacing with the MacOS Carbon toolbox. In the current situtation, I have to add a GPC-conditional "asmname 'myCarbonProc"" to 15.000 API routines either by hand (not nice) or with a sed script (that maybe somebody has ready for me).
procedure Foo; c;
can be turned to simply:
procedure Foo; external;
But a current
procedure Foo; external;
will have to be turned to:
procedure Foo; external name 'Foo';
(or the corresponding C code turned to `foo' in lowercase, which I'd usually recommend -- since these routines are explicitly coded, you usually know that there are no conflicts with libc etc.).
Another question is whether `asmname' should be dropped entirely. In external declarations (the most common case), it can be turned into `external name' as described above. But there are cases where you need to set the asmname of a non-external routine or variable. But perhaps we can just use `name' then, e.g.:
var Foo: Integer; name 'bar';
(instead of asmname 'bar'). The advantage would be to have another non-standard (conditional) keyword less. Or we could even use `attribute', something like:
var Foo: Integer; attribute (name ('foo'));
(or `asmname' -- that doesn't matter since within `attributes' we don't have the problems of keywords, anyway). This way, `name' would not be a real keyword (only special after `external'), at the cost of a little stranges syntax.
But while we're at it, I think the attribute syntax can be simplified to
var Foo: Integer; attribute (name = 'foo');
(also for other attributes with parameters, and without changing the existing syntax -- there wouldn't be any conflicts).
I think this could be an acceptable way (syntactically), so `asmname' can be dropped.
Fine for me (but for the above reasons I would like to know what it will be in the next compiler release).
Regards,
Adriaan van Os