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?

[dmjb]

This is documented in the release notes for C++ on x86 and is expected behaviour for that platform.

1.3 Differences Between C++ on OpenVMS Itanium and OpenVMS x86
The datatypes 'long', 'size_t', 'nullptr_t', 'ptrdiff_t' are 64-bits wide on OpenVMS x86 but only 32-bits wide on OpenVMS Itanium.

I'm not sure if there is anyway to make `long` be the same size in C and C++ - you may have to change the C code to use `long long`, or change both C++ and C to use stdint.h types.

EDIT: Messed up original message, ended up quoting myself instead of the release notes.

[saprykin]

Ah, okay, thanks for the hint. This is what I found in C++ release notes (for some reason I did not manage to find release notes on the official web site with documentation, only on osarchive.org):

1.3 Differences Between C++ on OpenVMS Itanium and OpenVMS x86
The datatypes 'long', 'size_t', 'nullptr_t', 'ptrdiff_t' are 64-bits wide on OpenVMS x86 but only 32-bits wide on OpenVMS Itanium.

So, not only long type. It should not be a big problem in my case as the library is in C, and C++ is used for tests only. It just make a test failing due to size mismatch. The first time I'm seeing such a behaviour.

[cct]

Ah, okay, thanks for the hint. This is what I found in C++ release notes (for some reason I did not manage to find release notes on the official web site with documentation, only on osarchive.org):

1.3 Differences Between C++ on OpenVMS Itanium and OpenVMS x86
The datatypes 'long', 'size_t', 'nullptr_t', 'ptrdiff_t' are 64-bits wide on OpenVMS x86 but only 32-bits wide on OpenVMS Itanium.

So, not only long type. It should not be a big problem in my case as the library is in C, and C++ is used for tests only. It just make a test failing due to size mismatch. The first time I'm seeing such a behaviour.

You can usually find the release notes in SYS$HELP:
If not they will ne available in the documentation part of the web site

[arne_v]

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.

I have mentioned it a couple of times, including:

https://www.vajhoej.dk/arne/vms/x64.html

and for pointer size:

https://www.vajhoej.dk/arne/articles/vms64.html

How to fix it?

There are no great solution but a few workarounds:

1) switch from int, long and long long to int32_t and int64_t [I consider this a general recommendable approach!]
2) #ifdef #else #endif to have different declarations for C and C++
3) compile your C code with the C++ compiler (requires that the C code is "nice" and do not have problems with the few cases where valid C has different semantics in C++)

[sms]

Code: Select all

      https://forum.vmssoftware.com/viewtopic.php?f=12&t=8657

> At the moment, there is no ability to change the size of long on any
> of the platforms or languages.

   A powerful argument could be made that none was needed, until the
new/different size of "long" arrived.

[arne_v]

viewtopic.php?f=12&t=8657

> At the moment, there is no ability to change the size of long on any
> of the platforms or languages.

A powerful argument could be made that none was needed, until the
new/different size of "long" arrived.

Not needed.

But from a C/C++ perspective it could have made sense to prepare for long changing.

Not so much sense for all those VMS Macro-32 people reading "long" as "longword" instead of "long int" though.

[sms]

Code: Select all

> Not needed.

   If you don't mind rewriting your programs to deal with the change,
then, no, you don't _need_ a convenient option to deal with the change.

[joukj]

But some things seem impossible at the moment:

C++ programs cannot use Xlib and friends.
Did someone find a "work-around" for that?

[pustovetov]

But some things seem impossible at the moment:

C++ programs cannot use Xlib and friends.
Did someone find a "work-around" for that?

Fix Xlib headers the same way as in the CRTL?

Code: Select all

# if defined(__clang__)
	unsigned int plane_mask;/* plane mask */
	unsigned int foreground;/* foreground pixel */
	unsigned int background;/* background pixel */
#else
	unsigned long plane_mask;/* plane mask */
	unsigned long foreground;/* foreground pixel */
	unsigned long background;/* background pixel */
#endif
etc etc

I don't know why this wasn't done.