map@cscosl.ncsu.edu (Mark Parris) (07/22/89)
I've encountered what appears to be a bug with the getservbyname
C library call under Ultrix 3.0. Any help would be appreciated.
When I attempt to get the port address of a service using getservbyname
the port number that is returned is the actual port number times 256 (or
shifted 8?) mod 65535. I can use this number in the getservbyport and it
returns the same port. The true port value returns a null.
Is this a documented bug? If so, is there a fix for it? If not, any
ideas on what I might be doing wrong? Any suggestions would be appreciated.
Thanks,
Mark Parris
*** Please email, I will post a summary of responses. ***
-----------------------------------------------------------------------------
Mark Parris mcnc.org!cscosl!map
Please E-mail. I will summarize. michaud@decvax.dec.com (Jeff Michaud) (07/22/89)
In article <3459@ncsuvx.ncsu.edu>, map@cscosl.ncsu.edu (Mark Parris) writes: > When I attempt to get the port address of a service using getservbyname > the port number that is returned is the actual port number times 256 (or > shifted 8?) mod 65535. I can use this number in the getservbyport and it > returns the same port. The true port value returns a null. From the man page: s_port The port number at which the service resides. Port numbers are returned in network byte order. which is the same byte order which it should be shoved into sockaddr_in. In order to get it in the right byte order to print out in human readable form you need to use the ntohs() routine. -- /--------------------------------------------------------------\ |Jeff Michaud michaud@decwrl.dec.com michaud@decvax.dec.com| |DECnet-ULTRIX #include <standard/disclaimer.h> | \--------------------------------------------------------------/
thomas@mipsbx.nac.dec.com (Matt Thomas) (07/22/89)
> When I attempt to get the port address of a service using getservbyname > the port number that is returned is the actual port number times 256 (or > shifted 8?) mod 65535. I can use this number in the getservbyport and it > returns the same port. The true port value returns a null. Are you using htons to make sure your entworking software is portable between little-endian machines (like DEC's VAX or MIPS system) and big-endian machines like Suns? Remember that the getXXXXbyYYYY routines return the values in host order and that you need to the use the hton macro's to conver it to network order (which happens to be big-endian). -- Matt Thomas Internet: thomas@decwrl.dec.com DECnet-Ultrix Development UUCP: ...!decwrl!thomas Digital Equipment Corporation Disclaimer: This message reflects my own Littleton, MA warped views, etc.