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

internal/fmtsort: restrict the for-range by len(key) #33277

Closed
wants to merge 1 commit into from

Conversation

@J-CIC
Copy link

J-CIC commented Jul 25, 2019

this modification prevents the fmt panicking with reason index out of range

Fixes #33275

Change-Id: I81fbd1997b8cd1f5f30549eb4640b516105d1dcc

This PR will be imported into Gerrit with the title and first
comment (this text) used to generate the subject and body of
the Gerrit change.

Please ensure you adhere to every item in this list.

More info can be found at https://github.com/golang/go/wiki/CommitMessage

  • The PR title is formatted as follows: net/http: frob the quux before blarfing
    • The package name goes before the colon
    • The part after the colon uses the verb tense + phrase that completes the blank in,
      "This change modifies Go to ___________"
    • Lowercase verb after the colon
    • No trailing period
    • Keep the title as short as possible. ideally under 76 characters or shorter
  • No Markdown
  • The first PR comment (this one) is wrapped at 76 characters, unless it's
    really needed (ASCII art, table, or long link)
  • If there is a corresponding issue, add either Fixes #1234 or Updates #1234
    (the latter if this is not a complete fix) to this comment
  • If referring to a repo other than golang/go you can use the
    owner/repo#issue_number syntax: Fixes golang/tools#1234
  • We do not use Signed-off-by lines in Go. Please don't add them.
    Our Gerrit server & GitHub bots enforce CLA compliance instead.
  • Delete these instructions once you have read and applied them
this modification prevents the fmt panicking with reason index out of range

Fixes #33275

Change-Id: I81fbd1997b8cd1f5f30549eb4640b516105d1dcc
@googlebot

This comment has been minimized.

Copy link

googlebot commented Jul 25, 2019

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

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.


What to do if you already signed the CLA

Individual signers
Corporate signers

ℹ️ Googlers: Go here for more info.

@googlebot googlebot added the cla: no label Jul 25, 2019
@J-CIC

This comment has been minimized.

Copy link
Author

J-CIC commented Jul 25, 2019

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

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

What to do if you already signed the CLA

Individual signers
Corporate signers

ℹ️ Googlers: Go here for more info.

i signed it!

@googlebot

This comment has been minimized.

Copy link

googlebot commented Jul 25, 2019

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

@googlebot googlebot added cla: yes and removed cla: no labels Jul 25, 2019
@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Jul 25, 2019

This PR (HEAD: 57a206b) has been imported to Gerrit for code review.

Please visit https://go-review.googlesource.com/c/go/+/187577 to see it.

Tip: You can toggle comments from me using the comments slash command (e.g. /comments off)
See the Wiki page for more info

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Jul 25, 2019

Message from Gobot Gobot:

Patch Set 1:

Congratulations on opening your first change. Thank you for your contribution!

Next steps:
Within the next week or so, a maintainer will review your change and provide
feedback. See https://golang.org/doc/contribute.html#review for more info and
tips to get your patch through code review.

Most changes in the Go project go through a few rounds of revision. This can be
surprising to people new to the project. The careful, iterative review process
is our way of helping mentor contributors and ensuring that their contributions
have a lasting impact.

During May-July and Nov-Jan the Go project is in a code freeze, during which
little code gets reviewed or merged. If a reviewer responds with a comment like
R=go1.11, it means that this CL will be reviewed as part of the next development
cycle. See https://golang.org/s/release for more details.


Please don’t reply on this GitHub thread. Visit golang.org/cl/187577.
After addressing review feedback, remember to publish your drafts!

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Jul 25, 2019

Message from Martin Möhrmann:

Patch Set 2: Code-Review-1

Thanks but please discuss this on the issue tracker first. This wont fix the inherent problem of a race when concurrently writing to the map while iterating over it. And if there are races of unsynchronised reading and writing then fmtsort does not need to protect against them as other hazards can still appear until there is proper synchronisation.


Please don’t reply on this GitHub thread. Visit golang.org/cl/187577.
After addressing review feedback, remember to publish your drafts!

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Jul 25, 2019

Message from Keith Randall:

Patch Set 2: Code-Review+1

I'm fine with this CL. It can only be triggered by a data race, but if there's something simple we can do to make the error better, we should.
We do something very similar in reflect.MapKeys:

The other options would be to:

  1. panic with a better message if a concurrent write is detected
  2. add a message about the concurrent write to the printed map
    Both would be better than the status quo.

Please don’t reply on this GitHub thread. Visit golang.org/cl/187577.
After addressing review feedback, remember to publish your drafts!

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Jul 25, 2019

Message from Martin Möhrmann:

Patch Set 2:

Patch Set 2: Code-Review+1

I'm fine with this CL. It can only be triggered by a data race, but if there's something simple we can do to make the error better, we should.
We do something very similar in reflect.MapKeys:

The other options would be to:

  1. panic with a better message if a concurrent write is detected
  2. add a message about the concurrent write to the printed map
    Both would be better than the status quo.

I would argue the better improvement here (if the panic should be avoided) would be to use append to add items to the slice as this will both handle more and less items than expected.

We probably should add a comment why this is programmed defensively so it is not optimised away by someone else later.

But I would rather as suggested add some marker/panic here that a race is observed than just avoiding the index panic.


Please don’t reply on this GitHub thread. Visit golang.org/cl/187577.
After addressing review feedback, remember to publish your drafts!

@gopherbot gopherbot force-pushed the golang:master branch 2 times, most recently from 53bd915 to 6139019 Oct 1, 2019
@gopherbot gopherbot force-pushed the golang:master branch from 07b4abd to 19a7490 Oct 9, 2019
@gopherbot gopherbot force-pushed the golang:master branch 10 times, most recently from 4a7ed1f to 0f992b9 Nov 5, 2019
@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Nov 11, 2019

Message from Brad Fitzpatrick:

Patch Set 2:

Patch Set 2:

Patch Set 2: Code-Review+1

I'm fine with this CL. It can only be triggered by a data race, but if there's something simple we can do to make the error better, we should.
We do something very similar in reflect.MapKeys:

The other options would be to:

  1. panic with a better message if a concurrent write is detected
  2. add a message about the concurrent write to the printed map
    Both would be better than the status quo.

I would argue the better improvement here (if the panic should be avoided) would be to use append to add items to the slice as this will both handle more and less items than expected.

We probably should add a comment why this is programmed defensively so it is not optimised away by someone else later.

But I would rather as suggested add some marker/panic here that a race is observed than just avoiding the index panic.

And I'd like to see a test. Is there a valid way that this change can matter that's not a data race? Do we not detect data races when reflect is used?


Please don’t reply on this GitHub thread. Visit golang.org/cl/187577.
After addressing review feedback, remember to publish your drafts!

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Nov 12, 2019

Message from 填佳 姚:

Patch Set 2:

Patch Set 2:

Patch Set 2:

Patch Set 2: Code-Review+1

I'm fine with this CL. It can only be triggered by a data race, but if there's something simple we can do to make the error better, we should.
We do something very similar in reflect.MapKeys:

The other options would be to:

  1. panic with a better message if a concurrent write is detected
  2. add a message about the concurrent write to the printed map
    Both would be better than the status quo.

I would argue the better improvement here (if the panic should be avoided) would be to use append to add items to the slice as this will both handle more and less items than expected.

We probably should add a comment why this is programmed defensively so it is not optimised away by someone else later.

But I would rather as suggested add some marker/panic here that a race is observed than just avoiding the index panic.

And I'd like to see a test. Is there a valid way that this change can matter that's not a data race? Do we not detect data races when reflect is used?

I'm sorry that i forgot to close this change. This issue #33275 has been solved in https://go-review.googlesource.com/c/go/+/191197


Please don’t reply on this GitHub thread. Visit golang.org/cl/187577.
After addressing review feedback, remember to publish your drafts!

@J-CIC J-CIC closed this Nov 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.