> You're attempting to make a huge distinction between interface and implementation. I can't rightly determine why. Well to start, for the same reason POSIX se

> You're attempting to make a huge distinction between interface and implementation. I can't rightly determine why. Well to start, for the same reason POSIX seems it necessary: they are distinct concepts that warrant distinct treatment. And I can't determine your insistence on calling different things by the same name. Especially after you yourself called them out as "opaque" yet insist that they describe something. What does opaque even mean? And this isn't even an interface vs implementation issue. Do you not see why it is useful to a user of the interface to understand why when they do a seek (assuming they can) on fd=1 that the offset of fd=2 or 4 or 6 or whatever may change. Two (or more) distinct entities yet somehow changing some shared state. What do you propose we call that state? The file descriptor? Then what do we call the thing returned by open()? They can't be the same because I can dup() that thing returned by open and have a new unique "thing", but it still changes the same state. > Different integers are always unique. It's the file description that isn't. The file description, however it is implemented is a uniquely identifiable entity. An object doesn't lose its identity just because it has multiple aliases, especially so when the lifetime of those aliases is ephemeral. The concrete embodiment of this in Linux or BSD would be the kernel address of the struct file.