C compiler error porting from Alpha to I64

[Dario Karlen]

Hey guys

I'm getting a compiler error:
flagword = TCPIP$C_MSG_NBIO + MSG_PEEK;
...................^
%CC-E-UNDECLARED, In this statement, "TCPIP$C_MSG_NBIO" is not declared.
at line number 114 in file DKA0:[INA.PROGS.DK]DEC90_OPEN.C;8
types.c and socket.h are included. it worked fine on an alpha system (vms V7.2-1, c V??) , but now we ported the c source to an I64 (vms V8.3, c V7.1) and getting this compiling error.
any ideas? thanks for any remark.

[Kris Clippeleyr · Accepted solution]

Dario,
The constant TCPIP$C_MSG_NBIO is defined in
SYS$LIBRARY:TCPIP$INETDEF.H
Regards,
Kris (aka Qkcl)

[Dario Karlen]

Hi Kris

Thanks a lot.
I included ucx$inetdef.h already, but with this file I got the error. now I replaced it with the file you suggested and it worked.
the last compiling error I get is this:
memcpy(&myaddr.sin_addr.s_addr, host->h_addr, 4);
....^
%CC-I-IMPLICITFUNC, In this statement, the identifier "memcpy" is implicitly dec
lared as a function.

can anybody help? my c knowledge is unfortunately very basic.

[Craig A Berry]

Dario,

Online help is very good for these things. It looks like you just need to include string.h:

$ help crtl memcpy


CRTL

memcpy

Copies a specified number of bytes from one object to another.

Format

#include

void *memcpy (void *dest, const void *source, size_t size);




Additional information available:

Function_Variants Arguments Description Return_Value

CRTL memcpy Subtopic?

[Hoff]

You've moved forward to a C compiler that defaults to detecting declaration errors; that better verifies the source code for correctness and consistency.

Where C symbols have moved over the years and the C compiler has definitely gotten better at spotting latent errors -- that memcpy was probably just an implicit declaration that the old compiler silently allowed -- but in cases like that TCPIP$C_MSG_NBIO symbol, that really smells like you're not using quite the same procedure(s) or same compilation command(s) or same header(s) that were originally used. That there are differences between what was used on OpenVMS Alpha V7.2-1 and OpenVMS I64 V8.? environment.

I've ported piles of C code among OpenVMS VAX and OpenVMS Alpha and OpenVMS I64, and (at least from Alpha to Integrity) it usually comes straight across.

Porting code forward from older C is a bit more problematic, as the older compilers missed or ignored various errors.

One way to potentially speed the process is the /FIRST_INCLUDE qualifier. I've used this qualifier with some success when porting open source onto OpenVMS, as it allows me to specify various fixes for the source code -- without altering the main source. It's also useful as it allows me to potentially experiment with the compilation, without having to back changes out of the main module. (This approach doesn't always work and certainly can't fix all cases of coding errors and compiler complaints, but for cases like #include string.h, it can be a very handy technique.)

Stephen Hoffman
HoffmanLabs

[Hoff]

The statement:

myaddr.sin_addr.s_addr = host->h_addr;

might also work as a replacement for the memcpy.

A memcpy of a longword address is somewhat like hunting insects with anvils. It works, but it's an effort. If you've a lot of these dinky memcpy sequences in the code and particularly in critical paths, definitely look into allowing the compiler to fully inline the memcpy and related operations.

And when you're mostly done with the compilation and link and initial debug, the next step is often hunting for unaligned references in the resulting execution environment, as these can massively degrade your processor performance. These unaligned references are seriously expensive for OpenVMS to field for you.

[Dario Karlen]

thank you a lot guys
with your help is was an easy solution.

I'm very pleased to have this resource center and so many friendly specialists.