-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Link compression added to rippled-example.cfg #4739
Conversation
If/when the default changes, this will be updated at that time to reflect the updated default. |
@intelliot Should I wait before merging this PR to see if #4387 gets merged soon? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
No, I don't think there's a need to wait. This is accurate as of |
Address a stack-use-after-scope issue when using rvalues with `soci::use`. Replace rvalues with lvalues to ensure the scope extends beyond the end of the expression. The issue arises from `soci` taking a reference to the rvalue without copying its value or extending its lifetime. `soci` references rvalues in `soci::use_container` and then the address in `soci_use_type`. For types like `int`, memory access post-lifetime is unlikely to cause issues. However, for `std::string`, the backing heap memory can be freed and potentially reused, leading to a potential segmentation fault. This was detected on x86_64 using clang-15 with asan. asan confirms resolution of the issue. Fix XRPLF#4675
Make transactions and pseudo-transactions share the same commonFields again. This regularizes the code in a nice way. While this technically allows pseudo-transactions to have a TicketSequence field, pseudo-transactions are only ever constructed by code paths that don't add such a field, so this is not a transaction processing change. It may be possible to add a separate check to ensure TicketSequence (and other fields that don't make sense on pseudo-transactions) are never added to pseudo-transactions, but that should not be necessary. (TicketSequence is not the only common field that can not and does not appear in pseudo-transactions.) Note: TicketSequence is already documented as a common field. Related: XRPLF#4637 Fix XRPLF#4714
When a new transactor is added, there are several places in applySteps that need to be modified. This patch refactors the code so only one function needs to be modified.
…F#4721) Context: The `DisallowIncoming` amendment provides an option to block incoming trust lines from reaching your account. The asfDisallowIncomingTrustline AccountSet Flag, when enabled, prevents any incoming trust line from being created. However, it was too restrictive: it would block an issuer from authorizing a trust line, even if the trust line already exists. Consider: 1. Issuer sets asfRequireAuth on their account. 2. User sets asfDisallowIncomingTrustline on their account. 3. User submits tx to SetTrust to Issuer. At this point, without `fixDisallowIncomingV1` active, the issuer would not be able to authorize the trust line. The `fixDisallowIncomingV1` amendment, once activated, allows an issuer to authorize a trust line even after the user sets the asfDisallowIncomingTrustline flag, as long as the trust line already exists.
…to link-compression
Closing this one and opening a similar one to have clear verified commits required to merge: |
High Level Overview of Change
This PR adds the link compression setting to the rippled-example.cfg file in the second section "Peer Protocol".
It solves #4656
Context of Change
Type of Change
Future Tasks