3 ms·
In SunOS 4.x `FILE` was not opaque, and `int fileno(FILE *)` was a macro, not a funciton, and the field of the struct that held the fd number was a `char`. Yea
by cryptonector 1y ago
In SunOS 4.x `FILE` was not opaque, and `int fileno(FILE *)` was a macro, not a funciton, and the field of the struct that held the fd number was a `char`. Yeah, that sucked for ages, especially since it bled into the Solaris 2.x 32-bit ABI.
- bodyfour 1y agoIndeed, that was the way it originally worked in all UNIXes: https://github.com/dspinellis/unix-history-repo/blob/Research-V7-Snapshot-Development/usr/include/stdio.h#L26 https://github.com/dspinellis/unix-history-repo/blob/Researc... It was a then-important optimization to do the most common operations with macros since calling a function for every getc()/putc() would have slowed I/O down too much. That's why there is also fgetc()/fputc() -- they're the same as getc()/putc() but they're always defined as functions so calling them generated less code at the callsite at the expense of always requiring a function call. A classic speed-vs-space tradeoff. But, yeah, it was a mistake that it originally used a "char" to store the file descriptor. Back then it was typical to limit processes to 20 open files ( https://github.com/dspinellis/unix-history-repo/blob/Research-V7-Snapshot-Development/usr/sys/h/param.h#L13 https://github.com/dspinellis/unix-history-repo/blob/Researc... ) so a "char" I'm sure felt like plenty.