John, it turns out that using the #define _NONEW_FUNC_CHECK doe not
simply revert to the default of having the undeclared getaddrinfo
function return an int. It actually generates the following:
#pragma map (getaddrinfo, "@@GTADRI")
#pragma map (getnameinfo, "@@GTNAMI")
#pragma map (gai_strerror, "@@GAISTR")
#pragma map (freeaddrinfo, "@@FRADDR")
Why it does this, I don't have a clue, and you're right that type
checking is clearly not being done here. Stranger and stranger....
DJ
John P. Hartmann wrote:
Dave,
In a word: Not a good idea.
That define means that the declaration of the offending function is
omitted and you fall back on the default of all undeclared functions
being something returning int, but that suppresses type checking of
the function arguments.
You need to convince the compiler that you are compiling for the level
that includes the code for the function. 4104 seems to be the
operative here. So a specify the appropriate TARGET parameter to the
compiler.
Then find out why your compiler installation does not default to
TARGET CURRENT as it should and fix that.
j.
On 1/25/07, Dave Jones <[EMAIL PROTECTED]> wrote:
Thanks to the help and advice of the good folks on this list, I have
managed to solve my C compiler problem. Turns out that I need to do a
#define _NO_NEW_FUNC_CHECK
at the beginning of the code. That tells the C compler (C/C++ for z/VM,
btw) to actually include the correct code to invoked the "getaddrinfo"
function, instead of generating a dummy external structure with the name
of "getaddrinfo". The dummy structure was the actual source of the error
message the C compiler produced.
Unfortunately, the _NO_NEW_FUNC_CHECK directive is not documented
anywhere in either the C or LE manuals, and I don't have a warm fuzzy
feeling about having to use it. Maybe some one from C or LE development
can add to my understanding of why it's there and what it's meant to
do...
The good news is that the code now compiles, loads and runs as I expect
it to.
Thanks again, and have a good one.
DJ
