eosio / fc Goto Github PK

While compiling in Ubuntu 18.10 I get:

/fc/src/log/log_message.cpp:165:4: warning: control reaches end of non-void function [-Wreturn-type]
}

By 4d8b5e5, all of the HTTP responses by nodeos includes "Connection: close" header.
It means all DApps which use the common HTTP/1.1 libraries are forced to do TCP connect for every HTTP request, which can cause significant performance degradation and resource exhaustion(TCP port, ...).

added "Connection: close" to websocketpps http request handling as "keep-alive" is the default for HTTP/1.1 and it was confusing Beast

I don't know what the problem was caused by Beast, but setting "Connection: close" header must be done specifically not generally.

conr2d/fc@5869f1a

I think that you don't like this idea because of ambiguity which can cause developers' mistake.
This patch allows variant to serialize integer, floating-point number, boolean and hex string.

For example,

struct options {
   bool   foo;
   int    bar;
   double baz;
};

[[eosio::action]]
void setoption(std::string key, std::vector<char> rawdata) {
   options opts;
   if( key == "foo" ) {
      auto value = eosio::unpack<bool>(rawdata);
      opts.foo = value;
   } else if( key == "bar" ) {
      auto value = eosio::unpack<int64_t>(rawdata);
      opts.bar = value;
   } else if( key == "baz" ) {
      auto value = eosio::unpack<double>(rawdata);
      opts.baz = value;
   } else { // hex string
      printhex(rawdata.data(), rawdata.size());
   }
   ...
}

cleos push action test setoption '["foo", true]' -p test@active
cleos push action test setoption '["bar", 1234]' -p test@active
cleos push action test setoption '["bar", 0x1234]' -p test@active
cleos push action test setoption '["bar", "1234"]' -p test@active // wrapped by double quotes means hex string
cleos push action test setoption '["baz", 1.234]' -p test@active

Currently DEX usually handles token following standard token interface (eosio.token), but there could be various types of token. For example, non-fungible token is usually represented in 256-bit integer to support 256-bit hash of its metadata directly. If bytes array can serialize various types of raw data, the one action which handles multiple types of token will be available.

[[eosio::action]]
void transfer(name from, name to, std::vector<char> value, std::string memo);

This task can be done manually by advanced users, so I also think that this doesn't need to be supported by default. Just wanna share small experiment. You can close this at any time. :)

When I compile eos, the make command stops and report below error:
libraries/chain/include/eosio/chain/types.hpp:17:10: fatal error: 'fc/smart_ref_fwd.hpp' file not found

There's no file named smart_ref_fwd.hpp in libraries/fc/include/fc directory. Which branch of fc should I checkout for compile eos?

How to solve the fc separate compile time error?

For canonical signature checks most standard ec libraries only enforce a low_s however the code referenced in this issue is enforcing a low_r (r being less than half of the curve order) as well. I'm wondering why that check is needed? Checking low_s should be enough to protect against signature malleability.

A clarification on why a low_r is being checked would be greatly appreciated, and if there is no need for it can that check be removed?

Why not return s._hash[0];?

time_point_sec::to_iso_string use boost::ptime to convert time_t to ios 8601 time string format with:
const auto ptime = boost::posix_time::from_time_t( time_t( sec_since_epoch() ) );
return boost::posix_time::to_iso_extended_string( ptime );
Note ptime has drop the zone info, and not strict compatible iso 8610.
it convert to string without zone and can be understand in context,
(sometimes is UTC or sometimes local zone with utc_to_local...)

https://en.wikipedia.org/wiki/ISO_8601, it says
"If no UTC relation information is given with a time representation, the time is assumed to be in local time. ...", it confused, i thank should append 'Z' to indicate UTC zone, and change code:
return boost::posix_time::to_iso_extended_string( ptime )+"Z";

diff --git a/src/filesystem.cpp b/src/filesystem.cpp
index 1b8df20..e643097 100644
--- a/src/filesystem.cpp
+++ b/src/filesystem.cpp
@@ -257,7 +257,7 @@ namespace fc {
      }
      if( ec ) {
         FC_THROW( "Copy from ${srcfile} to ${dstfile} failed because ${reason}",
-              ("srcfile",f)("dstfile",t)("reason", ec.category().name() ) );
+              ("srcfile",f)("dstfile",t)("reason", ec.message() ) );
      }
   }
   void resize_file( const path& f, size_t t )

(thx Steve!)

Seems like bug after providing correct url as std::string fc::url wrong parsing it and trim until path.

auto m_url = fc::url("http://nsqd-nodeos:4151/pub?topic=eos_actions");
ilog("URL string: ${str}", ("str", m_url)); http://nsqd-nodeos:4151/pub - incorrect
ilog("Url path: ${p}", ("p", m_url.path())); /pub - correct
ilog("Url query: ${q}", ("q", m_url.query())); empty - incorrect
ilog("Url args: ${r}", ("r", m_url.args())); empty

For EOS 2.0.x, it seems: eosio-2.0.x is develop branch and v2.0.x is production branch.

But for EOS 2.0.8 (corresponding fc @ b53dbdc):

git branch -r --contains b53dbdc
  origin/v2.0.x

And for EOS 2.0.9 (corresponding fc @ a369475):

git branch -r --contains a369475
  origin/eosio-2.0.x
  origin/keke_epe294 

So fc used by EOS 2.0.9 does not contains commit b53dbdc which is existing in EOS 2.0.8 ?

As per W3C RP ID specs at https://w3c.github.io/webauthn/#relying-party-identifier

"Given a Relying Party whose origin is https://login.example.com:1337, then the following RP IDs are valid: login.example.com (default) and example.com, but not m.login.example.com and not com."

However, fc does a rpIdHash === sha(clientDataJSON.origin) match which is too strict and does not cover the case where the origin may be login.example.com while the rp id is example.com:

There are no README file within project. I think it would be great to have it.

Since there is interest in customizing key prefixes, allow for specifying custom prefixes at compile time.

• No impact on default behavior
• Use new (PUB_K1_xxxx) not legacy (EOSxxxx) format
• Enhance build logic so that new format can be used to allow for custom keys such as MYSYM_K1_ instead of PUB_K1_
• Both MYSYM_K1_ and PUB_K1_ will be accepted by the system since the actual number past prefix is unaffected
• Default "PUB" will be replaced with "MYSYM" (for example) at compile time (see: public_key_base_prefix https://github.com/EOSIO/fc/blob/df5a17ef0704d7dd96c444bfd9a70506bcfbc057/include/fc/crypto/public_key.hpp)
• Treat encryption marker K1|R1 or others in the future separately, no change (ref: EOSIO/eos#2441)
• Same customization for SIG and PVT prefixes if desired.
• Custom symbols will be passed at compile time for different chains

@tbfleming, @jgiszczak, @heifner: Since there is a fair amount of conversation on this subject already EOSIO/eos#5467, submitting a proposal first, I can do a PR if there is general acceptance and/or suggestions of course.

Cheers,
Dmitri

Hi
I im trying to compile eos/unittests cpp files and I get this error:

fatal error: fc/reflect/reflect.hpp: No such file or directory
 #include <fc/reflect/reflect.hpp>

so now I'm trying to install fc library you,ve provided.
This is the command I used and the error I've got.

cmake .
CMake Error at CMakeLists.txt:25 (find_package):
  By not providing "FindSecp256k1.cmake" in CMAKE_MODULE_PATH this project
  has asked CMake to find a package configuration file provided by
  "Secp256k1", but CMake did not find one.

  Could not find a package configuration file provided by "Secp256k1" with
  any of the following names:

    Secp256k1Config.cmake
    secp256k1-config.cmake

  Add the installation prefix of "Secp256k1" to CMAKE_PREFIX_PATH or set
  "Secp256k1_DIR" to a directory containing one of the above files.  If
  "Secp256k1" provides a separate development package or SDK, be sure it has
  been installed.


CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

    cmake_minimum_required(VERSION 3.12)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP0000".
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!
See also "/home/poores/fc/CMakeFiles/CMakeOutput.log".

@larryk85

secp256k1/upstream points to a Github repo that does not have a master branch. This leads to an error when trying to update all externals recursively from my project that uses FC as external.

It also reproduces in standalone FC:

eosio@sthist:~/tmp$ git clone https://github.com/EOSIO/fc.git
Cloning into 'fc'...
remote: Enumerating objects: 155, done.
remote: Counting objects: 100% (155/155), done.
remote: Compressing objects: 100% (78/78), done.
remote: Total 2188 (delta 73), reused 115 (delta 57), pack-reused 2033
Receiving objects: 100% (2188/2188), 1.01 MiB | 2.68 MiB/s, done.
Resolving deltas: 100% (1174/1174), done.
eosio@sthist:~/tmp$ cd fc/
eosio@sthist:~/tmp/fc$ git submodule update --init --recursive
Submodule 'secp256k1/upstream' (https://github.com/cryptonomex/secp256k1-zkp.git) registered for path 'secp256k1/upstream'
Cloning into '/home/eosio/tmp/fc/secp256k1/upstream'...
Submodule path 'secp256k1/upstream': checked out 'bd067945ead3b514fba884abd0de95fc4b5db9ae'
eosio@sthist:~/tmp/fc$ git submodule update --init --recursive
eosio@sthist:~/tmp/fc$ git submodule update --recursive --remote
fatal: Needed a single revision
Unable to find current origin/master revision in submodule path 'secp256k1/upstream'
eosio@sthist:~/tmp/fc$ 

A json-serialized uint64 gets swapped for a string over 0xffffffff, but not when a int64 has a larger than 32 bits value, but is negative.

That's in https://github.com/EOSIO/fc/blob/master/src/io/json.cpp#L614

Example:

      "int64": -2714170076832633519,
      "uint64": "2714170076832633519",