Bug#187391: libc0.3-dev: weirdness with sockaddr_un

[nisse@lysator.liu.se (Niels Möller)]

Robert Millan <zeratul2@wanadoo.es> writes:

> note what the docs say in reference to `char sun_path[108]':
> 
>           *Incomplete:*  Why is 108 a magic number?  RMS suggests making
>           this a zero-length array and tweaking the following example
>           to use `alloca' to allocate an appropriate amount of storage
>           based on the length of the filename.

And in any case, adding a sun_len element to the structure seems very
redundant. All functions using sockaddr:s already take a separate
socklen_t argument, as sockaddr:es in general have varying length.
Only oddity with sockaddr_un is that the length can vary also between
addresses within the same address family.

  socklen_t sa_len = offsetof(struct sockaddr_un, sun_path)
                     + filename_length + 1;
  
  sockaddr_un sa = alloca(sa_len);

should work fine for arbitrary length filenames, no matter if or how
the magic number 108 in the declaration is replaced.

(And I still think that the + 1 for a terminating NUL isn't really
necessary, although I'm not sure what the standard says on that).

/Niels