[erlang-questions] Bug in epmd_srv.c?
Klas Johansson
klas.johansson@REDACTED
Mon Dec 21 08:51:48 CET 2009
Hi Dave,
On Mon, Dec 21, 2009 at 4:01 AM, Dave Smith <dizzyd@REDACTED> wrote:
> On Sun, Dec 20, 2009 at 3:06 PM, Klas Johansson
> <klas.johansson@REDACTED> wrote:
>
>> The fix tries to address that. I'm not too sure about the fix
>> though, since this is in some sense not a backwards compatible
>> fix (since extra and it's length will be different). However,
>> since the previous version truncated (and garbled) the "extra"
>> field and erl_epmd.erl doesn't seem to care about it it might not
>> be that big a deal. Perhaps for some other third-party libraries
>> or other parts of Erlang/OTP (ei, jinterface, ...; I haven't
>> checked)? Also, I'm not that confident in modifying the
>> epmd... :-) I've attached a test case which illustrates the
>> problem. Get the code here:
>
> It's been a while since I've looked at this, but at first glance it
> seems to me that while your patch solves the case where extra is a
> typical null-terminated string, it does not address the problem where
> extra has binary data with nulls sprinkled throughout. To deal with
> this, you'd need to add a field to track the length of extra (instead
> of depending on strlen) and also replace the strcpy on 627 to a
> memcpy.
True. I've made a new version, which takes that into account. I
introduced a new field into the Node/enode struct which remembers
the length of the "extra" when a node is registered in the epmd,
and uses that length together with a memcpy when building the
PORT2_RESP.
I'd love to hear from the Erlang/OTP team and their take on this.
I can push it back to github later on today, if there are no
other things to take into account.
> Hope that helps. :) I am very glad to see someone else looking at it.
> Extra would be quite useful to have working properly.
:-) Thanks for your feedback.
BR,
Klas
More information about the erlang-patches
mailing list