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.
fmt says "For strings, precision is the maximum number of characters to output, truncating if necessary." package main import "fmt" func main() { fmt.Printf("%.1x\n", "hello") // -> 68656c6c6f fmt.Printf("%.1q\n", "hello") // -> "h" } Which is 10 characters output for the first, and 3 characters output for the second. Both of these may be working as intended, but I think the fmt module docs need fixing/clarifying if so.The text was updated successfully, but these errors were encountered: