-
Notifications
You must be signed in to change notification settings - Fork 87
funcr: Escape strings when they are not known-safe. #113
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
Conversation
funcr/funcr.go
Outdated
| buf.WriteByte(',') | ||
| } | ||
| // JSON only does string keys. | ||
| // prettyWithFlags will produce already-escaped values |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that mean that
Lines 410 to 415 in 3608a4b
| case reflect.String: | |
| if flags&flagRawString > 0 { | |
| return v.String() | |
| } | |
| // This is empirically faster than strings.Builder. | |
| return `"` + v.String() + `"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also unsure about
Lines 504 to 509 in 3608a4b
| // prettyWithFlags will produce already-escaped values | |
| buf.WriteByte('"') | |
| buf.WriteString(f.prettyWithFlags(it.Key().Interface(), flagRawString)) | |
| buf.WriteByte('"') | |
| buf.WriteByte(':') | |
| buf.WriteString(f.pretty(it.Value().Interface())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
String members work, probably because case reflect.String: is never reached due to the case string: above. Should we remove the dead code?
Map values are also fine, but map keys are not. Here's a test case:
diff --git a/funcr/funcr_test.go b/funcr/funcr_test.go
index 18ccb31..e7dedde 100644
--- a/funcr/funcr_test.go
+++ b/funcr/funcr_test.go
@@ -504,6 +504,17 @@ func TestRender(t *testing.T) {
args: makeKV("bool\u00a0", true), // escaped
expectKV: `""1""=1 "\tstr\n"="ABC" "bool\u00a0"=true`,
expectJSON: `{""1"":1,"\tstr\n":"ABC","bool\u00a0":true}`,
+ }, {
+ name: "escape reflection",
+ args: makeKV("struct", struct {
+ Map map[string]string
+ String string
+ }{
+ Map: map[string]string{`"quoted map key"`: `"quoted map value"`},
+ String: `"quoted string value"`,
+ }),
+ expectKV: `"struct"={"Map":{"\"quoted map key\"":"\"quoted map value\""},"String":"\"quoted string value\""}`,
+ expectJSON: `{"struct":{"Map":{"\"quoted map key\"":"\"quoted map value\""},"String":"\"quoted string value\""}}`,
}, {
name: "missing value",
builtins: makeKV("builtin"),
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the code emit non-string map keys in those cases where JSON supports that? Right now it always seems to render as string.
Here's a test case for integer keys:
diff --git a/funcr/funcr_test.go b/funcr/funcr_test.go
index 18ccb31..122a72c 100644
--- a/funcr/funcr_test.go
+++ b/funcr/funcr_test.go
@@ -518,6 +518,11 @@ func TestRender(t *testing.T) {
args: makeKV(789, "val"),
expectKV: `"<non-string-key: 123>"="val" "<non-string-key: 456>"="val" "<non-string-key: 789>"="val"`,
expectJSON: `{"<non-string-key: 123>":"val","<non-string-key: 456>":"val","<non-string-key: 789>":"val"}`,
+ }, {
+ name: "int map keys",
+ values: makeKV("map", map[int]string{1: "first"}),
+ expectKV: `"map"={1:"first"}`,
+ expectJSON: `{"map":{1:"first"}}`,
}, {
name: "non-string key struct",
builtins: makeKV(struct { // will not be escaped, but should never happen
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I may have misremembered. Looks like JSON doesn't support non-string keys. So the current behavior is correct, except for quoting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed. In several places! PTAL
|
Will look at it again to see if there are any further micro-optimizations to be had - nothing obvious... |
|
Oh, I found one. Updating the PR comment. |
|
PTAL |
|
Looks much better. But I am still wondering how well arbitrary maps are resp. should be supported. My two cents:
With that in mind, here are some additional test cases. They document the current behavior even if that is broken: |
|
Good test cases! Cleaned up even more. Also added TextMarshaler support. PTAL :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm running out of ideas for breaking this 😁 Good job, let's merge it.
before:
after:
Fixes #112