[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un
From: |
Niels Möller |
Subject: |
Re: Bug#187391: libc0.3-dev: weirdness with sockaddr_un |
Date: |
03 Apr 2003 21:17:00 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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
Re: libc0.3-dev: weirdness with sockaddr_un, Niels Möller, 2003/04/03