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

Dup string value when encoding if it is frozen #117

Merged
merged 1 commit into from
Sep 6, 2013

Conversation

localshred
Copy link
Contributor

String#encode! will raise a RuntimeError if the string instance is frozen.

The normal string setter for required or optional string fields already dups
the incoming string to avoid reference issues. However when the field is a
repeated string field the assigned array is dup'ed, but ruby keeps any
string's frozen state.

The fix is simply to dup any string value when we go to encode if it is
frozen.

String#encode! will raise a RuntimeError if the string instance is
frozen.

The normal string setter for required or optional string fields already
dups the incoming string to avoid reference issues. However when the
field is a repeated string field the assigned array is dup'ed, but ruby
keeps any string's frozen state.

The fix is simply to dup any string value when we go to encode if it is
frozen.
@liveh2o
Copy link
Contributor

liveh2o commented Sep 6, 2013

This looks good to me. :shipit:

Out of curiosity, why use encode! here and force_encoding in bytes?

def encode(value)
# TODO: make replace character configurable?
value = value.dup if value.frozen?
value.encode!(::Protobuf::Field::StringField::ENCODING, :invalid => :replace, :undef => :replace, :replace => "")
value.force_encoding(::Protobuf::Field::BytesField::BYTES_ENCODING)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the purpose of calling force_encoding after the call to encode! ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the better question is why do we encode! it as UTF-8 before it is re-encoded as ASCII-8BIT, since it's encoded as UTF-8 on the receiving end anyway?

@abrandoned
Copy link
Contributor

@localshred :shipit:

@liveh2o @devin-c - force_encoding and encode! do different things, one is for transcoding the other is for sending binary blobs "ASCII-8BIT" across the wire, if you have recommendations then PR and tests will help us all understand

localshred added a commit that referenced this pull request Sep 6, 2013
Dup string value when encoding if it is frozen
@localshred localshred merged commit 0b42aa2 into 2-8-stable Sep 6, 2013
@localshred localshred deleted the bj/fix_frozen_string_encode branch September 6, 2013 16:57
@liveh2o
Copy link
Contributor

liveh2o commented Sep 6, 2013

I don't have any specific recommendations. Just trying to understand the differences...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants