On 26 Jan 2011, at 16:08, Rod Widdowson wrote:
The vol package uses three separate types of file descriptor. FILE *f int fd FD_t
I remain a little bit confused about what the problem is here, and what the desired cure is. What follows is an attempt to clarify things ...
My assumption is that having 3 different types of file descriptor isn't a huge problem (it would be really nice to not have int fd, and FD_t, but we're always going to have 2, as long as we use both POSIX and native I/O).
It seems to me that the real issue is that in places we intermingle the second and third I/O families. On Unix, this isn't a problem because these two families are identical. But on Windows, where we have our own I/O calls in ntops.c, we'll (for example) open a file using "normal" open(), but then unlink it using nt_unlink(). This causes problems because we then don't get the unlink semantics that we desire.
So, there are two issues to resolve. The first is that we want to ensure consistency of use. That is, we don't want to be explicitly (or implicitly) casting between FD_t and int. In fact, it would be highly desirable if the compiler stopped us from doing so.
Secondly, it would be really nice to not have 3 file descriptor types. This would entail replacing all use of the int family with the FD_t family. In my view, this would be best acheived by adding a platform independent I/O framework to our nascent opr portability library.
Or is there more to this than I realise? Cheers, Simon. _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
