On Thu, Apr 19, 2012 at 10:19 PM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
>> 3. Considering these two sets:
>>
>> (a) [applications that rely on the assumption that there
>> is a null terminator inside sizeof(sun_path) bytes]
>> (b) [applications that would break if the kernel behavior changed]
>>
>> I suspect that set (a) is rather larger than set (b)--or, more
>> likely still, applications ensure they go for the lowest common
>> denominator limit of 92 (HP-UX) or 104 (historical BSD limit)
>> bytes, and so avoid this issue completely.
>
> Or another way of putting it
>
> 3(a) Sloppy coding that may have lots of other bugs
>
> 3(b) Interfaces and code we promised not to break.
Yes, it's another way of putting it. (Though regarding 3(b), part of
the problem is that there never was a clearly specified contract.)
Anyway, I've dug deeper, looking at hat happens on other platforms.
It's a mess: the BSDs don't even guarantee that sun_path is
null_terminated. So, here's how one has to portably deal with the
variations:
addrlen = sizeof(struct sockaddr_un);
cfd = accept(lfd, &addr, &addlen);
printf("%.*s", addrlen - offsetof(struct sockaddr_un, sun_path), addr.sun_path);
That's pretty hideous!
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
