stty: fix baud rate display on ppc64le(#11708)

[CyberSarvesh]

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:

all(target_arch = "powerpc64", target_endian = "big")

However, on ppc64le (target_endian = "little"), cfgetospeed still returns enum values.

Fix

• Remove endian-specific condition
• Treat all powerpc64 targets the same
• Route them through BAUD_RATES mapping

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.

[Copilot]

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 powerpc64 Linux targets use the BAUD_RATES enum→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.

[Copilot]

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".

[Copilot]

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…”.

[github-actions]

GNU testsuite comparison:

Congrats! The gnu test tests/pr/bounded-memory is now passing!

[CyberSarvesh]

It looks like the remaining failures are related to CI environment issues rather than this change.
The OpenBSD job appears to fail in bindgen/clang, and the Android job is failing due to cargo not being available.
Since these errors occur outside the stty changes in this PR, they may be unrelated, but I’m happy to investigate further if needed.

[BAMF0]

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).

[CyberSarvesh]

Environment

I 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:

[codspeed-hq]

Merging this PR will degrade performance by 5.3%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 4 improved benchmarks
❌ 6 regressed benchmarks
✅ 299 untouched benchmarks
⏩ 46 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	cksum_sha256	1.7 s	1.8 s	-4.04%
⚡	Simulation	cksum_blake2b	192.7 ms	183.8 ms	+4.86%
❌	Simulation	cksum_sha2	1.7 s	1.8 s	-4.04%
❌	Simulation	cksum_sha224	1.7 s	1.8 s	-4.05%
❌	Simulation	cksum_crc32b	13 ms	13.7 ms	-5.3%
❌	Simulation	nl_large_file[10]	24.1 ms	25 ms	-3.73%
❌	Simulation	nl_many_lines[100000]	18.9 ms	19.6 ms	-3.68%
⚡	Simulation	fold_custom_width[50000]	25.3 ms	22.9 ms	+10.22%
⚡	Simulation	fold_many_lines[100000]	63.8 ms	57.3 ms	+11.41%
⚡	Simulation	split_bytes	401.8 µs	389.7 µs	+3.1%

---

_{Comparing CyberSarvesh:main (381925e) with main (5b54e08)}

Footnotes

1. 46 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩