xdrpp / xdrpp Goto Github PK

Home Page: http://xdrpp.github.io/xdrpp/index.html

License: Other

Shell 0.15% C 5.65% C++ 75.08% Yacc 2.88% Makefile 1.44% M4 10.20% RPC 4.60%

c-plus-plus rfc4506 rfc5531 rpc xdr

xdrpp's Introduction

# To build from a release that already has a configure file:

    ./configure
    make

# Documentation

Documentation is available on-line at the project home page,
<http://xdrpp.github.io/xdrpp/>.

To generate and view a local copy of the documentation, run:

    doxygen
    xdg-open doc/html/index.html

Finally, if you have neither an Internet connection nor doxygen, a
copy of the documentation can also be found in the `gh-pages` branch
of the repository, which you can access as:

    git archive --prefix=www/ origin/gh-pages | bsdtar xf -
    xdg-open www/index.html

# Building

To build after a git checkout that doesn't have ./configure, run:

    ./autogen.sh
    ./configure
    make

As is traditional, the software can be installed with

    make install

# To enable the cereal test

You need cereal in the top directory (before running `./configure`),
which you can get by running:

    git clone https://github.com/USCiLab/cereal.git

(Or make cereal a symlink to an already checked out copy.)

# To enable autocheck tests

You need autocheck in the top directory.  Run:

    git clone https://github.com/thejohnfreeman/autocheck.git

(Or make autocheck a symlink to an already checked out copy.)

xdrpp's People

Contributors

Stargazers

Watchers

Forkers

monsieurnicolas graydon charwliu codeck blackbeetlehub sohanlaxmicoin geod24 erd-27 mattpearce jonjove hidenori-shinohara gramseyer mcdmaster

xdrpp's Issues

generated code is suboptimal and trips static analysis

This is an old issue that I forgot to open - not a huge thing but if somebody wants to fix it...

Some generated code looks like this:

  static Constexpr int _xdr_field_number(_xdr_case_type which) {
    return which == CREATE_ACCOUNT_SUCCESS ? 0
      : 0;
  }

which causes the code to be flagged by static analyzers as it doesn't really do anything useful (example above is really return 0).

This causes noise in those tools, so it would be nice to not generate this kind of code in the first place.

xdrc should support recursive types

This is an issue we've run into on several occasions, but in order to generate the most optimal XDR for https://github.com/stellar/rs-soroban-env we need to support this.

It is possible to create xdr_vector<N> bigger than N

Simple example from stellar-core:

Signature out(200, 0);

Signature has limit of 64 but it is not checked in this constructor, only on resize/append

Seems like xstring solves it by its own constructors:

template<typename...Args> xstring(Args&&...args)
: string(std::forward(args)...) { validate(); }

consider moving to `enum class` when possible

C++ 11 can make enums type safe.

Recently we spotted a mistake in our code base (luckily no impact):
stellar/stellar-core@9d832c5#diff-8449113f1d4140770b4c3361b6997826L252

Basically, the XDR is defined as:

enum PublicKeyType
{
    PUBLIC_KEY_TYPE_ED25519 = KEY_TYPE_ED25519
};

enum SignerKeyType
{
    SIGNER_KEY_TYPE_ED25519 = KEY_TYPE_ED25519,
    SIGNER_KEY_TYPE_PRE_AUTH_TX = KEY_TYPE_PRE_AUTH_TX,
    SIGNER_KEY_TYPE_HASH_X = KEY_TYPE_HASH_X
};

union PublicKey switch (PublicKeyType type)
{
case PUBLIC_KEY_TYPE_ED25519:
    uint256 ed25519;
};

and the resulting generated c++ uses old style enums:

enum PublicKeyType : std::int32_t { ...

It would be nice to instead generate enums as:

enum class PublicKeyType : std::int32_t { ...

A few implications:

we would have to always specify the enum type in code (so referencing naked enum values would stop working), this is acceptable.
when using a value in generated code, it's probably fine to perform a blanket cast to std::int32_t, so that enums defined like the one above will "just work", I think by doing something like:

enum class PublicKeyType : std::int32_t {
  PUBLIC_KEY_TYPE_ED25519 = (std::int32_t)CryptoKeyType::KEY_TYPE_ED25519,
};
``
* as XDR doesn't support enum namespacing, to ensure compliance with the xdr spec, the xdr compiler would still have to keep track of enums (and enum values) in a global map
* we would get type safety when performing comparisons between enum values (or require people to explicitly cast)

Thoughts?

Why does xdr_traits<...>::enum_values() return std::vector<int32>?

I've come across this a couple of times, most recently in stellar/stellar-core#3031. Is there a reason that this can't return std::vector<T> where T is the enum? If this would break too many things, could we add a different function that does this?

xdrc Accepts Enum with Trailing Comma

Originally observed by @overcat in stellar/stellar-core#2954.

xdrc should either

fully comply with RFC-4506 and reject this case
omit a warning to inform the user that there is an issue.

I prefer the first option if possible.

Using enum class for enums in .h files

What about adding a little extra type safety by changing generated code from enum [name] to enum class [name]?

Should be simple to implement (gen_hh.cc:256 maybe?). I can do it if it makes sense to you.

In enums negative integer used as error value but can be valid

Here's an example of generated code for enum:

  static Constexpr int _xdr_field_number(_xdr_case_type which) {
    return which == KEY_TYPE_ED25519 ? 1
      : -1;
  }

However, according to XDR spec enums have the same representation as signed integers. That means that they can have a negative values.

message_t::size does not report used buffer size

The xdr::msg_ptr buffer size is always reported as actual (used) buffer size even if only a fraction of it is really used. Let's say you have a structure like

struct mymessage {
    string channel<24>;
    uint32_t cycle_id;
    int32_t force;
    uint32_t distance;
};

compiled by xdrc in the relevant C++ code, plus an
xdr::msg_ptr buf {xdr::message_t::alloc(36)};

The message size accounts for the maximum string length, but the actual string length may be less than the defined maximum. In any case the serialized message is a fixed 36 + 4 header bytes, thus wasting space. Am I missing something or this is the intended behaviour?
This causes, i.e. problems with Python xdrlib, besides the obvious efficiency/performance issues.

xdrc successfully compiles with int32_t type

This change successfully compiled even though the type of liquidityPoolUseCount was int32_t instead of int32. Ideally, xdrc would fail to compile here.

Free on not malloced address

xdrc may suffer from a free on not malloced address error on some crafted xdr files when calling destructor rpc_proc::~rpc_proc. It will abort with error message like free(): invalid pointer.

When compiled with address sanitizer, it reports:

free_xdrc_internal.h:124_1.x:2: syntax error
=================================================================
==15829==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x6100000000f0 in thread T0
    #0 0x5174f8 in operator delete(void*) (/home/hongxu/FOT/xdrpp-clang/install/bin/xdrc+0x5174f8)
    #1 0x55c1a2 in rpc_proc::~rpc_proc() /home/hongxu/FOT/xdrpp-clang/./xdrc/xdrc_internal.h:124:8
    #2 0x55c174 in void std::_Destroy<rpc_proc>(rpc_proc*) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_construct.h:98:19
    #3 0x55c13e in void std::_Destroy_aux<false>::__destroy<rpc_proc*>(rpc_proc*, rpc_proc*) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_construct.h:108:6
    #4 0x55af8c in void std::_Destroy<rpc_proc*>(rpc_proc*, rpc_proc*) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_construct.h:136:7
    #5 0x55c460 in void std::_Destroy<rpc_proc*, rpc_proc>(rpc_proc*, rpc_proc*, std::allocator<rpc_proc>&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_construct.h:206:7
    #6 0x55c3ef in std::vector<rpc_proc, std::allocator<rpc_proc> >::~vector() /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_vector.h:567:2
    #7 0x55c354 in vec<rpc_proc>::~vec() /home/hongxu/FOT/xdrpp-clang/./xdrc/xdrc_internal.h:28:29
    #8 0x55c322 in rpc_vers::~rpc_vers() /home/hongxu/FOT/xdrpp-clang/./xdrc/xdrc_internal.h:131:8
    #9 0x55c2f4 in void std::_Destroy<rpc_vers>(rpc_vers*) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_construct.h:98:19
    #10 0x55c2be in void std::_Destroy_aux<false>::__destroy<rpc_vers*>(rpc_vers*, rpc_vers*) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_construct.h:108:6
    #11 0x559b6c in void std::_Destroy<rpc_vers*>(rpc_vers*, rpc_vers*) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_construct.h:136:7
    #12 0x55ccf0 in void std::_Destroy<rpc_vers*, rpc_vers>(rpc_vers*, rpc_vers*, std::allocator<rpc_vers>&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_construct.h:206:7
    #13 0x55cc7f in std::vector<rpc_vers, std::allocator<rpc_vers> >::~vector() /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_vector.h:567:2
    #14 0x55cbe4 in vec<rpc_vers>::~vec() /home/hongxu/FOT/xdrpp-clang/./xdrc/xdrc_internal.h:28:29
    #15 0x55cbb2 in rpc_program::~rpc_program() /home/hongxu/FOT/xdrpp-clang/./xdrc/xdrc_internal.h:137:8
    #16 0x55850c in union_entry<rpc_program>::~union_entry() /home/hongxu/FOT/xdrpp-clang/xdrc/union.h:124:28
    #17 0x5534cd in union_entry_base::destroy() volatile /home/hongxu/FOT/xdrpp-clang/xdrc/union.h:111:35
    #18 0x55f834 in rpc_sym::~rpc_sym() /home/hongxu/FOT/xdrpp-clang/./xdrc/xdrc_internal.h:160:23
    #19 0x55f804 in void std::_Destroy<rpc_sym>(rpc_sym*) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_construct.h:98:19
    #20 0x55f7ce in void std::_Destroy_aux<false>::__destroy<rpc_sym*>(rpc_sym*, rpc_sym*) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_construct.h:108:6
    #21 0x55f78c in void std::_Destroy<rpc_sym*>(rpc_sym*, rpc_sym*) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_construct.h:136:7
    #22 0x55f640 in void std::_Destroy<rpc_sym*, rpc_sym>(rpc_sym*, rpc_sym*, std::allocator<rpc_sym>&) /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_construct.h:206:7
    #23 0x55f5cf in std::vector<rpc_sym, std::allocator<rpc_sym> >::~vector() /usr/bin/../lib/gcc/x86_64-linux-gnu/8.1.0/../../../../include/c++/8.1.0/bits/stl_vector.h:567:2
    #24 0x553184 in vec<rpc_sym>::~vec() /home/hongxu/FOT/xdrpp-clang/./xdrc/xdrc_internal.h:28:29
    #25 0x7f24c4709040 in __run_exit_handlers /build/glibc-OTsEL5/glibc-2.27/stdlib/exit.c:108
    #26 0x7f24c4709139 in exit /build/glibc-OTsEL5/glibc-2.27/stdlib/exit.c:139
    #27 0x544fbb in yyerror(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) /home/hongxu/FOT/xdrpp-clang/xdrc/scan.ll:88:3
    #28 0x54f07a in yyparse() /home/hongxu/FOT/xdrpp-clang/xdrc/parse.cc:1976:7
    #29 0x51c875 in main /home/hongxu/FOT/xdrpp-clang/xdrc/xdrc.cc:204:3
    #30 0x7f24c46e7b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
    #31 0x41e269 in _start (/home/hongxu/FOT/xdrpp-clang/install/bin/xdrc+0x41e269)

0x6100000000f0 is located 176 bytes inside of 192-byte region [0x610000000040,0x610000000100)
allocated by thread T0 here:
    #0 0x516780 in operator new(unsigned long) (/home/hongxu/FOT/xdrpp-clang/install/bin/xdrc+0x516780)

SUMMARY: AddressSanitizer: bad-free (/home/hongxu/FOT/xdrpp-clang/install/bin/xdrc+0x5174f8) in operator delete(void*)
==15829==ABORTING

A tiny POC file is like (others are available here):

program G{version R{o O(d)=7;p P(b)=0;}=0;