A feature being present in one language does not preclude it being needed in another. Length prefixed strings are not some newfangled high level concept, they are just an alternative to null terminated strings that have proved to be better. struct string {
size_t length;
char str[];
}; Funny, files are different in every filesystem too, so is the size of a byte, and the basic execution character set. That "but.. but.. portability!" drivel might work on children, but not me sorry.
A filename in C is a string that references something that can be accessed using fopen. Path separators, drive letters, file versions, and resource fork IDs, if they exist at all, are all part of the string. A file in C doesn't have to have a size and doesn't have to be seekable. All it needs is some way to read and/or write bytes in either text or binary modes (which can be the same). Data written to a file can be reread on the same machine no matter what character set, byte size, or byte order is used by reading and writing the same data types. Data can be read portably on any machine by serializing the bytes with shifts and masking and using a translate table where e.g. table['a'] == 97;. Whether a file is a regular file, device, pipe, symbolic link, memory-mapped data, or any other type, it can always be accessed as a stream of bytes. You can portably open argv[1] if it's a valid filename no matter what filesystem or path separators are in use.
Directories are not simple streams of bytes or lines of text. They contain other items and standardizing directories is useless unless there is a way to list these items. Can directories contain subdirectories? What about symbolic links? Should they be followed? If they are followed, how would a directory that contains a link to itself be handled? What about resource forks? If the file has resource forks, programmers will want to be able to see them. Should these multiple resource forks or data streams be viewed by opening the file as a directory? This won;t work if symbolic links or directories have resource forks separate from their referenced files. Do hidden files begin with a "." or have an attribute? Should there be a way to access hidden files? How do you determine the path separator? What about determining what drive letters are accessible? What about files with multiple versions like in VMS?
POSIX sys/stat.h mentions inodes and group IDs, but doesn't mention hidden attributes, access control lists, alternate data streams or type codes. dirent.h says nothing about them either. I haven't read C11 yet, but in any case these aren't sufficient for the primary use case (serialization). You also _Byteorderof, _Bitorderof, _Paddingbyteof, and a whole host of other shit.
I agree that there should be some way to improve portably serializing structs. I think C should add functions similar to hton* and ntoh* functions. I would have the "network" side of these functions be an array of unsigned char with a maximum of 255 even if bytes are more than 8 bits. If you read the C11 standard you will find that _Alignas controls padding bytes. What is an "OS"? Where is that mentioned in the C standard?
"OS" meaning some collection of functions that is included with the system but is not part of the C standard or the compiler's extensions. This "OS" might support threads even if the compiler and C library do not. If the compiler implementer claims to support threads and errno is not thread-safe, you should file a bug report.