Commit 42f8358
fix(sim): decode simulator output on Windows
The old code used a simple data.decode("utf-8") which would throw a raw UnicodeDecodeError when simulator output contained
non-UTF-8 characters (e.g., Windows legacy code pages like cp1252). The error message was something like:
UnicodeDecodeError:'utf-8' codec can't decode byte 0xe9 in position 42: invalid continuation byte
This was confusing because it gave no indication that the problem was with simulator output encoding, not with your source code or VUnit itself.
The change tries each encoding in order. If all fail, it falls back to data.decode("utf-8", errors="replace") which substitutes undecodable bytes with � instead of crashing.
Before: A simulator emitting a single non-UTF-8 byte (e.g., accented character in a file path, or a copyright symbol in a vendor library message) would crash VUnit with an opaque UnicodeDecodeError — both on compile success output and on compile failure output (err.output).
After: The output is decoded gracefully using the most likely encoding, so VUnit continues normally and the user sees the actual compile pass/fail message instead of a decoding traceback.1 parent 3357e4b commit 42f8358
1 file changed
Lines changed: 25 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
11 | 11 | | |
12 | 12 | | |
13 | 13 | | |
| 14 | + | |
14 | 15 | | |
15 | 16 | | |
16 | 17 | | |
| |||
360 | 361 | | |
361 | 362 | | |
362 | 363 | | |
| 364 | + | |
| 365 | + | |
| 366 | + | |
| 367 | + | |
| 368 | + | |
| 369 | + | |
| 370 | + | |
| 371 | + | |
| 372 | + | |
| 373 | + | |
| 374 | + | |
| 375 | + | |
| 376 | + | |
| 377 | + | |
| 378 | + | |
| 379 | + | |
| 380 | + | |
| 381 | + | |
| 382 | + | |
| 383 | + | |
| 384 | + | |
| 385 | + | |
363 | 386 | | |
364 | 387 | | |
365 | 388 | | |
366 | 389 | | |
367 | 390 | | |
368 | | - | |
| 391 | + | |
369 | 392 | | |
370 | | - | |
| 393 | + | |
371 | 394 | | |
372 | 395 | | |
373 | 396 | | |
| |||
0 commit comments