On 8 Jan 2002, Alexandre Julliard wrote:
I'm not sure 002 is a good idea. It seems to encourage doing distinctions between file types where we should instead try to handle them in a common way.
The whole point of the FD_TYPE_XYZ distinction, as it currently is, is that at some places (actually, only in WriteFile() and ReadFile()), a distinction according to fd type _must_ be made. I am not sure if Windows allows overlapped IO on the console, for example, but if yes, this patch would be a prerequisite to implement that.
I just wanted to make this distinction more logical. I think it is necessary to separate fd types and flags. The distinction between regular files, pipes, sockets, ... that the patch introduces is currently not needed, but doesn't hurt IMO.
If you wish, I can strip the patch down to its essential part (have separate flags for overlapped and timeout flags). I guess I could also proceed entirely without this patch, if you seriously reject it as a whole, but I fear this will bring trouble sooner or later.
Martin
Martin Wilck Martin.Wilck@fujitsu-siemens.com writes:
I just wanted to make this distinction more logical. I think it is necessary to separate fd types and flags. The distinction between regular files, pipes, sockets, ... that the patch introduces is currently not needed, but doesn't hurt IMO.
I prefer that we make the distinction only where needed, to encourage people to write generic code if possible.
If you wish, I can strip the patch down to its essential part (have separate flags for overlapped and timeout flags).
That would be better yes. Also I think they should be really separate: the type should be an enum and the flags should be in a separate variable.
On 8 Jan 2002, Alexandre Julliard wrote:
If you wish, I can strip the patch down to its essential part (have separate flags for overlapped and timeout flags).
That would be better yes. Also I think they should be really separate: the type should be an enum and the flags should be in a separate variable.
This is impossible without major effort, because we are talking about the return value of the get_file_info() methods of struct object.
We'd have to change the prototype of get_file_info to take an additional (flags) argument.
Honestly, because we use at most 5 bits of that return value currently, splitting that into 2 variables seems a bit too much cleanliness to me. As long as there are clean macros to set and test the different fields, it should be ok to have type & flags in a single variable.
It would be possible to represent the return value of get_file_info with a bit field, but that wouldn't make things more beautiful to my taste.
Martin
-
Alexandre Julliard -
Martin Wilck