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

fixed issue #131 by improving the Parse function in uuid.go + unit tests #132

Closed
wants to merge 1 commit into from
Closed

fixed issue #131 by improving the Parse function in uuid.go + unit tests #132

wants to merge 1 commit into from

Conversation

theghostmac
Copy link

I attempted to solve the most recently opened error here, but it's sensitive as other functions and test functions rely on the original implementation.

If my improvement on the Parse() function is correct, then both TestNullUUIDMarshalJSON and TestJSONUnmarshal needs to either be rewritten or fed with new data.

Also, two test data failed, as I mentioned.

@theghostmac theghostmac requested a review from a team as a code owner October 3, 2023 22:10
@google-cla
Copy link

google-cla bot commented Oct 3, 2023

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

Copy link
Collaborator

@bormanp bormanp left a comment

Choose a reason for hiding this comment

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

I am sorry, but code does not address issue #131 which only references the case when 38 (36+2) bytes are passed in.

This code, if it worked, would also have an adverse impact on the speed of Parse. The speed of parsing is very important to some users of this package.

@@ -66,6 +66,10 @@ func Parse(s string) (UUID, error) {
switch len(s) {
// xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
case 36:
// Ensure proper dash placement
Copy link
Collaborator

Choose a reason for hiding this comment

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

I do not see any benefit in these changes. Checking for "-" is already done on lines 94-89.

for i := range uuid {
uuid[i], ok = xtob(s[i*2], s[i*2+1])
if !ok {
uuid[i] = s[i]
Copy link
Collaborator

Choose a reason for hiding this comment

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

This code ignores half of the UUID and will provide the wrong answer.

It is possible that the existing for loop could be rewritten as

for i := 0; i < 32; i += 2 {
    uuid[i>>1], ok = xtob(s[i], s[i+1])
    ...

for i, x := range [16]int{
0, 2, 4, 6,
9, 11,
14, 16,
19, 21,
24, 26, 28, 30, 32, 34,
} {
v, ok := xtob(s[x], s[x+1])
if !ok {
if !isValidHexChar(s[x]) || !isValidHexChar(s[x+1]) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This block is both slower and produces the wrong results. both s[x] and s[x+1] are required to determine the value of uuid byte i. The xtob function, which handles this properly is very optimized.

@theghostmac
Copy link
Author

Okay, let me remove the PR. Thanks.

@theghostmac theghostmac closed this Oct 3, 2023
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.

2 participants