https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387
Francois-Xavier Coudert changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
--- Comment #6 from toon at moene dot org 2009-09-20 17:03 ---
It seems we have exhausted the arguments in this case.
The best cause of action seems to be to document that gfortran won't allow to
open dangling symlinks with STATUS='NEW'.
This bug report remains open until that is
--- Comment #1 from toon at moene dot org 2009-09-17 13:26 ---
Perhaps the system call 'access' can provide help here.
From the man page (man 2 access):
access() checks whether the calling process can access the file pathname.
If pathname is a symbolic link, it is dereferenced.
The
--- Comment #2 from kargl at gcc dot gnu dot org 2009-09-17 14:59 ---
This is opening a can of worms.
ln -s aap noot
touch app
program a
open(unit=10, file='noot', status='old')
write(10,'(A)') 'Deleted file'
close(10, status='delete')
end program a
Please audit all Fortran
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-09-17 19:15
---
I agree, this is enhancement only. Code that relies on or expects consistent
behavior when the users has created and symlink is likely not protable. See
http://gcc.gnu.org/ml/fortran/2009-09/msg00107.html as
--- Comment #4 from toon at moene dot org 2009-09-17 19:57 ---
In response to reply 2 (thanks Steve), we might be able to exploit the system
call access to at least solve the inconsistency between INQUIRE and OPEN:
man 2 access
ENOENT A component of pathname does not exist or
--- Comment #5 from kargl at gcc dot gnu dot org 2009-09-18 03:52 ---
For additional comments, see
http://gcc.gnu.org/ml/fortran/2009-09/msg00119.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41387
