On Tue, Sep 16, 2014 at 11:17 AM, FX <fxcoud...@gmail.com> wrote:
>>> 2014-09-05 Janne Blomqvist <j...@gcc.gnu.org>
>>>
>>> PR libfortran/62768
>>> * io/io.h (gfc_unit): Store C string for the filename.
>>> * io/close.c (st_close): Use gfc_unit.filename.
>>> * io/inquire.c (inquire_via_unit): Likewise.
>>> * io/open.c (new_unit): Likewise.
>>> (already_open): Likewise, unlink file before freeing filename.
>>> * io/unit.c (init_units): Likewise.
>>> (close_unit_1): Likewise.
>>> (filename_from_unit): Likewise.
>>> * io/unix.c (compare_file_filename): Likewise.
>>> (find_file0): Likewise.
>>> (delete_file): Likewise.
>
> OK, if you add a runtime testcase.
Thanks for the review, committed as r215307. I added the testcase
below as gfortran.dg/filename_null.f90:
! { dg-do run }
! PR 62768
! Filenames with embedded NULL characters are truncated, make sure
! inquire reports the correct truncated name.
program filename_null
implicit none
character(len=15), parameter :: s = "hello" // achar(0) // "world", &
s2 = "hello"
character(len=15) :: r
logical :: l
open(10, file=s)
inquire(unit=10, name=r)
if (r /= s2) call abort()
inquire(file=s2, exist=l)
if (.not. l) call abort()
close(10, status="delete")
end program filename_null
> I tried to think of other characters we might want to sanitize/special case,
> but at least on Unix/POSIX only NUL and / are fundamentally different. It
> might make sense to think about it for Windows targets.
IIRC on Windows only printable UTF-16 characters are allowed, and like
POSIX NULL and / are special. Anyway, if one does something which is
not allowed, the OS api's should report an error. The bug I fixed was
fundamentally about OS api's expecting null-terminated C strings, so
the strings were truncated in the Fortran->C string conversion before
calling the OS API's.
--
Janne Blomqvist
