Conference lassie::ucx

Are you using the proper C header file?  I
could not find inet_ntoa() in in.h from the most
current DEC C compiler but I _did_ find it in
inet.h.

Given the right side of the error message
it looks like you are getting a function
prototype for inet_ntoa() from somewhere,
but who knows where. (That is, the struct in_adder 
part is goodness.)

The right side of the message would lead 
me to ask what type is the variable 
ip_addr. Can you post the structure definition?

If the variable ip_addr is of type struct in_addr
then why not try passing simply ip_addr; the types
match.

Lee

    
    Hi Lee,
    
    here is the fragment of the program used:
    
    
    #include <errno.h>
    #include <types.h>
    #include <stdio.h>
    #include <socket.h>
    #include <in.h>
    #include <inet.h>
    main (int argc, char *argv[])
    ..
    ..
        int socket_1;  /* socket descriptor for socket 1 */
        struct sockaddr_in ip_addr;
        int sendlen, tolen, ip_addrlen;
        char rcvbuf[BUFSIZ];
    
    ..
    ..
    ..
    ..
    ..
    Now if I use the following it works fine.
    
            strcpy(res_addr,inet_ntoa(ip_addr.sin_addr));
    
    
    as the inet_ntoa expect a struct but using the following
    
     strcpy(res_addr,inet_ntoa(ip_addr.sin_addr.S_un.S_addr))
    
    I received the error message mention on my previous entry!
    due to the struct in_addr  I supposed otherwise I can not explained it.
    e.g.
           struct in_addr {
                union {
                    struct { unsigned char s_b1,s_b2,s_b3,s_b4; } S_un_b;
                    struct { unsigned short s_w1,s_w2; } S_un_w;
                    unsigned long S_addr;
    
    OK to this but what about the second question with ioctl() and
    the flags SIOCGIFFLAGS and SIOCGIFBRDADDR? Is it supported or
    implemented? Please let me know as the Swiss exchange will considers
    UCX for a project if this is supported otherwise will use
    multinet (TGV) which has a special call which enables them to
    get the Broadcast address i.e. SIOCGIFBRDADDR.
    
    best regards
    Phyl

Phyl,

Sounds like you have the solution to the first question.  
The header files do some re_definition of sin_addr, so 
I think that is why the the longer form fails (duplicated information).
Not sure there...

>    OK to this but what about the second question with ioctl() and
>    the flags SIOCGIFFLAGS and SIOCGIFBRDADDR? Is it supported or
>    implemented? Please let me know as the Swiss exchange will considers

I did not answer that question becuase it is outside my
area of expertise. It sounds like you need a more definitive
answer than notes will give. Since there is customer money
riding on this, have you considered an IPMT?

Lee

	Re inet_ntoa
        
        The inet_ntoa routine expects an argument of type "struct in_addr"
        passed by value:
        
        	/* Here is the prototype declaration from <inet.h> ... */
        	char *inet_ntoa (struct in_addr __in);
        
        The compiler is supposed to complain if you pass anything
        else.  So this works because ip_addr.sin_addr has the expected
        type "struct in_addr" (see <in.h> for what a "struct sockaddr_in"
        looks like) ...
        
>		struct sockaddr_in ip_addr;
>		strcpy(res_addr,inet_ntoa(ip_addr.sin_addr));
        
        ...and the compiler complains about this because
        ip_addr.sin_addr.S_un.S_addr has non-matching type
        "unsigned long" ...

>		strcpy(res_addr,inet_ntoa(ip_addr.sin_addr.S_un.S_addr))
        
        The compiler has to complain, because that's what type
        checking is.
        
        So if you have
        
        	struct sockaddr_in x;
        	struct in_addr y;
        
        then you can pass the "struct in_addr" to inet_ntoa() using
        
        	inet_ntoa(x.sin_addr)
        	inet_ntoa(y)
        
        but don't use x.sin_addr.S_un.S_addr or y.S_un.S_addr as the
        argument because their type is wrong for inet_ntoa().
        
        Dan