fix: guard against missing value args for cc and speed settings#56
Draft
fix: guard against missing value args for cc and speed settings#56
Conversation
When a control character name (intr, quit, etc.) or speed setting (ispeed, ospeed) was passed without a following value argument, shift @parameters returned undef, causing a cascade of "uninitialized value" warnings and silently setting the cc slot to 0 (which disables the character on Linux). Now _parse_char_value returns undef with a clear warning for missing values, and the cc handlers skip assignment. Speed handlers also validate before lookup. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Guard
_parse_char_value()and speed handlers against missing value arguments.Why
Calling
stty(\*FH, 'intr')without a value causedshift @parametersto returnundef, which triggered a cascade of "Use of uninitialized value" warnings through the pattern matching chain in_parse_char_value(). Worse, it silently set the control character to 0 — which on Linux happens to be_POSIX_VDISABLE, effectively disabling the character without any clear indication of what went wrong. Same issue affectedispeed/ospeedwithout a rate argument.How
_parse_char_value()now returnsundefwith a clear warning when passed an undefined valueispeed/ospeedhandlers validate the rate argument before lookupTesting
t/01-parse-char-value.tverify the undef input path🤖 Generated with Claude Code
Quality Report
Changes: 2 files changed, 36 insertions(+), 12 deletions(-)
Code scan: clean
Tests: passed (OK)
Branch hygiene: 1 issue(s)
Generated by Kōan post-mission quality pipeline