Impossible to differentiate link references in bytecode

[pipermerriam]

Suppose I have the following solidity file in my project under the path ./a-really-long-directory-name-that-is-quite-long/MyContracts.sol

pragma solidity ^0.4.0;

library A {
  function return10() constant returns (uint) {
    return 10;
  }
}

library B {
  function return13() constant returns (uint) {
    return 13;
  }
}

contract C {
  function return11() constant returns (uint) {
    return A.return10() + 1;
  }

  function return26() constant returns (uint) {
    return 2 * B.return13();
  }
}

The compiler will produce the following output

$ solc a-really-long-directory-name-that-is-quite-long/a.sol --bin --optimize

======= a-really-long-directory-name-that-is-quite-long/a.sol:A =======
Binary:
60606040523415600b57fe5b5b606a8060196000396000f300606060405263ffffffff60e060020a600035041663f12005ed81146020575bfe5b60266038565b60408051918252519081900360200190f35b600a5b905600a165627a7a723058209906d15f5f839b6eaa5d5fd36bd25399e0737a4a1d3a36019da5e91bb48f66800029

======= a-really-long-directory-name-that-is-quite-long/a.sol:B =======
Binary:
60606040523415600b57fe5b5b606a8060196000396000f300606060405263ffffffff60e060020a60003504166316216f3981146020575bfe5b60266038565b60408051918252519081900360200190f35b600d5b905600a165627a7a7230582086610ca3cae669c8689d63ea85af911f8f3d66de0bdd3564a3ca6a69f348b6650029

======= a-really-long-directory-name-that-is-quite-long/a.sol:C =======
Binary:
6060604052341561000c57fe5b5b6101788061001c6000396000f300606060405263ffffffff60e060020a6000350416633f2c0057811461002c578063fbbb978c1461004e575bfe5b341561003457fe5b61003c610070565b60408051918252519081900360200190f35b341561005657fe5b61003c6100de565b60408051918252519081900360200190f35b600073__a-really-long-directory-name-that-is__63f12005ed6000604051602001526040518163ffffffff1660e060020a02815260040180905060206040518083038186803b15156100c157fe5b60325a03f415156100ce57fe5b5050604051516001019150505b90565b600073__a-really-long-directory-name-that-is__6316216f396000604051602001526040518163ffffffff1660e060020a02815260040180905060206040518083038186803b151561012f57fe5b60325a03f4151561013c57fe5b5050604051516002029150505b905600a165627a7a7230582074f1df49e3f69a4db9066a374b46d2abe8665e58bfad7cef20373957d6b82d520029

Given that the file path is sufficiently long it does not appear to be possible to differentiate which link reference in the bytecode belongs to which library since both appear as __a-really-long-directory-name-that-is__ with the actual filename and library name cutoff.

[pipermerriam]

First idea off the top of my head to fix this:

Instead of using the string __a-really-long-directory-name-that-is-quite-long/a.sol:B__ which gets truncated, you could instead use something like md5('a-really-long-directory-name-that-is-quite-long/a.sol:B'). This way the link reference in the bytecode is a fixed length and can be reliably mapped to which contract it belongs to.

Another option would be to not truncate it and instead include the byte length in the string as well. __a-really-long-directory-name-that-is-quite-long/a.sol:B:20__.

[pipermerriam]

Oh, and my example here is contrived but with package management these kind of long paths are actually pretty common.

[axic]

I think this will rather be solved by the JSON compiler interface to return the positions in the byte code used for linking. With that in place, the compiler will also be flexible at what content to include in that location.

[pipermerriam]

Is there an ETA for that? This fundamentally breaks packaging which is problematic.

…

On Sun, Feb 5, 2017, 10:07 AM Alex Beregszaszi ***@***.***> wrote: I think this will rather be solved by the JSON compiler interface to return the positions in the byte code used for linking. With that in place, the compiler will also be flexible at what content to include in that location. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1645 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAyTgsS452fDrXAojt0mnlDsysuGNEF8ks5rZgHVgaJpZM4L3YQz> .

[axic]

I hope we can close off the spec this coming week, then it is up to implementing it.

[pipermerriam]

Thanks for the quick responses. I'll keep an eye out for progress in this.

…

On Sun, Feb 5, 2017, 10:19 AM Alex Beregszaszi ***@***.***> wrote: I hope we can close off the spec this coming week, then it is up to implementing it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1645 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAyTgqDiWHwgXmApIug6HvWnOe6hoVRwks5rZgSlgaJpZM4L3YQz> .

[axic]

Fixed by #1387, but not yet implemented.

[pipermerriam]

Any word on when the JSON interface stuff is going to make it's way into a release. Since 0.4.9 is installed by default and brew/apt doesn't have easy facilities for installing old versions this is causing many of my users problems.

[LefterisJP]

+1 I am one of these users :)

[axic]

I think it likely could make it into the release following the next one.

[chriseth]

As this is not an issue on its own and already has a fix planned I'm closing it.