Thanks for the information, Mike. I appreciate it. Using the target
value you suggest does indeed solve the compile time problem I was
having and I don't have to define _NO_NEW_FUNC_CHECK.
Do you know where I can find the valid values for TARGET in the z/VM
environment documented?
Have a good one.
DJ
Michael Donovan wrote:
Dave,
First ... I apologize for the late response. I was out of the office
yesterday and I am just getting
caught up on all my mail.
If you specify the option "TARGET(0x41040000)", sans quotes, on the compile
command, you
should be able to cleanly compile your source and still use all the
appropriate checking and
such. As John pointed out, there appears to be a conflict between the way
FEATURES.H
and NETDB.H work (or don't work) together. I am trying to find more
information about how
these two are supposed to work. I will get back to you with whatever I
find.
Cheers!
Mike
Dave Jones
<[EMAIL PROTECTED]
are.com> To
Sent by: The IBM [email protected]
z/VM Operating cc
System
<[EMAIL PROTECTED] Subject
ARK.EDU> Re: Fw: a C language question....
01/25/2007 12:09
PM
Please respond to
The IBM z/VM
Operating System
<[EMAIL PROTECTED]
ARK.EDU>
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
