Re: signed short fd

> pgsql(at)mohawksoft(dot)com 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.