whitespace not insignificant

[msloth]

Hi! Seems whitespace is not insignificant. Adding a line break to the t2b input results in extra data in the output. Example,

[0][10:57:55]/cygdrive/c/Dropbox/tools/t2b:
>printf "u8 10" | t2b.exe | hd
00000000  0d 0a                                             |..|
00000002

[0][10:57:59]/cygdrive/c/Dropbox/tools/t2b:
>printf "u8 10\n" | t2b.exe | hd
00000000  0d 0a 0d 0a                                       |....|
00000004

[0][10:58:05]/cygdrive/c/Dropbox/tools/t2b:
>printf "u8 10\r\n" | t2b.exe | hd
00000000  0d 0a 0d 0a                                       |....|
00000004

Using the released v1.0 win64 binary on Cygwin/win10. I saw the same behavior when using a textfile, but the above replicates the same behavior.

[msloth]

and,

[0][10:58:11]/cygdrive/c/Dropbox/tools/t2b:
>printf "hex\nu8 10\n" | t2b.exe | hd
00000000  10 10                                             |..|
00000002

[0][11:01:39]/cygdrive/c/Dropbox/tools/t2b:
>printf "hex\nu8 10\nu8 ff" | t2b.exe | hd
00000000  10 ff                                             |..|
00000002

[0][11:02:05]/cygdrive/c/Dropbox/tools/t2b:
>printf "hex\nu8 10\nu8 ff\n" | t2b.exe | hd
00000000  10 ff ff                                          |...|
00000003

[thosakwe]

This is intentional. It may be changed in a future version. But that would likely be via PR.

[msloth]

Ah, ok, so how is it meant to be interpreted? It seems like ending with a newline duplicates the last byte.
The readme says Newlines are solely for the sake of readability; all whitespace is the same., hence why I was surprised.

Again looking at the first post above, it seems the output becomes a leading, extra 0x0d if I express the byte in decimal rather than in hex (meaning it doesn't really become an u8 but a two-byte output).