Different size of long with C and C++ on x86

[saprykin]

Hello,

Thanks for providing community images of OpenVMS for x86! I'm trying to port a library which works on OpenVMS 8.4 (Alpha, IA64) to OpenVMS 9.2 (x86_64) using the latest community VMDK image. Right now I have a strange problem: when I compile a simple program with C compiler (basically, printing the size of long type), it shows that the size of long is 4 bytes, as on Alpha/IA64. However, the same program compiled with C++ compiler, outputs 8 bytes. How is that possible? Are there special compile options required to make C++ programs compatible with C?

[joukj]

Thanks, I'll try

Does this also fix the 64-bit alignment of the structures?

[pustovetov]

Does this also fix the 64-bit alignment of the structures?

I think not. But do we have a problem with the alignment of the structures?

[joukj]

Yes. Structures can be declared in the C++ code and passed to Xlib. Since Xlib is 32 bit with 32 bit aligned . I tried to create a work-around by writing C-wrappers (see http://galop.nano.tudelft.nl/openvms/so ... html#cxX11 ) but run into a problem where C-returned something which caused C++ to crash (see crystal sample in cxX11). In cxx11 I used some redefinitions of the structures.

Unfortunately I cannot test at the moment, since I do not have a license for X86 any more (I got admitted to the amnbasador program, but that is not in place and I did not hear anything on my application for the VMDK-disk.)

[soutbarr]

Yes. Structures can be declared in the C++ code and passed to Xlib. Since Xlib is 32 bit with 32 bit aligned . I tried to create a work-around by writing C-wrappers (see http://galop.nano.tudelft.nl/openvms/so ... html#cxX11 ) but run into a problem where C-returned something which caused C++ to crash (see crystal sample in cxX11). In cxx11 I used some redefinitions of the structures.

Unfortunately I cannot test at the moment, since I do not have a license for X86 any more (I got admitted to the amnbasador program, but that is not in place and I did not hear anything on my application for the VMDK-disk.)

There will be no great ways to do it, but try to force the structure to be 64 bit aligned while still being 32 bit aligned. i.e. you use a 64 bit type your fine.

int32_t var1;
int32_t dummy; /* Put in to maintain proper 64 bit alignment for xlib */
int64_t var2;
int8_t var3;
int8_t dummy2;
int16_t dummy3; /* put in to maintain proper 64 bit alignment for xlib */
int32_t dummy4;

Carefully design your structures so they remain exact to data type sizes and position.

Note: I haven't done this on OpenVMS yet but other systems when interfacing 64 bit and 32 bit.

[saprykin]

I believe that the VSI compiler strategy is:
* C - maintain 100% compatibility with traditional VMS C compilere
* C++ - stay as close to standard clang as possible (traditional VMS C++ compilers are old and let us call it "as good as VAX C was for C").

So the C++ compiler is a lot more 64 bit'ish than the C compiler.

It is documented.

Thanks for the links! C++ compiler is a bit strange, apart from using different size of long, it also poses some difficulties to detect. I mean, it does not define DEC-specific macros like __DECC or __DECCXX, and it also does not define Clang-specific macros like __clang__ or __clang . How should one treat it in cross-platform software? I did not find a full list of predefined macros, does it exist somewhere? It defines VMS-specific macros, yes, but that is more platform/OS hint, as there, in theory, can be multiple compilers.

I just disabled a few long-related checks in the tests and everything went fine. However, the decision to use different size of long will definitely bring more confusion in the future.

[arne_v]

$ help cxx lang pred

should tell what gets defined. If it is not correct, then report it to VSI.

Added in 1 minute 27 seconds:
Also note that the C++ compiler can be invoked two different ways:
* cxx dcl verb
* clang foreign command

If you use clang on other platforms, then maybe the foreign command is better for you.

[saprykin]

No, clang as itself is not required. However, detecting a compiler as clang-based is nice. At the end, __VMS and __clang__ did the trick.

$ help cxx lang pred

That's what I was looking for, thanks.

[jreagan]

We are working on those xlib headers. We simply forgot about them earlier in the port. There is no good workaround.

Yes, use int for 32-bit things and long for 64-bit things. There really is no good excuse on Alpha/Itanium for using long.

And for size_t, offset_t, and ptrdiff_t going to 64-bits, you still cannot have stack locals that big (the stack is still in 32-bit address space). I've seen code that declared variables as size_t when they should have used intptr_t (which is 64-bits on Alpha, Itanium, and x86)

[arne_v]

For external stuff one does not have a choice.

But for stuff under ones own control, then I would say:
- never use short/int/long
- always use int16_t/int32_t/int64_t

And if a struct foobar needs to change fields from 32 to 64 bit, then create a new struct foobar64.

More work upfront, but less messy down the road when everything always have the same size.

Just my 2 øre.

[mberryman]

I have worked on a few packages that mix C and C++ code and which also share structs that include elements defined using long, size_t, etc. Compiling with the C and CXX compilers produced the obvious size mismatches. I solved this problem by simply compiling everything with clang. Since clang is both a C and C++ compiler, this also eliminates the need to make one's C code C++ clean.