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

Bugfix read write compressed did not tell edian #26

Open
wants to merge 2 commits into
base: 2.0.x
Choose a base branch
from
Open

Bugfix read write compressed did not tell edian #26

wants to merge 2 commits into from

Conversation

Kiddinglife
Copy link

@Kiddinglife Kiddinglife commented Nov 25, 2017

low byte is stored in low memory address in little-endian system like windows
but low byte is stored in high memory address in big-endian system.

However, readcompressed() and writecompressed() do not take it into account. It is only working on little-endian system but will not work on big-endian system.

I am happy to discuss this further with someone who disagrees. ^_^

@Luke1410
Copy link
Member

Thanks for the pull request. We'll review it shortly and then merge it into the repository.

Looking at our CLA records, I realize we don't have you listed there yet. Could you quickly review the CLA at https://github.com/SLikeSoft/SLikeNet/blob/master/.github/CONTRIBUTING.md and send us a mail (in case you agree)?

@Kiddinglife
Copy link
Author

@Luke1410 has sent email to you lol.

Copy link
Member

@Luke1410 Luke1410 left a comment

Choose a reason for hiding this comment

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

I stopped the review at this point for the time being. Discussing the issue first in comments.

while ( currentByte > 0 )
// From high byte to low byte, if high byte is a byteMatch then write a 1 bit.
// Otherwise write a 0 bit and then write the remaining bytes
if (!IsNetworkOrder)
Copy link
Member

Choose a reason for hiding this comment

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

missing ()

Copy link
Member

Choose a reason for hiding this comment

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

Also incorrect usage --- Endian swapping is conditionally controlled by the __BITSTREAM_NATIVE_END macro - should call DoEndianSwap() instead

if (inByteArray[currentByte] == byteMatch) // If high byte is byteMatch (0 of 0xff) then it would have the same value shifted
{
Write(true);
currByte--;
Copy link
Member

Choose a reason for hiding this comment

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

should be currentByte I take it
also invalid character used (0x203a) instead of ;

if (inByteArray[currentByte] == byteMatch) // If high byte is byteMatch (0 of 0xff) then it would have the same value shifted
{
Write(true);
currByte++;
Copy link
Member

Choose a reason for hiding this comment

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

cyrrByte -> currentByte?
invalid character instead of simple ;

}

currentByte--;
// make sure we are now on the lowest byte (index highest)
if (currByte < ((size >> 3) - 1))
Copy link
Member

Choose a reason for hiding this comment

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

same here (i.e. currentByte)?

return ;
// make sure we are now on the lowest byte (index 0)
if (currentByte > 0)
return false;
Copy link
Member

Choose a reason for hiding this comment

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

this is a void function - should be simply return?

currentByte--;
// make sure we are now on the lowest byte (index highest)
if (currByte < ((size >> 3) - 1))
return false;
Copy link
Member

Choose a reason for hiding this comment

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

void function - should be return?

// Write the remainder of the data after writing 0
Write(false);
// Write the remainings
WriteBits(src + currentByte, size - (currentByte << 3));
Copy link
Member

Choose a reason for hiding this comment

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

src is undefined --- I guess you meant inByteArray instead?

{
// Read the rest of the bytes

if (ReadBits(inOutByteArray, size - (currentByte << 3) == false)
Copy link
Member

Choose a reason for hiding this comment

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

missing closing )

@Luke1410
Copy link
Member

Luke1410 commented Dec 1, 2017

The two versions of Read/WriteCompressed() you are referencing are private functions in BitStream and explicitly denoted to assume native types (i.e. they are not designed to be called directly on non-native types). Do you have a specific case where this is causing problems for you and/or did you run into some issue with SLikeNet/RakNet where you suspected that the cause would be these two methods not handling endian swapping themselves?

For example see the usage in BitStream::WriteCompressed(const templateType &inTemplateVar). This method calls the ReverseBytes() if required for endian swapping before calling WriteCompressed(unsigned char*, unsigned int, bool). So this looks correct to me. Do you see it otherwise?

@Kiddinglife
Copy link
Author

Kiddinglife commented Dec 3, 2017

Hi @Luke1410
I apologized for that I changed the codes from the github-built-in text editor and they were not complied and tested well from my side before being creating this PR.

Let us go to the point.

You said: So this looks correct to me. Do you see it otherwise?
I say: It looks OK on me too. As you said, public caller methods will handle this correctly. But it is always a good practice to make things 100% correct. BTW, in the term of efficiency, my changes can avoid edian swapping so that it runs faster than before. If that is the case, I may need to make same changes on the private ReadBits() and WriteBits() methods.

Anyway, ignoring my changes and safely closing this PR works no problems on me.
Let me know if it makes sense on you.

Regards,
Jake
^-^

@Luke1410
Copy link
Member

I'll keep this PR open for the time being. There are certainly a few things I'd like to pick up from your suggestion here. If you wanna improve the pull request to a level where it can get merged without causing issues, don't hesitate to do so. Otherwise, as stated before, we'll get back to this one at a later point then.

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.

None yet

2 participants