Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2007-09

Underscore prefix for external C functions

4 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Adriaan van Os

I am trying to find out whether or not to use an underscore prefix when declaring external C functions in FPC using 'external name xxx'. It looks like on Windows the underscore is not needed, whereas on Mac OS X the underscore is required, even when on both platforms 'nm' reveals that the to-be-linked-in C library has an underscore before the C function names.

Note that the Mac OS X Pascal (Carbon) Interfaces for fpc use the underscore, whereas the same Pascal Interfaces for gpc don't.

Is this just a mess or do I miss the true logic behind it ?

Regards,

Adriaan van Os

Reply by email

Jonas Maebe
to Adriaan van Os
Adriaan van Os wrote 11 lines
I am trying to find out whether or not to use an underscore prefix when declaring external C functions in FPC using 'external name xxx'. It looks like on Windows the underscore is not needed, whereas on Mac OS X the underscore is required, even when on both platforms 'nm' reveals that the to-be-linked-in C library has an underscore before the C function names. Note that the Mac OS X Pascal (Carbon) Interfaces for fpc use the underscore, whereas the same Pascal Interfaces for gpc don't. Is this just a mess or do I miss the true logic behind it ?

If you declare an external function/procedure as "cdecl", the compiler with /always/ add the necessary C-prefix (if any) to the external name.

The universal interfaces are declared as mwpascal rather than cdecl, and such functions/procedures do not automatically get the C-prefix (although one might argue that it would have been better if they did, and indeed if FPC on all platforms by default prefixed all its symbol names with the same prefix as the main C compiler(s), but the fact is that it doesn't do so today -- but maybe this could be changed now that there still aren't many FPC shared libraries in common use).

To make matters even more interesting (in the Chinese sense), there are also {$mode macpas} interface-only units (i.e., units without an implementation section, like many of the universal interfaces). Because this support was added solely for the purpose of supporting (older versions of) the universal interfaces, in that case any function without an explicitly specified external name also gets the C-prefix added (which does not apply to the universal interfaces units, since all functions/procedures there do have an explicitly specified external name).

Jonas

Reply by email

Adriaan van Os
to Jonas Maebe
Jonas Maebe wrote
> Is this just a mess or do I miss the true logic behind it ? If you declare an external function/procedure as "cdecl", the compiler with /always/ add the necessary C-prefix (if any) to the external name.

I see, so if I add

{$ifdef FPC}
{$calling cdecl}
{$endif

and skip the underscore, this results in multi-platform and gpc compatible 'external name xxx" directives.

Show quoted text 7 lines
The universal interfaces are declared as mwpascal rather than cdecl, and such functions/procedures do not automatically get the C-prefix (although one might argue that it would have been better if they did, and indeed if FPC on all platforms by default prefixed all its symbol names with the same prefix as the main C compiler(s), but the fact is that it doesn't do so today -- but maybe this could be changed now that there still aren't many FPC shared libraries in common use).

Yes.

Show quoted text 8 lines
To make matters even more interesting (in the Chinese sense), there are also {$mode macpas} interface-only units (i.e., units without an implementation section, like many of the universal interfaces). Because this support was added solely for the purpose of supporting (older versions of) the universal interfaces, in that case any function without an explicitly specified external name also gets the C-prefix added (which does not apply to the universal interfaces units, since all functions/procedures there do have an explicitly specified external name).

Are you saying that adding IMPLEMENTATION BEGIN changes the meaning of the INTERFACE section. That is hardly a defendable compiler feature, is it ?

Regards,

Adriaan van Os

Reply by email

Jonas Maebe
to Adriaan van Os
Adriaan van Os wrote 15 lines
Jonas Maebe wrote: >> Is this just a mess or do I miss the true logic behind it ? > If you declare an external function/procedure as "cdecl", the > compiler with /always/ add the necessary C-prefix (if any) to the > external name. I see, so if I add {$ifdef FPC} {$calling cdecl} {$endif and skip the underscore, this results in multi-platform and gpc compatible 'external name xxx" directives.

Yes (save for possibly const-related differences in parameter passing).

Show quoted text 13 lines
> To make matters even more interesting (in the Chinese sense), > there are also {$mode macpas} interface-only units (i.e., units > without an implementation section, like many of the universal > interfaces). Because this support was added solely for the purpose > of supporting (older versions of) the universal interfaces, in > that case any function without an explicitly specified external > name also gets the C-prefix added (which does not apply to the > universal interfaces units, since all functions/procedures there > do have an explicitly specified external name). Are you saying that adding IMPLEMENTATION BEGIN changes the meaning of the INTERFACE section. That is hardly a defendable compiler feature, is it ?

Interface-only unit support was (and still is) only a quick hack added for allowing to compile the universal interfaces. There was (and still is) no other way to specify both a non-cdecl/cppdecl calling convention and get automatic addition of C-prefixes. It does the job for which it was introduced, and was never intended for any other use than easy porting of legacy interfaces to external (C) libraries.

Jonas

Reply by email