[EMAIL PROTECTED] (Ludovic Courtès) writes: > > [AF_INET...] > + c_address = scm_malloc (sizeof (struct sockaddr_in)); > + c_inet = (struct sockaddr_in *)c_address; > + > + c_inet->sin_addr.s_addr = > + htonl (scm_to_ulong (SCM_SIMPLE_VECTOR_REF (address, 1)));
Looks like a memory leak here if scm_to_ulong throws an error. Obviously it won't normally, but a vector with any garbage could reach here. Maybe build the addr on the stack then memdup. Ditto the other cases. > [AF_UNIX...] > + > + if (path == SCM_BOOL_F) > + path_len = 0; What is #f here meant to support? > +#ifndef UNIX_PATH_MAX > +/* We can hope that this limit will eventually vanish, at least in GNU. > + However, currently, while glibc doesn't define `UNIX_PATH_MAX', it > + documents it has being limited to 108 bytes. */ > +# define UNIX_PATH_MAX 108 > +#endif > + if (path_len >= UNIX_PATH_MAX) How about sizeof(c_unix->sun_path)? > + scm_to_locale_stringbuf (path, c_unix->sun_path, > + UNIX_PATH_MAX); > + c_unix->sun_path[path_len] = '\0'; > + } > + else > + c_unix->sun_path[0] = '\0'; > + > + c_unix->sun_family = AF_UNIX; > + *address_size = SUN_LEN (c_unix); I think scm_to_locale_stringbuf will store nulls from the string but then SUN_LEN will truncate at the first one of those. Maybe nulls in the SCM should be an error (per scm_to_locale_stringn). _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user
