Test 150_tag_config_invalid_tags.txt on s390x architecture

[carnil]

Hi

In Debian we see a test case failure, strangely only on s390x:

Running test case: 150_tag_config_invalid_tags.txt
    Invoking: boxes -f 150_tag_config_invalid_tags.cfg -l
1,2c1,5
< boxes: 150_tag_config_invalid_tags.cfg: line 5: invalid tag -- tag4    , tag5
< boxes: 150_tag_config_invalid_tags.cfg: line 32: invalid tag -- Invalid1, 2invalid, invalid3-, -invalid4, in--valid5
---
> boxes: 150_tag_config_invalid_tags.cfg: line 32: invalid tag -- Invalid1
> boxes: 150_tag_config_invalid_tags.cfg: line 32: invalid tag -- 2invalid
> boxes: 150_tag_config_invalid_tags.cfg: line 32: invalid tag -- invalid3-
> boxes: 150_tag_config_invalid_tags.cfg: line 32: invalid tag -- -invalid4
> boxes: 150_tag_config_invalid_tags.cfg: line 32: invalid tag -- in--valid5
29c32
< tag1 (1) | tag2 (1) | tag3 (1) | tag6 (1)
---
> tag1 (1) | tag2 (1) | tag3 (1) | tag4 (1) | tag5 (1) | tag6 (1)
Error in test case: 150_tag_config_invalid_tags.txt (top: actual; bottom: expected)

https://buildd.debian.org/status/fetch.php?pkg=boxes&arch=s390x&ver=2.3.1-1%7Eexp2&stamp=1732398167&raw=0
but not seen on other release architectures: https://buildd.debian.org/status/package.php?p=boxes&suite=experimental

Does this by chance ring a bell?

[tsjensen]

Aww, that's another one of these isolated cases where all other test cases are miraculously fine. 🤔

The only thing I could guess is that because it's on s390x, which I really don't know, maybe it has to do with endianness or something? The code in question uses the to_utf32() function to convert an ASCII character to UTF-32 in a way that assumes some things about byte order. And it's obviously the finding of the comma (,) which is faulty in this case.

On the other hand, all the other test cases are green ...

[pkern]

Aww, that's another one of these isolated cases where all other test cases are miraculously fine. 🤔

The only thing I could guess is that because it's on s390x, which I really don't know, maybe it has to do with endianness or something? The code in question uses the to_utf32() function to convert an ASCII character to UTF-32 in a way that assumes some things about byte order. And it's obviously the finding of the comma (,) which is faulty in this case.

On the other hand, all the other test cases are green ...

I'd try to put it into bytes[3] on big endian machines. But ultimately the question is how it is used. If it's used in a numerical context at all then yes, the code is purely little endian right now (stuffing the lowest bits into the first byte of a four byte sequence, instead of the last).

[carnil]

So specifically the issue is been introduced with 8a7bb80 ("Enable lexer and parser to handle UTF-8 config file #72") AFAIU and for cross-reference.