bytestring_to_count handle different byte lens

[NothinRandom]

zeek/src/zeek.bif

Line 2667 in e5db1f0

function bytestring_to_count%(s: string, is_le: bool &default=F%): count

Please implement inputs for bytestring with length of 3, 5, 6, 7. This is useful for embedded devices that optimizes for space as use as minimum as needed.

[timwoj]

I have some questions about how we'd handle this in relation to endianness. For example, take these two tests from bifs/bytestring_to_count.zeek:

	print bytestring_to_count("\x00\x00\xff\xff", F); # 65535
	print bytestring_to_count("\xff\xff\x00\x00", T); # 65535

On a little-endian system, the first one gets converted into 0xFFFF0000, which is 65535, which makes sense and matches the test.

Next, take the three-byte string version of those same tests, just chopping off the first and last byte from both:

	print bytestring_to_count("\x00\xff\xff", F); # 65535
	print bytestring_to_count("\xff\xff\x00", T); # 65535

The question I have is related to zero-padding on those strings. What should those turn into? Should the former turn into 0x00FFFF00 or 0xFFFF0000? The latter test currently zero-pads to the right so it turns into 0xFFFF0000 (65535 on an LE system), maybe as expected?

[NothinRandom]

Hi Tim. This is a great question. If bytestring_to_count("\x00\xff\xff", F) is targeting big endian, then wouldn't the padding be to the left (e.g. "\x00\x00\xff\xff")?