stty: `stty -F /dev/tty` reports incorrect baud rate on PowerPC64 Little-endian

[BAMF0]

(This has been forwarded from Launchpad Bug #2146427)

Problem

stty reports an incorrect baud rate on ppc64le systems.

Reproduce

On a ppc64le system, run:

stty -F /dev/tty

This outputs:

speed 15 baud; line = 0;
-brkint ixon -imaxbel iutf8

---

To compare with GNU, run:

gnustty -F /dev/tty

This outputs the correct baud rate:

speed 38400 baud; line = 0;
-brkint -imaxbel iutf8

System

• OS release: Ubuntu 26.04 (Development branch)
• uutils coreutils version: 0.7.0-0ubuntu1
• CPU architecture: ppc64le

[oech3]

BaudRate is enum on old glibc. So I guess 15 is internal value.

[CyberSarvesh]

I looked into this and it seems the issue comes from how stty formats the baud rate rather than how it’s retrieved.

On ppc64le, cfgetospeed appears to return an enum value (e.g. 15 for B38400), similar to other PowerPC targets. However, in stty.rs, the cfg conditions only treat:

• powerpc
• powerpc64 (big-endian)

as requiring enum → string conversion.

Because of this, ppc64le falls into the generic path:

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

and the raw value (15) is printed instead of being mapped to 38400.

It seems that all powerpc64 targets (including little-endian) should use the mapping logic via BAUD_RATES.

I can work on a patch to extend the cfg conditions accordingly if that approach looks correct and make the pr immediately if that makes sense.

[BAMF0]

@CyberSarvesh Interesting! When building uutils coreutils on ppc64le I received a compilation error saying that the datatype was u32 and not the expected baud rate enum (see #11282)

[CyberSarvesh]

That’s really interesting—and I think I’m seeing the discrepancy you’re referring to.

In my ppc64le test environment (via QEMU), cfgetospeed appears to return a BaudRate, which causes the original code (printing speed directly) to fail with:

However, based on #11282, it seems that in other environments the same function returns a u32, which would make the mapping logic fail instead.

So it looks like the behavior of cfgetospeed on ppc64le is environment-dependent.

I think the correct approach here might be to handle both cases explicitly rather than relying solely on architecture checks.

I can work on a version that supports both u32 and BaudRate if that makes sense.

[BAMF0]

Thanks for testing it out. This is indeed weird. I have tried compiling your fix in another ppc64le environment, and there it builds successfully! I think you may be right in that this is environment dependent and not strictly architecture dependent.

[CyberSarvesh]

Thanks for verifying that!!!
Since the behavior seems to vary across environments, I was wondering if it might make more sense to focus on making the mapping logic more robust, rather than relying purely on architecture-based conditions.
For example i was thinking along the lines of handling both representations of cfgetospeed (whether it behaves like a BaudRate or a numeric value) in a unified way.
Maybe this can be environment independent or anything you are thinking about specific to this?
Happy to explore if this approach sounds logical enough.

[BAMF0]

Yes I think that might be a good idea. Intuitively, I think we could assume that the value should always correspond to a BaudRate enum on ppc64le systems. The problem is likely whether we can directly map the enum integer value to the BaudRate naively. Looking at the definition in the nix crate seems to suggest that 15 maps to 38400 on Linux, which is correct for my provided bug.

[CyberSarvesh]

I took a closer look at the BaudRate definition in the nix crate, and it does seem to align with what you mentioned.

Although BaudRate is exposed as an enum, the underlying values correspond to the constants defined in the system headers. For example, B38400 maps to 15, which matches what we’re seeing in the output.

I also verified this in /usr/include, where B38400 is defined with the same value, so the numeric representation appears to be consistent at the libc level.

This suggests that even when cfgetospeed returns a raw integer, it still maps reliably to a valid BaudRate, which makes the mapping approach viable across both cases.

Given this, it might make sense for us to focus on a mapping-based approach that works consistently across environments, rather than relying on architecture-specific assumptions.

[oech3]

Can we support any baudrate instead of enum baudrate on all Linux targets?

[CyberSarvesh]

We could go with that, but I think the BaudRate enum still has value in terms of providing well-defined, expected values. That seems to align with how stty is currently structured.

[oech3]

We use enum because it is restricted by dependencies instead of we want to do that.
GNU supports any bauds on Linux and recient glibc.

[oech3]

Moreover, gny-stty 51 && uutils-stty panics on unsupported targets. It is why we have read-only support for any baud on Linux except for ppc targets.

[CyberSarvesh]

So the enum is more of a constraint from the current dependencies rather than the intended behavior, and the goal is to support arbitrary baud rates similar to GNU.
That also makes sense why the current approach can panic on unsupported values and why ppc targets behave differently.

I’ll keep that in mind while adjusting the approach here. If I’m not mistaken, we likely need to rely more on the underlying numeric representation and map it consistently, rather than depending on architecture-specific handling.

I’d be happy to work on updating the implementation along these lines if that sounds reasonable.