Craig Berry wrote:
!Peter,
!
!Thanks for working on this. With that head start I am now able to nail
the
!exact problem with gethostbyaddr, though integrating a fix into Perl will
!still be a bit messy. With the socktest.c program at the end of this
!message, I get an address length of 58 by using the headers and routines
!supplied with the C RTL:
This is interesting. Indeed, later last night I wrote a program
very similar to yours with which I can also see a h->h_length problem.
The value I obtained (62) matches the length of the perl hostent.t
test return: C<gethost("127.0.0.1");> returns a perl scalar string of
length 62 for me with my set up (hence I wonder if your is length 58?).
On further investigation I found that with my 4.3A Multinet
gethostbyaddr() is documented as:
(struct hostent *) gethostbyaddr(Addr, Length, Family);
char *Addr;
unsigned int Length;
unsigned int Family;
The prototype inside of the multinet netdb.h header is:
struct hostent *gethostbyaddr __P((const void *, int, int));
I was curious about possible updates to Multinet and was
intrigued that the docs for Multinet 4.4 (based on the 4.4 BSD
behavior???) at:
http://www.multinet.process.com/ftp/docs/html/programmers_reference/Ch02.htm#E48E13
also mentions "char *Addr", but then goes on to add:
"Addr is a pointer to an in_addr structure." -- ???
The other concern that I have is: what to do with the extra
characters? Should we simply truncate the returned address(es)
at 4? What about IPv6 addresses? Basically: can we accomdate
the difference between the hostent in DECC and the hostent in
Multinet land?
Craig went on to note:
!Making use of this will be a bit of a mess since configure.com will have
to
!detect Multinet and define the MULTINET_SOCKETS macro. Then probably
!sockadapt.h will have to be modified to include the alternate headers when
!the macro is defined. Then one of the linker options files (I'm not sure
!which one) will need to have a line added to link against the Multinet
!socket library. Any takers?
If this proves necessary I already have a strategy mapped out:
configure.com can do an f$search for the necessary bits, namely
multinet_root:[multinet.include]netdb.h, and
MULTINET:MULTINET_SOCKET_LIBRARY.EXE, in addition and to
circumvent trouble with dual stack boot machines it should
$status .eq. 1 (successfully) run a simple command like
"multinet show /version" and only then turn on MULTINET_SOCKETS.
I was able to successfully switch from the system <netdb.h>
to the multinet one in sockadapt.h with code that looked like:
--- vms/sockadapt.h Tue May 14 19:13:02 2002
+++ sockadapt.h Thu May 16 14:30:18 2002
@@ -23,8 +23,11 @@
# include <socket.h>
# include <inet.h>
# include <in.h>
-/* # include <netdb.h> */
-# include "multinet_root:[multinet.include]netdb.h"
+# ifdef MULTINET_SOCKETS
+# include "multinet_root:[multinet.include]netdb.h"
+# else
+# include <netdb.h> /* system (UCX) header */
+# endif
#if ((__VMS_VER >= 70000000) && (__DECC_VER >= 50200000)) || (__CRTL_VER >
= 70000000)
#else
void sethostent(int);
In particular I have tagged along with #define DECCRTL_SOCKETS,
which must both be defined. It looks like if we add
a ~MULTINET_SOCKETS~ near the top of vms/descrip_mms.template
that would then ask the run of [.vms]genopt to add the line:
MULTINET:MULTINET_SOCKET_LIBRARY.EXE/SHARE
to crtl.opt. I've already test out most of this apart from
the propsed change to descrip_mms.template. I am not sure
yet if I'd need to alter genopt.com.
Peter Prymmer
