cbor serialize for float not match for CBOR specification

[atenjin]

I use rust to impl IPFS, and now, I meet a problem in CBOR serialize.

this project use cbor serialize/deserialize lib is github.com/polydawn/refmt
but I think this CBOR implementation not match to specification for float number.

in specification: https://tools.ietf.org/html/rfc7049#section-2.3
different float would have different serialize.
For example for float16, float32, float64, etc...

but this lib would not recognition different float, it handle all float number for float64 type.
e.g.

func TestFloat(t *testing.T) {
	m := 1.5  // this float is float16 in fact.
	//data, err := DumpObject(m)
	data, err := marshaller.Marshal(m)  // this would treat 1.5  as float64
	fmt.Println(data, err)
        // result is [251 63 248 0 0 0 0 0 0] ,  serialized by type float64
}

In rust, I use the library: https://github.com/pyfisch/cbor
In this implementation, it would handle well for float type:

fn test_cbor() {
    let s = serde_cbor::to_vec(&1.5).unwrap();
    println!("{:?}", s);
    // result is [249, 62, 0], serialized by type float16
}

it implemention is like:
https://github.com/pyfisch/cbor/blob/7d1d6d31eb3620add0b7ed5fc9bc3ff42ba4a532/src/ser.rs#L334-L342
when handle float64, it would judge if it could be handled by float32.
and in float32:
https://github.com/pyfisch/cbor/blob/7d1d6d31eb3620add0b7ed5fc9bc3ff42ba4a532/src/ser.rs#L311-L324
it would handle type float16.

However I test CBOR library in python and js version, they all not match to the CBOR specification
(I choose test library from here https://cbor.io/impls.html)

So I'm confused for this. The cbor serialize would effect the cid, if not match the CBOR specification, it would cause chaos!

[x448]

@atenjin CBOR allows protocols to specify how they want to handle floating-point values. When protocols don't specify, it can cause different implementations to produce different results.

I helped a generic CBOR library (in Go) add options for encoding floating-point values. fxamacker/cbor ended up providing 4 options just for encoding floating-point NaN values. See release notes for v1.5.

Also, cbor.io and other lists might include obsolete implementations that fail during resource exhaustion attacks from malicious CBOR data. The criteria those lists use can vary widely.