3 ms·

> The interface is an opaque number While opaque for a subset of the API, it's not fully opaque since certain assumptions are made by the client based on their

by epcoa 3y ago

> The interface is an opaque number While opaque for a subset of the API, it's not fully opaque since certain assumptions are made by the client based on their value: they are guaranteed to be reused and minimal. What this means is I can do close(0); open(...) to redirect stdin. > the implementation describes state, some of which is guaranteed to be present, one of which you can access using lseek() >> Which are flags and a current offset at a minimum. Uhh... no. Try that with pipes, sockets, FIFOs or any of the myriad other file types, eventfds, signalfds, kqueue, etc there are. Most open fds on a data center server likely don't meet your criteria. Even POSIX disagrees for the concept you are trying to convey cf "file description". https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

akira2501 3y ago
> Even POSIX disagrees for the concept you are trying to convey cf "file description" You should have kept reading: 3.258 Open File Description A record of how a process or group of processes is accessing a file. Each file descriptor refers to exactly one open file description, but an open file description can be referred to by more than one file descriptor. The file offset, file status, and file access modes are attributes of an open file description.
- epcoa 3y ago
  "The file offset, file status, and file access modes are attributes of an open file description" That says file description there buddy, not descriptor. The two are defined separately, that is all. The single integer does not describe state in the way those terms are typically used; we have clearer vocabulary: refers, points to, etc that's fine. But it is a distinction with a difference. (They're not even unique). Edit: yeah, it says refers, not describes.
  - akira2501 3y ago
    And, read more carefully, emphasis added: "Each file descriptor refers to exactly one open file description" Different integers are always unique. It's the file description that isn't: "but an open file description can be referred to by more than one file descriptor." You're attempting to make a huge distinction between interface and implementation. I can't rightly determine why.
    - epcoa 3y ago
      > 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.

by epcoa 3y ago

akira2501 3y ago

> Even POSIX disagrees for the concept you are trying to convey cf "file description" You should have kept reading: 3.258 Open File Description A record of how a process or group of processes is accessing a file. Each file descriptor refers to exactly one open file description, but an open file description can be referred to by more than one file descriptor. The file offset, file status, and file access modes are attributes of an open file description.

epcoa 3y ago
"The file offset, file status, and file access modes are attributes of an open file description" That says file description there buddy, not descriptor. The two are defined separately, that is all. The single integer does not describe state in the way those terms are typically used; we have clearer vocabulary: refers, points to, etc that's fine. But it is a distinction with a difference. (They're not even unique). Edit: yeah, it says refers, not describes.
- akira2501 3y ago
  And, read more carefully, emphasis added: "Each file descriptor refers to exactly one open file description" Different integers are always unique. It's the file description that isn't: "but an open file description can be referred to by more than one file descriptor." You're attempting to make a huge distinction between interface and implementation. I can't rightly determine why.
  - epcoa 3y ago
    > 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.