stty: fix baud rate display on ppc64le(#11708)#11816
stty: fix baud rate display on ppc64le(#11708)#11816CyberSarvesh wants to merge 3 commits intouutils:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Adjusts stty baud-rate formatting so PowerPC64 little-endian (ppc64le) prints human-readable baud rates (e.g., 38400) instead of the underlying enum discriminant (e.g., 15), aligning behavior with other PowerPC targets.
Changes:
- Remove endian-specific cfg gating so all
powerpc64Linux targets use theBAUD_RATESenum→string mapping. - Update in-code comments describing when baud rate can be printed directly vs needs mapping.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| #[cfg(any(target_os = "linux", bsd))] | ||
| #[cfg(all( | ||
| not(target_arch = "powerpc"), | ||
| not(all(target_arch = "powerpc64", target_endian = "big")) | ||
| not(target_arch = "powerpc64") | ||
| ))] |
There was a problem hiding this comment.
The #[cfg(any(target_os = "linux", bsd))] direct-print branch now excludes all powerpc64 targets, but the enum-mapping branch is Linux-only and the fallback branch excludes BSD. This means on BSD powerpc64 builds the speed token will not be printed at all (regression vs printing the numeric u32 speed). Consider splitting the cfgs so BSD always uses the direct-print path, and only gate the PowerPC enum mapping on target_os = "linux".
| // On PowerPC (including powerpc64 and ppc64le), baud rates are represented as enum values, | ||
| // so we need to map them to their corresponding numeric strings for display. | ||
| #[cfg(target_os = "linux")] | ||
| #[cfg(any( | ||
| target_arch = "powerpc", | ||
| all(target_arch = "powerpc64", target_endian = "big") | ||
| target_arch = "powerpc64" |
There was a problem hiding this comment.
The comment says “On PowerPC (including powerpc64 and ppc64le)…” but this block is guarded by #[cfg(target_os = "linux")]. To avoid misleading readers into thinking this applies to BSD/macOS PowerPC targets, consider updating the wording to explicitly say “On Linux PowerPC…”.
|
GNU testsuite comparison: |
|
It looks like the remaining failures are related to CI environment issues rather than this change. |
|
Hey there! Do you have any logs showing that this builds on ppc64le (the CI does not)? I am interested since this reverts the fix for the bug I experienced when building on ppc64le (#11282). |
EnvironmentI tested this on a ppc64le environment (via QEMU), and I’m seeing different behavior from what was described in #11282. 
Attempting to build the original code (which prints speed directly) results in:
With the changes in this PR, the code builds successfully and produces:
|
PR Description
Fixes: #11708
Summary
On ppc64le, stty prints incorrect baud rates (e.g. 15 instead of 38400).
This happens because cfgetospeed returns enum values (e.g. B38400 → 15), but the current code only applies enum-to-string mapping for powerpc and powerpc64 big-endian.
As a result, ppc64le incorrectly falls into the direct-print path.
Root Cause
The existing cfg conditions assume that only big-endian PowerPC64 uses enum-based baud rates:
However, on ppc64le (target_endian = "little"), cfgetospeed still returns enum values.
Fix
I’m happy to make further adjustments if there are any issues with the conditions or edge cases I may have missed do recommend better practices to follow in the repo.