Re: Exposing common type wrapping/unwrapping methods

[Kevin Ryde]

address@hidden (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).