On Wed, 26 Nov 1997, Jeremy Fitzhardinge wrote:
> Lots of programs are perfectly in their rights to expect the traditional
> "next free fd" behaviour. The most troublesome will be the shells: not
> only do they themselves use it, they pass on that behaviour to shell
> scripts. I'd expect that any program which uses mildly complex fd
> manipulation takes advantage of this behaviour.
>
> The idiom which is most likely to break is
>
> close_all();
> open("/dev/ttyX", O_RDWR);
> dup();
> dup();
this is the 1) workaround for ID 0,1,2. Question is, does code expect it
for 3,4,5.... too?
> A newly execd program could reasonably expect this to work:
>
> int main()
> {
> int fd = dup(2);
> assert(fd == 3);
> ...
new processes get forward-IDs, and LIFO (or FIFO) when reusing IDs, so i
expect the above case to work out of box. What breaks are such cases:
open();
open();
close(x);
open();
close(y);
fd = dup(2);
assert(fd == 3);
so the real breakage is: applications cannot expect to get first-free ID
>= 3 when _reusing_ file IDs. Eg. an application allocates all files from
0 to 100, then frees 97, 51 and 77, and expects the next open() to give ID
51.
-- mingo