"G. Branden Robinson" writes: >> The name of a header providing some function is thus inconsequential. > > Then why not have one official big header file for the whole standard? > > #include > > When you answer that to your own satisfaction, I suspect you'll have > little trouble following Alex's argument. > > ...which doesn't mean you'll agree with it. The only reason I can imagine for not having One Big Header in 2026 is the same reason why I wouldn't make the change Alex is proposing: because someone already chose to create many headers and changing it would mean shuffling lots of code around for no gain. I imagine that, at some point, the amount of time that it would take to read and parse such a header would've been a problem also. Perhaps that inspired the fragmentation. Perhaps not. I do not know, I didn't do the historiography. I do know that splitting an extremely widely used header (291,660 matches on Debian codesearch) to replace it with one used far less widely (11,459 matches on that same codesearch, some of which mention portability concerns as the motivation for including memory.h, and I suspect most of which also have an include of string.h in the same file, but I did not verify this) only means that people include both, perhaps conditionally, while seeing no changes outside of the preamble of their source files. -- Arsen Arsenović