This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Another weird CPP result
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Neil Booth <neil at daikokuya dot co dot uk>
- Cc: Jason R Thorpe <thorpej at wasabisystems dot com>, gcc-bugs at gcc dot gnu dot org
- Date: Mon, 15 Jul 2002 23:48:32 -0700
- Subject: Re: Another weird CPP result
- References: <20020716024341.3B1E17DA4@yeah-baby.shagadelic.org> <20020715204007.A13737@dr-evil.shagadelic.org> <20020716062917.GA29448@daikokuya.co.uk>
On Tue, Jul 16, 2002 at 07:29:17AM +0100, Neil Booth wrote:
[cmdline-dM-M.c]
> There is an explicit check for stdout in cpplib to avoid this for that
> one case (cppinit.c:1075). The problem is to avoid it in general.
> Zack mentioned reworking the code so that cpplib didn't handle opening
> and closing FILE *s, instead the client would just pass them and handle
> the open / close itself. It hasn't been done yet, though.
I just haven't gotten around to it. It should get done for 3.3. Does
it need to be fixed for 3.1.1? If so I'll bump it up the list.
> I'm still not clear how this solves the problem in general, since
> different paths can refer to the same file. Under UNIX we can check
> dev/inode pairs, but I'm not aware of a proper portable solution.
You are imagining a situation where, for instance, the -M file and the
normal output are hard or symbolic links to the same inode? The user
must have done that deliberately; I'm fine with saying that that's not
supported.
zw