Git Product home page Git Product logo

solidity-bytes-utils's People

Contributors

bh2smith avatar cleanunicorn avatar djb15 avatar flada-auxv avatar fubuloubu avatar gnsps avatar hihiben avatar niran avatar pegahcarter avatar rotcivegaf avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

solidity-bytes-utils's Issues

`toUint24` removed?

Why was the "toUint24" method removed?

Here is the rather simple code to implement it:

function toUint24(bytes memory _bytes, uint256 _start) internal pure returns (uint24) {
        require(_bytes.length >= _start + 3, "toUint24_outOfBounds");
        uint24 tempUint;

        assembly {
            tempUint := mload(add(add(_bytes, 0x3), _start))
        }

        return tempUint;
}

concatStorage test data repeats itself instead of varying by case

In the tests, the results for concatenating with storageBytes31 are always the same as with storageBytes32 and storageBytes70, among others.

    storageBytes4.concatStorage(memBytes4);
    testBytes = hex"f00dfeedf00dfeed";
    AssertBytes.equalStorage(storageBytes4, testBytes, "storageBytes4 + memBytes4 concatenation failed.");

    storageBytes31.concatStorage(memBytes4);
    testBytes = hex"f00d000000000000000000000000000000000000000000000000000000feedf00dfeed";
    AssertBytes.equalStorage(storageBytes31, testBytes, "storageBytes31 + memBytes4 concatenation failed.");

    storageBytes32.concatStorage(memBytes4);
    testBytes = hex"f00d000000000000000000000000000000000000000000000000000000feedf00dfeed";
    AssertBytes.equalStorage(storageBytes32, testBytes, "storageBytes32 + memBytes4 concatenation failed.");

    ...


    storageBytes70.concatStorage(memBytes4);
    testBytes = hex"f00d000000000000000000000000000000000000000000000000000000feedf00dfeed";
    AssertBytes.equalStorage(storageBytes70, testBytes, "storageBytes70 + memBytes4 concatenation failed.");

These tests pass, which seems problematic.

forge-std & ds-test are being installed in downstream projects

The problem

forge-std and ds-test are being installed in downstream projects even though they are not needed for this library. They are only used for testing so they should be marked as devDependencies instead of dependencies

The solution

The minimal solution would consist of changing dependencies to devDependencies. However, to follow the good scout rule, a little cleanup was introduced in #67:

  • Adding CI pipeline to test any changes
  • Add forge-std the foundry way

Use keccak to compare arrays

BytesLib.equal and BytesLib.equal_nonAligned can be replaced with a much simpler, more gas efficient and purely Solidity (YUL probably won't bring any benefits here): return _preBytes.length == _postBytes.length && keccak256(_preBytes) == keccak256(_postBytes);.

First require of the slice

Hi,
I have a question on the first require on the slice method.
Shouldn't this require(_length + 31 >= _length, "slice_overflow"); be require(_bytes.length + 31 >= _length, "slice_overflow"); to be meaningful?

bytes arrays in storage shouldn't be treated as zero-padded in concatStorage

Storage arrays can be shortened by setting bytes.length to a lower value. I don't think that zeros out the freed bytes. If not, we can't just add a value to the last 32 bytes of storage because the lower-order bytes might be garbage.

            sstore(
                sc,
                add(
                    and(
                        fslot,
                        0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff00
                    ),
                    and(mload(mc), mask)
                )
            )


            ...

           sstore(sc, add(sload(sc), and(mload(mc), mask)))

Release new version with updated dependencies

Hello,
The current release on npm is about 10 months old, and it relies on some outdated packages/versions (namely truffle-hdwallet-provider v0.0.3 ).

Can we release a new version with updated dependencies, please? @GNSPS I think it would at least partially solve the issue #29.

free memory pointer seems to leave extra space sometimes

When we update the free memory pointer in concat, we make sure that we leave a blank 32 bytes if the second array's length was a multiple of 32. Is this ever necessary? Even when two zero-length arrays are combined, the free memory pointer would be moved 32 bytes for the length anyway.

slice with length 32 seems to produce error

I think there's a bug in slice() when length=32. Um, I'm not a solidity expert, and certainly not a solidity assembler expert, but here's a small test (patch) that demonstrates. Output included below, and then a patch (to TestBytesLib2.sol) below that.

    2) testSlice_0_32

    Events emitted during test:
    ---------------------------

    TestEvent(result: <indexed>, message: ofs=0,len=32)

    ---------------------------
    3) testSlice_1_32

    Events emitted during test:
    ---------------------------

    TestEvent(result: <indexed>, message: ofs=1,len=32)

    ---------------------------
    4) testSlice_31_32

    Events emitted during test:
    ---------------------------

    TestEvent(result: <indexed>, message: ofs=31,len=32)

    ---------------------------
    â testSlice (89ms)
    â testToUint (48ms)
    â testToAddress (56ms)


  22 passing (3s)
  4 failing

  1) TestBytesLib2 testSlice_16_32:
     Error: ofs=16,len=32
      at /home/chet/Hack/Ethereum/src/truffle/build/cli.bundled.js:319974:17
      at Array.forEach (<anonymous>)
      at processResult (/home/chet/Hack/Ethereum/src/truffle/build/cli.bundled.js:319972:19)
      at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:188:7)

  2) TestBytesLib2 testSlice_0_32:
     Error: ofs=0,len=32
      at /home/chet/Hack/Ethereum/src/truffle/build/cli.bundled.js:319974:17
      at Array.forEach (<anonymous>)
      at processResult (/home/chet/Hack/Ethereum/src/truffle/build/cli.bundled.js:319972:19)
      at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:188:7)

  3) TestBytesLib2 testSlice_1_32:
     Error: ofs=1,len=32
      at /home/chet/Hack/Ethereum/src/truffle/build/cli.bundled.js:319974:17
      at Array.forEach (<anonymous>)
      at processResult (/home/chet/Hack/Ethereum/src/truffle/build/cli.bundled.js:319972:19)
      at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:188:7)

  4) TestBytesLib2 testSlice_31_32:
     Error: ofs=31,len=32
      at /home/chet/Hack/Ethereum/src/truffle/build/cli.bundled.js:319974:17
      at Array.forEach (<anonymous>)
      at processResult (/home/chet/Hack/Ethereum/src/truffle/build/cli.bundled.js:319972:19)
      at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:188:7)

patch for test:

diff --git a/test/TestBytesLib2.sol b/test/TestBytesLib2.sol
index 9528a55..a62f24a 100755
--- a/test/TestBytesLib2.sol
+++ b/test/TestBytesLib2.sol
@@ -53,6 +53,37 @@ contract TestBytesLib2 {
     * Slice Tests
     */
 
+    function slowslice(bytes a, uint ofs, uint len) internal returns (bytes) {
+      require(ofs + len <= a.length) ;
+      bytes memory b = new bytes(len) ;
+      for(uint i = 0 ; i < len ; i++) {
+       b[i] = a[ofs+i] ;
+      }
+      return b ;
+    }
+
+    function once_test(bytes _bytes, uint ofs, uint len, string msg) internal {
+      require(ofs + len <= _bytes.length) ;
+      bytes memory want = slowslice(_bytes, ofs, len) ;
+      bytes memory got = _bytes.slice(ofs, len) ;
+      AssertBytes.equal(want, got, msg) ;
+    }
+
+    function _bytes() returns (bytes) {
+      bytes memory _bytes = hex"deadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef" ;
+      return _bytes ;
+    }
+
+    function testSlice_16_31() public { once_test(_bytes(), 16, 31, "ofs=16,len=31") ; }
+    function testSlice_16_32() public { once_test(_bytes(), 16, 32, "ofs=16,len=32") ; }
+    function testSlice_16_33() public { once_test(_bytes(), 16, 33, "ofs=16,len=33") ; }
+    function testSlice_16_65() public { once_test(_bytes(), 16, 65, "ofs=16,len=65") ; }
+    function testSlice_65_65() public { once_test(_bytes(), 65, 65, "ofs=65,len=65") ; }
+    function testSlice_0_32() public { once_test(_bytes(), 0, 32, "ofs=0,len=32") ; }
+    function testSlice_1_32() public { once_test(_bytes(), 1, 32, "ofs=1,len=32") ; }
+    function testSlice_31_32() public { once_test(_bytes(), 31, 32, "ofs=31,len=32") ; }
+
+
     function testSlice() public {
         bytes memory memBytes33 = hex"f00d0000000000000000000000000000000000000000000000000000000000feed";
 

Documentation inaccuracy

Hello,
there inaccuracy in Readme.md in NPM section. There is example of import

import 'solidity-bytes-utils/BytesLib.sol';

but in current version it should be

import 'solidity-bytes-utils/contracts/BytesLib.sol';

Adding functions to convert slices of bytes to/from uint{8,16,32,64}

I'd like to start adding functions to convert slices of bytes to/from uint8, uint16, etc. But I know nothing of Solidity's assembler, so I'd have to write these in Solidity itself, which I'm presuming will be inefficient (can already see that for some operations, the assembler is just faster).

Do you have any suggestions for where to go, to start learning assembler?

concat is redunant

AFAIK, calling concat(a,b) is redundant and can be replaced with:

abi.encodePacked(a,b)

isn't it?

excessive dependencies...

importing this package adds ~60Mb of dependencies (not counting truffle). its a Solidity-only project Solidity-only, so it shouldn't add js modules.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.