> [EMAIL PROTECTED] writes: >>> The POSIX spec requires open() to assign fd's consecutively from zero. >>> http://www.opengroup.org/onlinepubs/007908799/xsh/open.html > >> With all due respect, PostgreSQL now runs natively on Win32. > > ... using the POSIX APIs that Microsoft so kindly provides. > fd.c will certainly not work at all on a platform that doesn't > provide a POSIX-like file access API, and in the absence of any > evidence to the contrary, I don't see why we shouldn't assume > that the platform adheres to that part of the spec too. >
I'm a "better safe than sorry" sort of guy. I would rather code defensively against a poorly implemented API. However: "Upon successful completion, the function will open the file and return a non-negative integer representing the lowest numbered unused file descriptor. Otherwise, -1 is returned and errno is set to indicate the error. No files will be created or modified if the function returns -1." That is hardly anything that I would feel comfortable with. Lets break this down into all the areas that are ambiguous: "unused" file descriptor, define "unused." Is it unused ever, or currently unused? Could an API developer simply just increment file opens? What about just allocating a structure on each open, and returning its pointer cast to an int? Also notice that no mention of process separation exists, it could very well be that a file descriptor may be usable system wide, with the exceptions of stdin, stdout, and stderr. Nowhere does it say how the file descriptors are numbered. 1,2,3,4 sure, that's what you expect, but it isn't an explicitly documented behavior. What is documented, however, that it is a machine "int" and that the number will be positive and be the lowest "unused" descriptor (depending on the definition of "unused") This is the sort of thing that makes software brittle and likely to crash. Sure, you may be "right" in saying a "short int" is enough. Some developer creating a POSIX clib my think he is right doing something his way. What happens is that there is a potentially serious bug that will only show up at seemingly random times. The fact is that it is PostgreSQL that would be wrong, the API is documented as taking an "int." PostgreSQL casts it to a "short." What ever you read into the implementation of the API is wrong. The API is an abstraction and you should assume you don't know anything about it. ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq