Given the following hjson:

{
    foo: [
        bar,
        baz
    ]
}

I would expect the output to be:

{
  "foo": [
    "bar",
    "baz"
  ]
}

But instead I get:

{
  "foo": [
    "bar,",
    "baz"
  ]
}

To get the expected output, I need to quote the list item or not use a trailing comma in lists.

How to unmashal to struct not map string interface

Current implementation decode integers into float64 values.
This introduces a limitation in the integer values magnitude that can be handled by the hjson library.

How to newLine on hexDump field not all filed new line fmt?

Unmarshal panics with nil

Playground link:
https://play.golang.org/p/a70hlsJK2-9

This was found by fuzzing with go-fuzz

It would be very useful to be able to marshal (encode) a struct and embed comments in the resulting hjson.

I was wondering if there is a way to Unmarshal hjson to a go struct but preserve arbitrary comments on the source json. For example if my hjson looks like this:

{
// random comment
  "foo": "bar",
  "foo2": "bar2"
}

I want to preserve a comment on a random line in the json, unmarshal the file to a go struct, change bar to bar-modified.
Then marshal and save to file.

Is it possible to preserve comments when you don't know which line might have a comment on it?

The structs are left as their zero values. The errors are ignored in the example code. If I log the errors, it says reflect.Set: value of type map[string]interface {} is not assignable to type main.Sample.

my Go version: go1.20.7 linux/amd64

test code:

func TestEncodeMarshalAndUnmarshal(t *testing.T) {
	type t_obj struct{
		F string
	}
	const testS = "0\r'"
	input := t_obj{
		F: "0\r'",
	}
	buf, err := Marshal(input)
	if err != nil {
		t.Fatal(err)
	}
	var obj2 t_obj
	err = Unmarshal(buf,&obj2)
	if err != nil {
		t.Fatal(err)
	}
	if obj2.F!=testS{
		t.Error("fail ["+hex.Dump([]byte(obj2.F))+`]`)
	}
}

See hjson/hjson#74

package main

import (
	"github.com/hjson/hjson-go"
	"fmt"
)

func main(){
	type Node struct{
		self *Node
	}
	var obj Node
	obj.self = &obj
	b,err:=hjson.Marshal(obj)
	if err!=nil{
		panic(err)
	}
	fmt.Println(string(b))
}

It should ignore all not export field.

When producing hjson out of a struct with in a struct that has comments on the fields, there's a bunch of additional trailing spaces in there. See the attached picture for an example, which I created with this piece of code:

package main

import (
	"github.com/hjson/hjson-go"
	"fmt"
)

type Config struct {
	InnerConfig	InnerConfig	`comment:"This is a\ncomment with some\nnewlines in between."`
}

type InnerConfig struct {
	ValueOne	string	`comment:"This is a\ncomment with some\nnewlines in between."`
	ValueTwo	bool	`comment:"This is a\ncomment with some\nnewlines in between."`
}

func main() {
	cfg := Config{}
	cfg.InnerConfig = InnerConfig{}
	cfg.InnerConfig.ValueOne = "test"
	cfg.InnerConfig.ValueTwo = true

	hjson, _ := hjson.Marshal(cfg)

	fmt.Println(string(hjson))
}

Minor documentation inconsistency?

Readme:

String pointer destinations are treated the same as string destinations, so you cannot set a string pointer to nil by writing null in an Hjson file. Writing null in an Hjson file would result in the string "null" being stored in the destination string pointer.

4.4.0 Release notes

Slightly changed behavior for unmarshalling "null" into a string destination: if the value is "null" without quotes and the destination is a pointer then the pointer is set to nil instead of a pointer to the string "null", even if the destination is a pointer to a string or a type that implements UnmarshalText().

Shouldn't a be used as input instead of c, since c must be nil?

Playground link:

https://play.golang.org/p/TsyJyU4XKEE

This was found by fuzzing with go-fuzz

When fetching this package, I get the following error:

go get github.com/hjson/[email protected]
go: github.com/hjson/[email protected]: invalid version: module contains a go.mod file, so module path must match major version ("github.com/hjson/hjson-go/v3")

It looks like that, according to golang/go#35732, this can be fixed by modifying the path here:

When using hjson -j without a file, hjson gets stuck.
An exit code 1 would be preferable then.
I stumbled across this, when I wanted to write a systemctl system service that parses a hjson file, but the environment variable was not set (as it the defualt in system services) and then the script was stuck there forever. Only after inspecting the tree with htop I could see that hjson is executed forever.

i'm trying to remain compatible with a python implementation of the hjson format, and need the keys to remain in order.

this is preventing me from being able to utilize this tool due to it's key sorting in the output.

i understand that in go, a map is not guaranteed an order, but the keys could be imported into a list on read and exported back out in the same order that they appear, i.e. to simulate a python 'ordered dictionary.

this doesn't need to be the default behaviour since often the sorting is desired, but as a compatibility option or flag to 'preserve key order' would be ideal.

thank you for considering.

The Unmarshal function will always return an error when it tries to parse a list of object, whose internal property type is an pointer which implements UnmarshalText interface and the value is null.

type Foo struct {
	Bar *Bar
}

type Bar struct {
}

func (b *Bar) UnmarshalText(text []byte) error {
	return nil
}

func TestHjson_NullPropertyUnmarshalTextObjectInList(t *testing.T) {
	s := []byte("[{\"Bar\":null}]")

	foos := []*Foo{}
	err := hjson.Unmarshal(s, &foos)

	assert.ErrorContains(t, err, "End of input while parsing an object (did you forget a closing '}'?)")
}

maybe you can add a homebrew formula?

Hello,

Sorry if the answer is too obvious as I'm a beginner in Go, but is there an easy way to do this with hjson and hjson-go without all the assertions as presented in the doc?

Thanks

support marshal net.ParseIP(127.0.0.1) to 127.0.0.1

current result:

[
  0
  0
  0
  0
  0
  0
  0
  0
  0
  0
  255
  255
  127
  0
  0
  1
]

support encoding.TextMarshaler should fix this bug.