kstenerud / concise-encoding

The secure data format for a modern world
https://concise-encoding.org
Other
258 stars 4 forks source link

Strange behavior with float arrays in CTE #29

Open kengruven opened 3 years ago

kengruven commented 3 years ago

In float arrays, enctool sometimes tries to write numbers in base-16, but doesn't quite use valid syntax:

$ echo 'c1 |f16 1|' | ./enctool convert -df cte
c0
|f16x 1p+00|

The enctool parser correctly reports this as an error:

$ echo 'c1 |f16 1|' | ./enctool convert -df cte | ./enctool convert -df cte
c0
offset 10 (line 2, col 8): unexpected [p] while decoding hex float

My first thought was that "1" is an int, not a float, and "f16" might be expecting only a float (despite there being only one 'numeric type'?). But it fails the same way for some floats, too:

$ echo 'c1 |f16 1.0|' | ./enctool convert -df cte
c0
|f16x 1p+00|

It's not just forgetting the ".0" when writing base-16 values inside an array, though. There's something weirder going on. Here, it prints an invalid number, and also flips the sign:

$ echo 'c1 |f16 -1|' | ./enctool convert -df cte 
c0
|f16x 1p+00|
kstenerud commented 3 years ago

There's a bug in the value printer somewhere. I had to put special code in for float16 values since it's not a native format, so something broke along the way I bet.

kengruven commented 3 years ago

Hmm, you're right that most of these issues are f16-specific. Even with f32/f64, though:

$ echo 'c1 |f32 -1|' | ./enctool convert -df cte 
c0
|f32x 1|

Perhaps that's a separate bug.

kengruven commented 3 years ago

Just to confirm, are |f32 1| and |i32 1.0| both considered valid?