[Bug gas/23153] gas: distinct input and output files are not properly detected on not-fully-emulated POSIX platforms

[pexu at sourceware dot mail.kapsi.fi]

https://sourceware.org/bugzilla/show_bug.cgi?id=23153

--- Comment #2 from Pekka Seppänen <pexu at sourceware dot mail.kapsi.fi> ---
Hi Nick,

My apologies for a late response; The patch appears to work just fine as
expected.

However, it just occured to me that IEEE Std 1003.1 (2016 edition), i.e. the
POSIX specs, state that ``The st_ino and st_dev fields taken together uniquely
identify the file within the system'' (pg. 392), so I guess the attached patch
shouldn't be applied but one that fails only if the st_dev is the same, too
(and has the non-POSIX compliant quirk workaround enabled way or another).

By the way, the GCC folks simply do not do any stat()s for MinGW targets (so
any compliant system does not get the zero serial number ignored).

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23153

--- Comment #3 from Nick Clifton <nickc at redhat dot com> ---
Hi Pekka,

Post by pexu at sourceware dot mail.kapsi.fi
so I guess the
attached patch shouldn't be applied but one that fails only if the st_dev is
the same, too

Can you confirm that MingW always returns 0 for the st_dev field as well ?
(I assume that it does, but I would like to make sure). If so then I
will apply the patch modified as you suggest.

Cheers
Nick

[pexu at sourceware dot mail.kapsi.fi]

https://sourceware.org/bugzilla/show_bug.cgi?id=23153

--- Comment #4 from Pekka Seppänen <pexu at sourceware dot mail.kapsi.fi> ---
(In reply to Nick Clifton from comment #3)

Post by nickc at redhat dot com
Hi Pekka,
Can you confirm that MingW always returns 0 for the st_dev field as well ?
(I assume that it does, but I would like to make sure). If so then I
will apply the patch modified as you suggest.

No, MinGW populates the st_dev field with some apparently non-random value
(i.e. might be zero or not, but it's not always zero). I didn't check from what
it acquires or derives that value, but it's neither always zero nor the same
what Cygwin's stat() will return.

Only the st_ino is always zero, which is indeed a bit shame.

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23153

--- Comment #5 from Nick Clifton <nickc at redhat dot com> ---
Hi Pekka,

Post by pexu at sourceware dot mail.kapsi.fi
No, MinGW populates the st_dev field with some apparently non-random value

In which case I will go with the original patch. I know that technically
a valid file might have an inode of 0, but I think that in practice this
will never happen since most file systems do not use inode 0, (at least not for
ordinary files). Or if they do, it is for a special purpose, such as marking
that the file has been deleted.

Cheers
Nick

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23153

--- Comment #6 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nick Clifton <***@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c3533c4c7c5db84b27e4dc8994a3c3a893077c03

commit c3533c4c7c5db84b27e4dc8994a3c3a893077c03
Author: Nick Clifton <***@redhat.com>
Date: Mon May 14 13:05:02 2018 +0100

Fix a problem in the assembler when checking for overlapping input and
output files on non-POSIX compliant systems.

PR 23153
* as.c (main): When checking for an output file that is also an
input file, also check that the inode is not zero.

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23153

Nick Clifton <nickc at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED

--- Comment #7 from Nick Clifton <nickc at redhat dot com> ---
Patch applied.

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23153

Florian Weimer <fweimer at redhat dot com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |fweimer at redhat dot com

--- Comment #8 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Nick Clifton from comment #5)

Post by nickc at redhat dot com
Hi Pekka,

Post by pexu at sourceware dot mail.kapsi.fi
No, MinGW populates the st_dev field with some apparently non-random value

In which case I will go with the original patch. I know that technically
a valid file might have an inode of 0, but I think that in practice this
will never happen since most file systems do not use inode 0, (at least not
for ordinary files). Or if they do, it is for a special purpose, such as
marking that the file has been deleted.

On XFS, inode 0 can be used for regular files created by applications. Only
newer versions have code in them to avoid inode 0. Some old applications have
comments that inode 0 indicates a deleted directory entry, but this appears to
be an invention and not something that has ever occurred in practice.

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23153

--- Comment #9 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Florian Weimer from comment #8)

Post by fweimer at redhat dot com
On XFS, inode 0 can be used for regular files created by applications. Only
newer versions have code in them to avoid inode 0. Some old applications
have comments that inode 0 indicates a deleted directory entry, but this
appears to be an invention and not something that has ever occurred in
practice.

My assumption is that even if inode 0 is valid for the filesystem it is
extremely unlikely that this value will just happen to be used for an assembler
input file,
and extremely unlucky if this file is then used as the output from the
assembler too. So basically, it is not worth worrying about.

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23153

--- Comment #10 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Nick Clifton from comment #9)

Post by nickc at redhat dot com
My assumption is that even if inode 0 is valid for the filesystem it is
extremely unlikely that this value will just happen to be used for an
assembler input file,
and extremely unlucky if this file is then used as the output from the
assembler too. So basically, it is not worth worrying about.

Agreed. If this safety check does not kick in because the input and output
files are the same and have inode 0, then this is not a huge problem.

I just wanted to point out that inode number 0 is *not* special on most systems
because that's a common misconception.