[Bug]: human_to_eng() silently accepts ambiguous 'm' suffix #3

New Issue

2026-04-17T11:29:41Z

tgohle commented

2026-04-17 11:29:41 +00:00

Problem

human_to_eng() accepts m as milli, which can silently misinterpret user input in fields where that is probably not what was meant.

Current code context

elif t.endswith("m") and not t.endswith("mm"):
    mult = 1e-3
    t = t[:-1]

Why this is a problem

In practice, an input like 1m in a frequency field is much more likely to be a user typo or shorthand for something else than a deliberate request for milli-Hz.

That means the current behaviour can silently send a completely wrong value to the instrument without any warning in the log.

Fix approach

Add input validation for ambiguous suffix usage and log a warning when m is used in contexts where it is likely unsafe or misleading.

Possible options:

reject ambiguous input
warn and refuse to send
only allow explicit suffixes such as ms, mV, kHz, MHz, etc.

Status

Still open.
Not fixed in the current v0.2 working copy.

### Problem `human_to_eng()` accepts `m` as milli, which can silently misinterpret user input in fields where that is probably not what was meant. ### Current code context ```python elif t.endswith("m") and not t.endswith("mm"): mult = 1e-3 t = t[:-1] ``` ### Why this is a problem In practice, an input like `1m` in a frequency field is much more likely to be a user typo or shorthand for something else than a deliberate request for milli-Hz. That means the current behaviour can silently send a completely wrong value to the instrument without any warning in the log. ### Fix approach Add input validation for ambiguous suffix usage and log a warning when `m` is used in contexts where it is likely unsafe or misleading. Possible options: - reject ambiguous input - warn and refuse to send - only allow explicit suffixes such as `ms`, `mV`, `kHz`, `MHz`, etc. ### Status Still open. Not fixed in the current v0.2 working copy.

tgohle added the area/transport

labels 2026-04-17 11:41:45 +00:00

tgohle self-assigned this 2026-04-17 12:09:17 +00:00

tgohle changed title from ~~human_to_eng() silently accepts ambiguous 'm' suffix~~ to [Bug]: human_to_eng() silently accepts ambiguous 'm' suffix

2026-04-18 11:19:08 +00:00

tgohle commented

2026-04-20 12:34:50 +00:00

Fixed in v0.2.6.

human_to_eng() no longer silently accepts bare m as milli. This was unsafe because inputs like 1m could be interpreted as 1e-3 and sent to the instrument without any warning.

The parser now rejects ambiguous bare m / M input and requires explicit units instead, for example ms, mV, kHz, or MHz. The affected GUI apply paths were also updated so invalid ambiguous input is refused and logged, instead of being converted and sent.

Result:

ambiguous m suffix no longer slips through silently
user gets a warning in the log
explicit units continue to work as intended

Fixed in v0.2.6. `human_to_eng()` no longer silently accepts bare `m` as milli. This was unsafe because inputs like `1m` could be interpreted as `1e-3` and sent to the instrument without any warning. The parser now rejects ambiguous bare `m` / `M` input and requires explicit units instead, for example `ms`, `mV`, `kHz`, or `MHz`. The affected GUI apply paths were also updated so invalid ambiguous input is refused and logged, instead of being converted and sent. Result: - ambiguous `m` suffix no longer slips through silently - user gets a warning in the log - explicit units continue to work as intended

tgohle closed this issue

2026-04-20 12:34:50 +00:00

tgohle added this to the Close all Bugs higer or equal "Medium" milestone 2026-04-20 12:37:34 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: tgohle/0003-SDG2042X-PyQt-GUI-for-Linux#3