SIGWINCH and the TIOCGWINSZ ioctl() were originally omitted from POSIX as they were considered relevant for windowing systems only and GUI-stuff was considered out of scope for POSIX. Furthermore, POSIX only specifies ioctl() for STREAMS; other interfaces that traditionally use ioctl() calls are specified in POSIX using wrapper functions (which is what the new interface is; it is specified such that you can implement it just by wrapping the traditional TIOCGWINSZ/TIOCSWINSZ ioctl calls).
My original proposal had functions tcgetsize() and tcsetsize(), but it turns out that QNX already uses these identifiers with an incompatible signature, so a last minute change was made to name these tcgetwinsize() and tcsetwinsize().
Furthermore, the winsize structure traditionally also has ws_xpixel and ws_ypixel members indicating the resolution of the terminal. This existed primarily becaus on some historical virtual terminals, a client could change the video mode by calling the TIOCSWINSZ ioctl, providing resolution and row/column count for the desired video mode. While no current virtual terminal known to me supports this, the POSIX spec mandates that if a slave PTY calls tcsetwinsize(), the window size update is propagated to the master, allowing terminal emulators to implement this feature if desired. Another objection raised was that the traditional unsigned short type may be insufficient for future high-definition screens and a resolution may not be well defined for some types of terminals like hardcopy or braille terminals.
I maintain that submitting a feature to POSIX and waiting for a new version of the standard to be released is probably the easiest way to get glibc to implement a feature you want.
And nowadays modern terminals even support in-band resize notification so there is no need for SIGWINCH: https://gist.github.com/rockorager/e695fb2924d36b2bcf1fff4a3...
>_POSIX_C_SOURCE
>TIOCGWINSZ
>SIGWINCH
>TIOCSWINSZ
Jesus christ, this whole fashion among the C and linux people focused on writing shorter, but unreadable names is really terrible habbit
...but it has 96 rows, and there are five of them, side by side across my monitor. Definitely an improvement! - but I still prefer not to have long rambling Java-style identifiers.
Internal identifiers and macro names had a lower limit of 31 significant characters in C.
The more relevant original reason for short identifiers is that code completion wasn’t a thing, and to a lesser extent that screens were at most 80 characters wide.
Hence, famously, "creat" instead of "create"
Also, if the size was reported in-band, it would mess up applications that are not aware of that in-band signalling.
(I'm the author of the linked-to article.)
So we start the interactive age with teletypes, keyboards and paper. Nothing beyond printing the characters, ringing the bell, and the basic ACSII chars for moving right (SPACE, TAB), left (BS, CR), and down (VT, FF, LF). The main editor is a line editor called ed.
Move ahead a few years and you have 'glass' ttys, every one of them different. This is the termcap and curses era. The screen size is baked into the termcap entry. Editors are now interactive 'screen' editors, vi and emacs mostly. Pretty soon, some terminals can support multiple font sizes and the LINES and COLUMNS environment variables can override the termcap entries. Terminals are still separate devices connected via RS-232 and all communication is in-band.
Move ahead a few more years and we're now in the era of workstations with bitmapped graphics (and their Mac and PC equivalents). 'Terminals' are now interactive graphics programs that run under the window system (either X11 or proprietary), so they need to translate kbd and mouse events into the ASCII byte stream onto a pty to emulate the old RS-232 convention to talk to the "line dscipline" part of the kernel's tty driver. But now, changing the size of a window is trivial; people do it all the time. They do it in the middle of vi sessions. They do it when they've ^Z'd out of vi and then expect vi to know the new size when they fg back into it. You can't just blast escape codes onto the line as whatever is reading stdin is likely not equipped to deal with it. At the very least, the in-band exchange has to be initiated by the 'computer' side of the pty. So, they added SIGWINCH and it was an out-of-band signal sent from the terminal emulator program through the pty (which, again, is a software abstraction in the os as opposed to an RS-232 line) to tell the other side of the pty that, when it has a chance, it should re-query the size of the terminal. It took a little while to nail down the semantics of the shell notifying backgrounded processes, but it got the job done. But it likely doesn't make a lick of sense to anyone that doesn't remember the good ol' days.
I wrote a proposal[0] to have terminals send these updates in-band, instead of requiring polling a-la xterm. So far, foot, ghostty, iterm2, and kitty have implemented this feature on the terminal side. Neovim, notably, also supports this on the client side.
[0]: https://gist.github.com/rockorager/e695fb2924d36b2bcf1fff4a3...
Reminds me I need to bring it here.
I am probably mis-remembering but my memory is getting a signal while handling another signal was a point of pain.
It may seem strange that there's a process signal for window-size changes, but that's what was needed back in 1985. There's a similar dance with the Amiga's console.device, but both Unix and Amiga TTYs are better than Windows' terminals where there was no such thing as a PTY until Windows 10, you had to make direct API calls, and even now it's still pretty slow: https://devblogs.microsoft.com/commandline/windows-command-l...
This page is a great overview pf the Unix TTY/PTY subsystem: https://www.linusakesson.net/programming/tty/
This does not belong into a kernel.