Skip to content
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

Added protection to collection sizes with FC_ASSERTs #55

Closed
wants to merge 1 commit into from

Conversation

3 participants
@jmjatlanta
Copy link

commented Jun 2, 2018

This is a PR for the bitshares-fc side of issue bitshares/bitshares-core#995

The #define was split in two to make these FC_ASSERTs easier.

Please note that these were not added to the pack/unpack methods for bip::vector<T,A>. I believe they should be, but want to wait for confirmation from others.

@abitmore

This comment has been minimized.

Copy link
Member

commented Jun 2, 2018

IIRC we're not using bip::vector<T,A> in bitshare-core.

@pmconrad
Copy link

left a comment

I'd say we treat this like a hardfork change and postpone it until next regular hf.

value.clear();
FC_ASSERT( size.value*sizeof(T) < MAX_ARRAY_ALLOC_SIZE );

This comment has been minimized.

Copy link
@pmconrad

pmconrad Jun 5, 2018

This change is dangerous.
In the core, T is often an object_id_type with sizeof(T) = 8(?). MAX_ARRAY_ALLOC_SIZE/8 > MAX_NUM_ARRAY_ELEMENTS, so with this change we lose compatibility.
OTOH T is sometimes a public_key_type with sizeof(T) = 33(?). MAX_ARRAY_ALLOC_SIZE < MAX_NUM_ARRAY_ELEMENTS*33, which means we lose compatibility in the other direction.

(Note that the old check is stupid in general because sizeof(T) does not necessarily correlate with the actual storage size of a pack'd T.)

This comment has been minimized.

Copy link
@jmjatlanta

jmjatlanta Jun 6, 2018

Author

I'd like to build a test to prove this, and I'd like to use an item where its size is not equal to its packed size. I haven't thought the process all the way through, but I'm thinking of a flat set of varint. Will that work? I will use small value varints for a baseline, and large value varints for the other way. I realize this does nothing for compatibility, but I believe it would help design asserts that actually check for what we want to prevent. Your thoughts please, @pmconrad.

This comment has been minimized.

Copy link
@pmconrad

pmconrad Jun 6, 2018

If you want to be realistic use object_id_type with instance values < 128.
Another example would be strings - sizeof(string) != string length.

value.clear();
FC_ASSERT( size.value*(sizeof(K)+sizeof(V)) < MAX_ARRAY_ALLOC_SIZE );

This comment has been minimized.

Copy link
@pmconrad

pmconrad Jun 5, 2018

Dangerous, see above.

@jmjatlanta

This comment has been minimized.

Copy link
Author

commented Jan 16, 2019

With PR #100 this fix is not needed, and probably more dangerous to consensus than leaving things alone. I will close this PR and create another that removes FC_ASSERTs that are unnecessary due to PR #100

@jmjatlanta jmjatlanta closed this Jan 16, 2019

@jmjatlanta jmjatlanta deleted the jmj_issue_995 branch Jan 22, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.