encoding/yaml: unable to parse number value in YAML with leading zero

[jesselang]

What version of CUE are you using (cue version)?

$ cue version
cue version v0.6.0

go version go1.20.6
      -buildmode exe
       -compiler gc
       -trimpath true
     CGO_ENABLED 0
          GOARCH amd64
            GOOS darwin
         GOAMD64 v1

Does this issue reproduce with the latest stable release?

Yes. v0.6.0 appears to be the latest release.

What did you do?

I'm trying to parse a YAML value that contains a number with a leading zero.

exec cue vet a.cue a.yaml

-- a.cue --
account: uint
-- a.yaml --
# number without leading zero parses correctly.
account: 1123456778901
# number with leading zero results is parsing error.
account: 0123456778901

What did you expect to see?

The number is parsed. Perhaps this is challenging because some parsers parse the value as base 8, others might strip the leading zero, etc.

What did you see instead?

> exec cue vet a.cue a.yaml
[stderr]
account: parse error: illegal integer number "0123456778901":
    ./a.yaml:4:11
[exit status 1]
FAIL: /var/folders/yd/6gthgn951hlbr9xmst_p_bb1smsz_1/T/testscript715473880/leading-zero.txtar/script.txtar:1: unexpected command failure
error running leading-zero.txtar in /var/folders/yd/6gthgn951hlbr9xmst_p_bb1smsz_1/T/testscript715473880/leading-zero.txtar

[mvdan]

This appears to be a bug in upstream go-yaml; see go-yaml/yaml#157. See @rogpeppe's replies in that thread, in particular - each YAML implementation seems to solve this ambiguity a different way, since 0129 could be interpreted as a valid base-10 integer, an invalid base-8 integer, or a valid unquoted string.

It seems to me like the YAML v1.2 spec is unambiguous in that 0o is the octal prefix, and not simply 0, so perhaps go-yaml should decode 0129 as a base-10 integer. However, its README says:

Octals encode and decode as 0777 per YAML 1.1, rather than 0o777 as specified in YAML 1.2, because most parsers still use the old format. Octals in the 0o777 format are supported though, so new files work.

Either way, this needs to be fixed upstream - then we can pick up the fix.

[jesselang]

Thanks @mvdan. I was able to use go-yaml to decode the value as a string, while CUE will not. Here's a reproducer that I'd love your feedback on. Thanks!

go mod tidy
go run .
exec cue vet a.cue a.yaml

-- a.cue --
account: string
-- a.yaml --
# number without leading zero parses correctly.
account: 1123456778901
# number with leading zero results in parsing error.
account: 0123456778901
-- go.mod --
module b

go 1.20

require gopkg.in/yaml.v3 v3.0.1
-- b.yaml --
# number with leading zero loads fine with go-yaml
account: 0123456778901
-- b.go --
package main

import (
  "os"
  "fmt"

  "gopkg.in/yaml.v3"
)

type data struct {
    Account string `yaml:"account"`
}

func main() {
    f, err := os.Open("b.yaml")
    if err != nil {
        panic(err)
    }
    defer f.Close()

    dec := yaml.NewDecoder(f)

    var d data
    if err = dec.Decode(&d); err != nil {
        panic(err)
    }

    fmt.Printf("%s\n", d.Account)
}

Output:

> go mod tidy
[stderr]
go: downloading gopkg.in/yaml.v3 v3.0.1
go: downloading gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405

> go run .
[stdout]
0123456778901

> exec cue vet a.cue a.yaml
[stderr]
account: parse error: illegal integer number "0123456778901":
    ./a.yaml:4:11
[exit status 1]
FAIL: /var/folders/yd/6gthgn951hlbr9xmst_p_bb1smsz_1/T/testscript3557253812/leading-zero.txtar/script.txtar:3: unexpected command failure
error running leading-zero.txtar in /var/folders/yd/6gthgn951hlbr9xmst_p_bb1smsz_1/T/testscript3557253812/leading-zero.txtar

[mvdan]

Thank you @jesselang, indeed it seems like the error comes from CUE and not go-yaml, and we can tweak our YAML decoding logic to not produce an invalid/illegal CUE literal. I'll send a fix shortly.