#828 32bit Integer/Long mangling reversed

[dkl]

fbc 32bit still mangles Integer=int and Long=long, which is the opposite of 64bit (Integer=long|INTEGER and Long=int) and the C/C++ binding recommendations.

This means that the same FB and C++ code will only work together on either 32bit or 64bit, but not both.

'' currently works on 32bit only
extern "C++"
    declare sub f(byval i as integer)
end extern
...
void f(int i) {
}

'' currently works on 64bit only
extern "C++"
    declare sub f(byval i as long)
end extern
...
void f(int i) {
}

This affects the namespace/cpp test case in the FB test suite.

[dkl]

It would be good to fix this for C++ compatibility, but unfortunately that would break every existing precompiled FB library that uses Integers and mangling...

[Jeff Marshall]

I had a note somewhere about mangling in extern blocks, but can't find where I put it. It is somewhat related to this issue; even though fbc might be able to resolve [u]long, [u]integer, [u]longint overloads, fbc should respect the capabilities of the extern's linker namespace.

[dkl]

There is a possible fix here that improves compatibility with C++, but as mentioned, it breaks compatibility with previous FB versions, so I'm not sure it's a good idea.

[Jeff Marshall]

I think the change is acceptable is worth the trouble of breaking compatibility. Goal is to write code in FB and code in C++ that is compatible at the binary (linker) level, and this change moves us closer to that goal. We don't have to change FB mangling, but in this case it makes sense to align it with the recommendations.

Here's my notes, about the mangling, that helped me understand, and other problems.

FB

• 5 basic integer types (plus 5 corresponding unsigned types)
• sizeof(byte)<=sizeof(short)<=sizeof(long)<=sizeof(integer)<=sizeof(longint)
• 32-bit: 1 <= 2 <= 4 <= 4 <= 8
• 64-bit: 1 <= 2 <= 4 <= 8 <= 8,
• size of INTEGER varies by platform
• for FB mangling, we can do whatever; we only have to be compatible with ourselves, so the change is acceptable

C++

• 5 basic integer types (plus 5 corresponding unsigned types)
• sizeof(signed char)<=sizeof(short)<=sizeof(int)<=sizeof(long)<=sizeof(long long)
• sizes will vary by compiler and platform

FB versus C++

• C++ int/long is like FB LONG/INTEGER ... sometimes
• better to think of it as simply different and not get confused by naming
• only when we try to match up FB and C++ that it makes sense

Itanium C++ ABI (http://itanium-cxx-abi.github.io/cxx-abi/abi.html)
Builtin types single-letter codes:
a := signed char
h := unsigned char
s := short
t := unsigned short
i := int
j := unsigned int
l := long
m := unsigned long
x := long long, __int64
y := unsigned long long, __int64

With this change, match up FB to C++ ABI, depends on platform and other compiler (gcc)
Shown in next list is 1) platform, 2) C++ sizes of unsigned char, short, int, long, long long,
3) name mangling suffix for a comparible type in FB

Some popular targets:
linux 32-bit: 1 <= 2 <= 4 <= 4 <= 8, asilx
linux 64-bit: 1 <= 2 <= 4 <= 8 <= 8, asilx
windows 32-bit: 1 <= 2 <= 4 <= 4 <= 8, asilx
windows 64-bit: 1 <= 2 <= 4 <= 4 <= 8, asi?x

Problems in EXTERN "C++":

• can't match up FB INTEGER or C++ long on Win64, they are different sizes
• can't write any code in FB that can use C++ long on Win64
• can't write any code in C++ that can use FB INTEGER on Win64

Possibly solutions to Win64 & EXTERN "C++"

• assume for now that C++ and Win64 data model won't change
• mangle both INTEGER and LONGINT to C++ long long. Generate a duplicate definitation if they conflict on overloaded symbol
• allow LONG (32-bit) to have attribute to mangle as C++ long (64-bit)
• allow INTEGER (mangled as C++ long), to have and attribute to be 32 bit.
• map INTEGER (still a separate data type) as 32-bit inside EXTERN "C++" on Win64

This last possible solution might be worth exploring. It fits with our notion that FB INTEGER size is dependant on platform.

[Jeff Marshall]

I tried some of the ideas I mentioned in last post:

• remapping the integer/uinteger (size) in general makes the porting problem worse across systems.
• remapping the integer/uinteger (size) either in extern blocks or similiar is worse having data types of varying size depending on context
• my other ideas for remapping size, equal bad
• basically, we don't want to change sizes

I created a pull request for an extension of dkl/integer-mangling that works as follows:

• the integer types keep the same size, as they do now. Long/ULong normally mangle to C++ 'int' type.
• On Win64, to call an external C++ procedure taking a 'long int', we need a 32bit type that mangles to C++ 'long int'.
• So I did it like this:

type long32 as long alias "long"

• declarations can be freely mixed with fbc's Long/ULong/Unsigned
• On all other platforms, it's just ignored and has no effect

Not directly related, but is also mangling, there is a fix for [#890] in the pull request.

[Jeff Marshall]

The specific bug reported "32bit Integer/Long mangling reversed" fixed in commit: [90f331]

'long alias "long"' added in commit: [e07d3b]
note add to wiki at Alias