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 IBMVM@LISTSERV.UARK.EDU
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
>>
