Stop leaking file descriptors

[Neil Booth]

Hi Nathan,

Firstly, thanks for looking into this.

Nathan Sidwell wrote:-

> cpp will leak file descriptors when reincluding an idempotent header file.
> What happens is that open_file (cppfiles.c) will reopen the header,
> but stack_unclude_file will simply ignore it, forgetting to close the
> descriptor. With something like gtk, which reincludes a lot of
> such headers, you run out of file descriptors!

I cannot easily grok cppfiles.c; maybe just from lack of familiarity.
But it does seem hard to follow the thread of it.  When I had to redo
the multiple-include optimisation for the new token-at-a-time regime,
I wrote it so the "wrapper include" optimisation Zack put on the web
page (where a header file that only includes another gets optimised
away (recursively) next time it is included) would be fairly simple to
implement, or so I thought.  When I had a look at it a couple of days
ago, I couldn't fathom the semantics of buffers and files in
cppfiles.c to implement it.  When I get a chance, I want to have a
good look at cppfiles.c and see if I can't make the logic flow
clearer.

In short, I'm not at all surprised there are problems...

> the patch stops open_file re-opening a DO_NOT_REREAD header -- was
> there a reason it should really be re-opened? And makes sure that
> stack_include_file releases the file descriptor, if there was one.

Hmmm.  Maybe we should not even be getting as far as open_file if it's
flagged like that; I'm not at all sure.

> 	(stack_include_file): If DO_NOT_REREAD, close it if open.

This is definitely the wrong place.  To me, a file flagged
DO_NOT_REREAD should be closed when it is flagged DO_NOT_REREAD, not
when we accidentally discover this later.

Thoughts?

Neil.