Continuing woes when mixing C and C++ code


Topic author
mberryman
Valued Contributor
Posts: 54
Joined: Sat Sep 02, 2023 1:31 pm
Reputation: 0
Location: Colorado Springs, CO, USA
Status: Offline

Continuing woes when mixing C and C++ code

Post by mberryman » Tue Dec 03, 2024 6:51 pm

Every package I have ported to VMS that uses C++ code either contains a mix of C and C++ routines or else the C++ routines call support libraries that are written entirely in C. In both cases, when one language calls the other, structures are shared that include elements defined using long, size_t, etc. Obviously, these structures don't match as compiled by each compiler and runtime havoc results.

One possible solution would be to compile all of the code with clang. This, of course, would result in a library that is now incompatible with other code compiled with the C compiler. That can be worked around. Unfortunately, it also appears that clang is not quite ready to take on the task of a general-purpose C compiler. These are some of the issues I have encountered.
  • Clang does not appear to use any logical names when deciding which directories to search for included files. Based on my experience, it only searches those directories specified on the command line or in an include-directory pragma.
  • Clang does not appear to search the directory of the including file first before using the command line. This causes problems when the filename being included appears in multiple directories.
  • Clang does not know how to find the variants of at least some functions when there are 32 and 64 bit versions. They must be explicitly specified. The following is an example.

    Code: Select all

    $ type test.c
    #include <string.h>
    
    void copyit( char * src, char * dst, size_t size)
    {
            memcpy(dst, src, size);
    }
    $ cc test
    $ clang -pointer-size=32 test.c
    test.c:6:19: error: too many arguments to function call, expected 2, have 3
            memcpy(dst, src, size);
                             ^~~~
    1 error generated.
    $
    $ type test.c
    #include <string.h>
    
    void copyit( char * src, char * dst, size_t size)
    {
            _memcpy32(dst, src, size);
    }
    $ clang -pointer-size=32 test.c
    $
    
And others, all of which I am sure that VSI is aware.

From a user perspective, the best fix would seem to be to add a switch to the C compiler that would cause it to treat all data types the same as the C++ compiler. I'm not sure how VSI would feel about that. The alternative would be to make clang a supported compiler for C code.

Any hints on what direction I should be pursuing when resolving these issues when mixing C and C++ code would be most welcome.


Topic author
mberryman
Valued Contributor
Posts: 54
Joined: Sat Sep 02, 2023 1:31 pm
Reputation: 0
Location: Colorado Springs, CO, USA
Status: Offline

Re: Continuing woes when mixing C and C++ code

Post by mberryman » Thu Dec 05, 2024 11:09 am

No. It means that I have 53 different libraries with a file called zlib.h.

One of the issues is that both gzip and zlib use zlib.h. Many packages bundle both and the version bundled varies. You don't want to grab the wrong one.

User avatar

arne_v
Senior Member
Posts: 625
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Offline
Contact:

Re: Continuing woes when mixing C and C++ code

Post by arne_v » Thu Dec 05, 2024 1:02 pm

The primitive pre-processing model combined with lack of namespaces can make C "interesting".

It seems to me that there is a gap - a Grand Canyon sized gap - between how the "business smart asses" think that software developers are going to be obsolete soon, because they will just tell some AI what they want in English and they will get production ready software back, and the real world of software development where people are constantly struggling solving even relative simple issues, because some design decisions was made 10/20/30/40/50 years ago and we are stuck with them.
Arne
arne@vajhoej.dk
VMS user since 1986

Post Reply