Robert Millan <[EMAIL PROTECTED]> 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
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
