[erlang-questions] unix domain sockets with abstract namespace: can't use all 108 bytes

[Ali Sabil]

Just a suggestion, but would it make sense to handle abstract unix sockets
differently at the Erlang level?

Basically if the path is a binary or list consider it a standard path and
append the null byte, but if it is for example a tuple `{abstract, string()
| binary()}` then prepend the null byte instead of appending?
On Fri, 28 Apr 2017 at 10:42, Raimo Niskanen <
raimo+erlang-questions@REDACTED> wrote:

> On Fri, Apr 28, 2017 at 04:46:17PM +1200, Richard A. O'Keefe wrote:
> :
> >
> > My argument goes like this:
> >  - Linux is too important to ignore
> >  - The Linux extension is a genuinely useful feature
> >    done in a rather unpleasant way
> >  - If you are using AF_UNIX in the portable way, you should
> >    provide the *length* of the address, not the *size* of the
> >    struct.  I remember it being that way in 4.2 BSD and have
> >    cited material from some of the key BSD people that that was
> >    certainly the intent in 4.3BSD.
> >  - But if you care about HP-UX, you had better do some experiments.
> >
> > Honestly, just doing the right thing is less effort than arguing
> > about it.
>
> Precisely.  Well put!  But what is the "right thing"?
>
> The current implementation passes the address given to it as is, but
> ensures it is correctly terminated as in appending a '\0' at the end
> that is not counted for address_len, and if that does not fit
> in the defined size it bails out.
>
> That felt like the "right thing" when I wrote it, but you can not set the
> last byte of the address to non-zero.
>
> The new "right thing" could be to add an exception to the above when there
> is a '\0' first in the address, since that hopefully will count as a
> correct termination on OS:es that do not understand abstract addresses.
>
> The question is if there is any danger in this because we then give a
> contradiction to e.g bind() because we have not used SUN_LEN(su) as we were
> told to do...?
>
> I believe not, and will try to find the time to do this
> after our OTP-20.rc1 pre-release.
>
> --
>
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170428/09259520/attachment.htm>