Messages in this thread | | | Date | Thu, 27 Nov 1997 00:34:59 +1100 | From | Jeremy Fitzhardinge <> | Subject | Re: file ID redesign proposal |
| |
Ingo Molnar wrote: > 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?
Yep. Maybe fewer programs, but a significant number never the less. As I said, this behaviour is built into shell scripts all over the place.
> > A newly execd program could reasonably expect this to work: > > > > int main() > > { > > int fd = dup(2); > > assert(fd == 3); > > ...
Actually, this example is wrong. If it were started with fd 3 already open (a.out 3> /dev/null), the assert would fail anyway.
> 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.
I can assure you there's programs out there which presume this will work. Rememer that ld.so does lots of things to fds before main is called; similarly, unknown things happen inside libraries. A program can't assume any fixed behaviour from your scheme, regardless of what stage of execution its in.
On the other hand, I might be wrong. Try it, and see what happens; if things break, you've got (most) of the source.
J
| |