[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

u_short to int conversion

   From: nrouquet%gringo.usc.edu@usc.edu (Nicolas Rouquette)

[This message was obviously intended for Franz Inc tech support.
Sending it directly to us at cl-bugs@franz.com is much better than
posting to a general interest mailing list at Berkeley.]

   [Allegro CL, 3.0.3 on a Sequent Symmetry running Dynix V3.0.12]
   I have problems to pass a port number from C to lisp.

   int GetSockPort(Sock)
	int Sock;
     struct sockaddr_in sockad;
     int len;

     getsockname(Sock,(struct sockaddr *)&sockad,(int *)&len);

   Well, when get-sock-port is called with a socket, the value returned
   is correct. Many times I have had the same value for two different sockets.
   I think the problem lies in the fact that the sin_port of the sockaddr
   structure is declared as a u_short.

The undeclared C function implicitly returns type integer, so the
return statement should coerce the short to a long.  In other words,
the u_short isn't the problem.

I don't have a set of Sequent manual at hand right now, but this is
what Sun documentation says:

	getsockname(s, name, namelen)
	int s;
	struct sockaddr *name;
	int *namelen;

	Getsockname returns  the  current  name  for  the  specified
>>	socket.   The  namelen  parameter  should  be initialized to
>>	indicate the amount of space pointed to by name.  On  return
	it contains the actual size of the name returned (in bytes).

On quick examination, your problem *might* be that the automatic
variable len is being initialized by random stack contents.  If it
happens to be negative, zero, or small, then the call to getsockname
could be failing or else not returning the complete sockaddr
structure.  Perhaps your C function should be coded as below
(untested).  The important change is the initialization of len, but I
added error detection because (unlike Lisp) C often doesn't tell you
when things don't work, and without runtime typechecking, your "same
value for two different sockets" might just be identical "random"
stack garbage returned on successive calls.

   int GetSockPort(Sock)
	int Sock;
     struct sockaddr_in sockad;
>>   int len = sizeof sockad;

>>   if (getsockname(Sock,(struct sockaddr *)&sockad,(int *)&len) != 0)
>>     return(-1);

If this doesn't solve the problem let us know and we'll look further.