This PR fixes a bug in how the library chooses Rust types to represent signals.
We tried a DBC with a 16 bit unsigned signal with a factor of -1. This means the range of valid values is [-65535, 0]. But this confused the function scaled_signal_to_rust_int which chose i8 when it should have picked i32.
This PR will:
Change scaled_signal_to_rust_int to look at the whole range of values for a signal and pick the smallest Rust type.
Ignore min and max values when deciding Rust types for a signal because Config.check_ranges can disable range checking. To be on the safe side, this picks types assuming the worst-case values for a signal.
Drop the symlink in testing/can-messages/src/messages.rs because it doesn't work on Windows. Now testing/can-messages/build.rs copies the file from can-messages to can-embedded.
Fix build order so can-messages goes before can-embedded.
Add unit and integration tests. UnsignedNegativeFactorSignal in example.dbc will reproduce the bug.
This PR fixes a bug in how the library chooses Rust types to represent signals.
We tried a DBC with a 16 bit unsigned signal with a factor of -1. This means the range of valid values is
[-65535, 0]. But this confused the functionscaled_signal_to_rust_intwhich chosei8when it should have pickedi32.This PR will:
scaled_signal_to_rust_intto look at the whole range of values for a signal and pick the smallest Rust type.minandmaxvalues when deciding Rust types for a signal becauseConfig.check_rangescan disable range checking. To be on the safe side, this picks types assuming the worst-case values for a signal.testing/can-messages/src/messages.rsbecause it doesn't work on Windows. Nowtesting/can-messages/build.rscopies the file fromcan-messagestocan-embedded.can-messagesgoes beforecan-embedded.UnsignedNegativeFactorSignalinexample.dbcwill reproduce the bug.Happy to address any comments or change requests.