Requiring specific targets as compile-time options makes package development (and porting) quite a bit more complicated.
Traditionally, the headers have sufficient conditionals to "do the right thing". -- R; Dave Jones <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 01/26/2007 09:14 AM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> From Dave Jones <[EMAIL PROTECTED]> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Fw: a C language question.... 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 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 > >
