Skip to content
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

Encoder reorders elements, causing incorrect encoding. #43

Closed
aarondl opened this issue Jun 11, 2014 · 4 comments
Closed

Encoder reorders elements, causing incorrect encoding. #43

aarondl opened this issue Jun 11, 2014 · 4 comments

Comments

@aarondl
Copy link

aarondl commented Jun 11, 2014

Expected: toml package to encode data properly.
Actual: During encoding it seems like arrays of maps are given some sort of priority, the ordering of the fields is mixed up, and an incorrect toml representation of the object is output.

Given the following reproduce code:

package main

import (
    "bytes"
    "fmt"

    "github.com/BurntSushi/toml"
)

// The object we are trying to build.
var config = `
[map]
zero = 5
[[map.maparr]]
friend = 5
`

func main() {
    var toEncode = map[string]interface{}{
        "map": map[string]interface{}{
            "zero": 5,
            "maparr": []map[string]interface{}{
                map[string]interface{}{
                    "friend": 5,
                },
            },
        },
    }

    b := &bytes.Buffer{}
    enc := toml.NewEncoder(b)
    if err := enc.Encode(toEncode); err != nil {
        fmt.Println("Error encoding:", err)
        return
    }

    fmt.Println(b.String())
}

The expected output of this is:

[map]
  zero = 5
  [[map.maparr]]
    friend = 5

But the actual output is:

[map]

  [[map.maparr]]
    friend = 5
  zero = 5

Because of the ordering of the fields, the field "zero" belongs to the [[map.maparr]] entry rather to the [map] entry, meaning that the encoded toml is incorrect.

@BurntSushi
Copy link
Owner

Yikes. Reproduced. Working on a fix.

@BurntSushi
Copy link
Owner

All set. I included your code as a regression test. Thank you!

BurntSushi added a commit that referenced this issue Jun 11, 2014
This was actually fixed in commit 44d4af for #43, but this adds a
regression test from #42.
@aarondl
Copy link
Author

aarondl commented Jun 11, 2014

Thank you for the prompt fix. You're doing an excellent job maintaining this library :)

@BurntSushi
Copy link
Owner

Thanks! :)

mitszo pushed a commit to accense/toml that referenced this issue Jul 19, 2016
Array hashes were being considered as normal keys rather than hashes,
which sometimes caused them to come before other keys and therefore
producing incorrect TOML.

This was fixed by being a bit cleaner with type handling. Now tomlTypeOfGo
is a single point of truth about finding the TOML type of a Go value.

This includes a regression test from BurntSushi#43.
mitszo pushed a commit to accense/toml that referenced this issue Jul 19, 2016
This was actually fixed in commit 44d4af for BurntSushi#43, but this adds a
regression test from BurntSushi#42.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants