C file reading is implemented incorrectly about i3status HOT 3 OPEN

Thus you need to loop around read(), always.

I am not so sure. In i3status, it's usually better to keep going to not block the program rather than potentially being stuck in a while-read loop.

from i3status.

The reason why the lack of short read handling is typically not a problem with i3status is that it mostly reads /proc and /sys files, for which the kernel never returns a short read.

That said, at the very least for print_file_contents.c we should consider handling short reads, and it probably doesn’t hurt for the other reads either.

@orestisfl’s point also stands, though: would handling short reads change behavior when i3status is configured to print a file that is backed by an unavailable NFS mount (for example)?

from i3status.

In i3status, it's usually better to keep going to not block the program rather than potentially being stuck in a while-read loop.

Short reads can be very confusing and lead to bad decisions. Imagine that this very general function slurp() one day gets used to read a path to delete stored on disk in some config file ending in cacheDir = /home/myuser/.cache, short-reads only cacheDir = /home/myuser, and then runs rm -r on that.

The reason why the lack of short read handling is typically not a problem with i3status is that it mostly reads /proc and /sys files, for which the kernel never returns a short read.

Fair point. Then the function should have a mega disclaimer at the top though when it's safe to use, probably even in the name.

That said, at the very least for print_file_contents.c we should consider handling short reads, and it probably doesn’t hurt for the other reads either.

Yes, I think that's better. If some file by implementation of the kernel needs only one call to read, that's nice and fast, but that shouldn't be assumed in general-purpose functions because it's easy to introduce future bugs.

would handling short reads change behavior when i3status is configured to print a file that is backed by an unavailable NFS mount (for example)?

I think in the general case on a hanging kernel NFS, or FUSE mount, already the first read() will hang indefinitely (or for very long), so I doubt short-reading it would help here.

The only situation I can imagine (but am not sure it actually is implemented that way) is that you read a very large file (e.g. 1 GB), and after the first 500 MB the NFS server goes down (and clearly says so, thus avoiding a hang). Maybe then you get s short read.

From what I can tell so far, short reads don't seem to be designed to handle hangs from userspace, but to allow kernels to work with non-infinite buffers.

from i3status.