Optional name mangling

Stuart stugol at gmx.com
Mon Jul 23 06:02:53 PDT 2012


On Monday, 23 July 2012 at 06:44:22 UTC, Walter Bright wrote:
> On 7/22/2012 6:12 AM, Stuart wrote:
>> Okay, but if you had a keyword - say, "extern(rawC)" - that 
>> did no mangling
>> whatsoever, then I could run implib without manually editing 
>> every single damn
>> line in every Microsoft .def file by hand!!! Surely that's a 
>> good idea?
>
> I agree, it's a pain, and a pointless one at that.
>
>> I don't know why implib is ignoring the /s switch, but it is. 
>> My .lib file
>> doesn't have underscores, and there doesn't seem to be much I 
>> can do about it.
>> Do I need a different version of implib or something? 
>> Shouldn't the /s switch
>> add underscores to everything?
>
> There's no magical way for implib to figure out what the nn in 
> @nn must be.

Granted, but IMPLIB IS NOT PREFIXING THE NAMES WITH AN 
UNDERSCORE, even when used with the /s switch. Hello? Houston? Am 
I getting through?

In any case, adding support for importing unmangled function 
names in D would help in these cases; and also allow us to import 
unmangled functions that were exported from C using the "extern 
C" instruction in C++.

Correct me if I'm wrong, but isn't it only C++ that does 
mangling? As I recall, straight C doesn't support overloading and 
doesn't mangle names. Therefore, I reckon your "extern (C)" 
instruction ought instead to be written "extern (C++)", and a new 
"extern (C)" should be introduced that does no name mangling. 
Alternatively, I may be wrong, but even so, a non-mangling 
keyword would be helpful. And surely it wouldn't be difficult to 
implement?


More information about the Digitalmars-d mailing list