-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Boolean support inconsistent with the YAML 1.2 spec #214
Comments
Here's the initial motivation for this in Kubernetes, and one possible idea for "fixing" it: |
Signed-off-by: Vinzenz Feenstra <evilissmo@redhat.com>
Signed-off-by: Vinzenz Feenstra <evilissmo@redhat.com>
Signed-off-by: Vinzenz Feenstra <evilissmo@redhat.com>
Signed-off-by: Vinzenz Feenstra <evilissmo@redhat.com>
test case func TestYAsStringKeyInMap(t *testing.T) {
var raw map[interface{}]interface{}
yaml.Unmarshal([]byte(`{x: 10, y: 1}`), &raw)
if _, ok := raw[true]; ok {
t.Errorf("read y as yes instead of 'y', result: %#v", raw)
}
} This is pretty scary stuff... |
Welcome to YAML. |
We cannot touch this in v2 as it will break existing code, but we'll make this change on v3. |
When using yab templates and a key is specified as `"y"` (with quoting), the template parsing ends up converting this to `y`, which then gets unmarshalled as a boolean. The underlying cause is: go-yaml/yaml#214 This is caused by template rendering's use of `yaml.Unmarshal` on all string values which can lose the type. This change restricts the `Unmarshal` to values that were modified as part of the rendering step. It also adds special logic to protect against YAML's boolean handling, by only using the boolean value if strconv.ParseBool would parse the value. This means if a value was rendered as `y`, we would still not treat it as a boolean. Fixes #253
When using yab templates and a key is specified as `"y"` (with quoting), the template parsing ends up converting this to `y`, which then gets unmarshalled as a boolean. The underlying cause is: go-yaml/yaml#214 This is caused by template rendering's use of `yaml.Unmarshal` on all string values which can lose the type. This change restricts the `Unmarshal` to values that were modified as part of the rendering step. It also adds special logic to protect against YAML's boolean handling, by only using the boolean value if strconv.ParseBool would parse the value. This means if a value was rendered as `y`, we would still not treat it as a boolean. Fixes #253
When using yab templates and a key is specified as `"y"` (with quoting), the template parsing ends up converting this to `y`, which then gets unmarshalled as a boolean. The underlying cause is: go-yaml/yaml#214 This is caused by template rendering's use of `yaml.Unmarshal` on all string values which can lose the type. This change restricts the `Unmarshal` to values that were modified as part of the rendering step. It also adds special logic to protect against YAML's boolean handling, by only using the boolean value if strconv.ParseBool would parse the value. This means if a value was rendered as `y`, we would still not treat it as a boolean. Fixes #253
* v/fix-for-issue-91: (40 commits) Add test cases from go-yaml#184 Fix for issue go-yaml#91 Fixes go-yaml#214 - New option to allow setting strict boolean mode Fix for issue go-yaml#144 Always use the pointer mechanism, but only allow recursion per option Applied API changes as suggested in another PR and fixed outstanding problems Removed introduced shadowing bug Make aliases share the same memory address as the anchor ( go-yaml#215 ) Replace LICENSE text with actual license (go-yaml#274) Make tag scanning code slightly cleaner. move embedded struct example into godoc Add UnmarshalStrict returning error if yaml has fields that do not exist in structure correct misspell on yamlh.go fix misspell on emmiterc.go Remove unreachable code to fix go vet (go-yaml#249) Fix dead URL for yaml specification (go-yaml#240) Tighten restrictions on float decoding (go-yaml#171) Fix decode test for Go 1.8 (go-yaml#217) Fix unmarshaler handling of empty strings. new license in the README file (go-yaml#189) ...
To allow better compatibility with YAML 1.1 parsers, when outputting a string that is equal to one of the YAML 1.1 boolean values ("yes", "no", "on", "off", etc), enclose the string in quotes. The string will then parse correctly by either YAML 1.1 or YAML 1.2 parsers. This change does not affect decoding: Bare `yes` and `no` will still be decoded as strings. See: go-yaml#214
@niemeyer I‘ve been bitten by this, too. Could you kindly confirm what the status is with regards to unmarshaling in v3? UPDATE answering myself: https://github.com/go-yaml/yaml/tree/v3 Seems this has been changed and this issue could be closed? |
is this still an issue or can be closed given v3 seems to be already available? |
The YAML 1.1 spec explicitly supported unquoted values like "on/off" or "yes/no" as booleans, so the sample below would translate the third element of
command
tofalse
:However these boolean representations were dropped in 1.2 as one of the major changes in the spec, in favour of just
true
orfalse
to represent booleans.This change is not represented in the go-yaml library, which still supports all previous forms of booleans. I understand it's a claim of the project that it supports most of 1.1 and 1.2, however for larger spec changes like this one, it would be important to have the ability to choose if I want to stick to the 1.2 behavior for booleans, and have the
no
element in the example above translated to the string "no".The text was updated successfully, but these errors were encountered: