Re: signed short fd

> pgsql(at)mohawksoft(dot)com writes:
>> That is hardly anything that I would feel comfortable with. Lets break
>> this down into all the areas that are ambiguous:
>
> There isn't anything ambiguous about this, nor is it credible that there
> are implementations that don't follow the intent of the spec.

How do you know the intent of the spec? I have seen no meta discussion
about the behavior of the file descriptor integer returned from open. The
Steven's book makes no such assumptions, and the steven's book (Advanced
Programming in the UNIX Environment) is what people reference.

> Consider
> the standard paradigm for replacing stdout: you close(1) and then open()
> the target file. If the open() doesn't pick 1 as the fd, you're screwed.
> Every shell in the world would break atop such an implementation.

I said that stdin, stdout, and stderr would be treated differently as they
are on all platforms.

>
> It may well be the case that saving 4 bytes per VFD is useless
> micro-optimization. But the code isn't broken as it stands.

It most likely is not broken as it is, but it would be interesting to put
an assert(fd < 32768) in the code and see if it ever breaks. Never the
less, the spec DOES call for file fds to be a machine "int." All
acceptable coding practices would demand that since the API spec calls for
an int, the application should use an int.

This is the sort of thing that is caught and fixed in any standard code
review. Why is this an argument? What am I missing that you are defending?