-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
fmt: Precision for strings formatting matches documented neither for %x nor %q #8151
Labels
Milestone
Comments
What is the intended behavior when using precision and %q with strings? In the example above: fmt.Printf("%.1q\n", "hello") // -> "h" The string is truncated to length 1 *before* the quoting. The logic is straightforward in src/pkg/fmt/format.go::fmt_q(): truncate() quote() pad_to_width() currently at line number: https://code.google.com/p/go/source/browse/src/pkg/fmt/format.go#325 If the goal here is a strictly quoted string, since quoting can introduce escape sequences «A\nB» → «A\\\nB» the library can't blindly trim the result and surround it with quotes: "A\\\" is invalid, and likely dangerous. If the current behavior (or compromise) is the intended one, maybe mention it in the docs (an exception applicable only to these “quoting” verbs)? It took me some time to reason about this and figure out why the printed string is longer than the precision I'm giving. I'm leaning towards calling it a bug because, as a user of the fmt package, I expect .precision to always work the same, without me reasoning about the package's internals. At least that's what I expected in the absence of disclaimers. |
Owner changed to @robpike. Status changed to Accepted. |
CL https://golang.org/cl/144540044 mentions this issue. |
This issue was closed by revision 54111a5. Status changed to Fixed. |
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jun 25, 2018
…slices Previous behavior was undocumented and inconsistent. Now it is documented and consistent and measures the input size, since that makes more sense when talking about %q and %x. For %s the change has no effect. Fixes golang#8151. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/144540044
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jun 26, 2018
…slices Previous behavior was undocumented and inconsistent. Now it is documented and consistent and measures the input size, since that makes more sense when talking about %q and %x. For %s the change has no effect. Fixes golang#8151. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/144540044
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jul 9, 2018
…slices Previous behavior was undocumented and inconsistent. Now it is documented and consistent and measures the input size, since that makes more sense when talking about %q and %x. For %s the change has no effect. Fixes golang#8151. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/144540044
wheatman
pushed a commit
to wheatman/go-akaros
that referenced
this issue
Jul 30, 2018
…slices Previous behavior was undocumented and inconsistent. Now it is documented and consistent and measures the input size, since that makes more sense when talking about %q and %x. For %s the change has no effect. Fixes golang#8151. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/144540044
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: