Column `User` is printed as signed int

[chriss-de]

Hi

Latest version of htop prints the UserID in column User as signed integer if no username can be found. UserID is an unsigned integer.

This disrupts that line as the - character moves everything one character to the right.

[Explorer09]

1. POSIX standard doesn't say uid_t should be signed or unsigned. "nlink_t, uid_t, gid_t, and id_t shall be integer types."
2. What is your OS version and how can a large UID integer like your case can happen?

[chriss-de]

1. This may be Linux specific. But seems logical. A negative User ID (or for that matter signed user ID) makes no sense - at least to me.
2. This screenshot is from Arch Linux. Those large user IDs come from rootless containers. You define a subuid range from 2^31 -1 with the size of 2^31 (entry in /etc/subuid : containers:2147483647:2147483648)

[Explorer09]

A negative User ID (or for that matter signed user ID) makes no sense - at least to me.

It's not about whether negative user ID makes sense to you, it's about whether the OS allows user ID to overflow the signed integer limit (that is, 2^31 - 1). If the OS never permits UIDs above (2^31 - 1), then it makes no difference printing the UID in signed integer or unsigned integer.

[chriss-de]

https://en.wikipedia.org/wiki/User_identifier states it is a 32bit integer

According to this in 2001 Linux switched to 32bit and it is unsigned.

Now - assuming there is a reason to have a signed UID - it still breaks the output.

[chriss-de]

to quote your source (updated document) https://pubs.opengroup.org/onlinepubs/9799919799/

• nlink_t, uid_t, gid_t, and id_t shall be integer types.
• blkcnt_t and off_t shall be signed integer types.

It states to be an integer - but for blkcnt_t it is specific defined as a signed integer. So one can assume that uid_t may be unsigned.

[Explorer09]

According to this in 2001 Linux switched to 32bit and it is unsigned.

Now - assuming there is a reason to have a signed UID - it still breaks the output.

What's the reason you have a UID in that overflowed range in the first place? I am referring to this: -2147481603 2147485693U 0x800007FDU

So one can assume that uid_t may be unsigned.

No. If any OS defined it to be signed, we need to follow. htop is not a Linux-only program. Any Unix-like OS can define uid_t in its own way.

Note that I'm not arguing whether uid_t should be a signed type or unsigned according to standard or use cases or whatever you believe. I'm asking that in what use case can your UID overflow the INT32_MAX limit. Because then we can determine whether the bug is in htop or in your (unusual) Linux configuration.

[BenBE]

The UID mapping should handle negative numbers if uid_t is signed.

[Rivers47]

This is standard practice for container subuid/subgid. I think it'd be nice if htop can query /etc/subuid and map the id back to the login names

[chriss-de]

I'd like to add to my previous thought why uid should not be handled as unsigned.

After all the uid is an integer with 32bit - the rest is representation and interpretation. What would a signed uid mean ? If I have a uid with -20 - is that the evil twin of uid 20 ?

And my initial bug report has been about the fact that the output of htop gets destroyed. If you insist that there are users with a negative uid - ok. But could you make it so that the columns in htop don't get shifted?