[Bug libfortran/60324] Handle arbitrarily long path names

[Bug libfortran/60324] Handle arbitrarily long path names

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-04-30
           Assignee|unassigned at gcc dot gnu.org      |jb at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Assigning to myself, working on a patch.

[Bug libfortran/60324] Handle arbitrarily long path names

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324

--- Comment #2 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Author: jb
Date: Thu May 22 03:51:25 2014
New Revision: 210738

URL: http://gcc.gnu.org/viewcvs?rev=210738&root=gcc&view=rev
Log:
PR 60324 Handle long path names, don't use PATH_MAX.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/config.h.in
    trunk/libgfortran/configure
    trunk/libgfortran/configure.ac
    trunk/libgfortran/io/close.c
    trunk/libgfortran/io/open.c
    trunk/libgfortran/io/unit.c
    trunk/libgfortran/io/unix.c
    trunk/libgfortran/io/unix.h
    trunk/libgfortran/libgfortran.h
    trunk/libgfortran/runtime/main.c
    trunk/libgfortran/runtime/string.c

[Bug libfortran/60324] Handle arbitrarily long path names

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324

--- Comment #3 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Author: jb
Date: Thu May 22 21:17:29 2014
New Revision: 210827

URL: http://gcc.gnu.org/viewcvs?rev=210827&root=gcc&view=rev
Log:
PR 60324 Handle long path names, don't use PATH_MAX.

2014-05-23  Janne Blomqvist  <jb@gcc.gnu.org>

    PR libfortran/60324
    * runtime/string.c: Include stdlib.h.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/runtime/string.c

[Bug libfortran/60324] Handle arbitrarily long path names

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |fxcoudert at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #4 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
I take it this one can be closed :)

[Bug libfortran/60324] Handle arbitrarily long path names

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324

Janne Blomqvist <jb at gcc dot gnu.org> changed:

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

--- Comment #5 from Janne Blomqvist <jb at gcc dot gnu.org> ---
There are still a number of cases (IO intrinsics, mostly) where we create a
null-terminated copy of a potentially unbounded input string on the stack,
leading to a potential stack overflow crash. But the stack limit is usually
several MB versus a few KB for PATH_MAX, so unlikely to be an issue in
practice.

[Bug libfortran/60324] Handle arbitrarily long path names

[townsend at astro dot wisc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324

Rich Townsend <townsend at astro dot wisc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |townsend at astro dot wisc.edu

--- Comment #6 from Rich Townsend <townsend at astro dot wisc.edu> ---
This change introduces a dependency on strndup -- which, alas, is absent from
libSystem in OS X 10.6 (Snow Leopard), although later releases of OS X include
it. This isn't a problem per se, as it appears that an internal strndup will be
built if a system one can't be found.

Howver, today, I've run into the problem that when I build gcc/gfortran (trunk)
on 10.9, I can't then use the compiler on 10.6 due to the reference in
libgfortran (and perhaps elsewhere) to the (missing) system strndup. Any
suggestions for workarounds? Can I hack libgfortran/configure.ac to force the
internal strndup to be used?

cheers,

Rich

[Bug libfortran/60324] Handle arbitrarily long path names

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324

--- Comment #7 from Janne Blomqvist <jb at gcc dot gnu.org> ---
(In reply to Rich Townsend from comment #6)
> This change introduces a dependency on strndup -- which, alas, is absent
> from libSystem in OS X 10.6 (Snow Leopard), although later releases of OS X
> include it. This isn't a problem per se, as it appears that an internal
> strndup will be built if a system one can't be found.

Indeed. This is similar to how libgfortran handles a lot of functionality
beyond basic C89 + POSIX.

> Howver, today, I've run into the problem that when I build gcc/gfortran
> (trunk) on 10.9, I can't then use the compiler on 10.6 due to the reference
> in libgfortran (and perhaps elsewhere) to the (missing) system strndup. Any
> suggestions for workarounds? Can I hack libgfortran/configure.ac to force
> the internal strndup to be used?

I think hacking configure.ac is how people doing cross-compilers etc. typically
do it, so it should work, yes. configure.ac does already have such a hard-coded
list for newlib targets, take a look at that, it ought to be relatively
straightforward to create a similar list for OSX.

Another alternative would be for you to compile gfortran on your 10.6 system,
the result should be usable on a 10.9 system as well.

The strnlen/strndup implementations provided by the target system might be
faster compared to the simple fallback implementations in libgfortran, but for
the usage in libgfortran it's unlikely to be an issue.

[Bug libfortran/60324] Handle arbitrarily long path names

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324

--- Comment #8 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Author: jb
Date: Thu Nov 13 12:05:01 2014
New Revision: 217480

URL: https://gcc.gnu.org/viewcvs?rev=217480&root=gcc&view=rev
Log:
PR 60324 Unbounded stack allocations in libgfortran.

2014-11-13  Janne Blomqvist  <jb@gcc.gnu.org>

    PR libfortran/60324
    * configure: Regenerated.
    * configure.ac (AM_CFLAGS): Add Werror=vla.
    * libgfortran.h (gfc_alloca): Remove macro.
    (fc_strdup_notrim): New prototype.
    * intrinsics/access.c (access_func): Use fc_strdup rather than
    stack allocation.
    * intrinsics/chdir.c (chdir_i4_sub): Likewise.
    (chdir_i8_sub): Likewise.
    * intrinsics/chmod.c (chmod_internal): New function, move logic
    here.
    (chmod_func): Call chmod_internal.
    * intrinsics/env.c (getenv): Use fc_strdup rather than stack
    allocation.
    (get_environment_variable_i4): Likewise.
    * intrinsics/execute_command_line.c (execute_command_line):
    Likewise.
    * intrinsics/hostnm.c (hostnm_0): New function, use static buffer
    rather than VLA.
    (hostnm_i4_sub): Call hostnm_0.
    (hostnm_i8_sub): Likewise.
    (hostnm): Likewise.
    * intrinsics/link.c (link_internal): New function, use fc_strdup
    rather than stack allocation.
    (link_i4_sub): Call link_internal.
    (link_i8_sub): Likewise.
    (link_i4): Likewise.
    (link_i8): Likewise.
    * intrinsics/perror.c (perror_sub): Use fc_strdup rather than
    stack allocation.
    * intrinsics/random.c (random_seed_i4): Use static buffer rather
    than VLA, use _Static_assert to make sure it's big enough.
    * intrinsics/rename.c (rename_internal): New function, use
    fc_strdup rather than stack allocation.
    (rename_i4_sub): Call rename_internal.
    (rename_i8_sub): Likewise.
    (rename_i4): Likewise.
    (rename_i8): Likewise.
    * intrinsics/stat.c (stat_i4_sub_0): Use fc_strdup rather than
    stack allocation.
    (stat_i8_sub_0): Likewise.
    * intrinsics/symlink.c (symlnk_internal): New function, use
    fc_strdup rather than stack allocation.
    (symlnk_i4_sub): Call symlnk_internal.
    (symlnk_i8_sub): Likewise.
    (symlnk_i4): Likewise.
    (symlnk_i8): Likewise.
    * intrinsics/system.c (system_sub): Use fc_strdup rather than
    stack allocation.
    * intrinsics/unlink.c (unlink_i4_sub): Likewise.
    * io/file_pos.c (READ_CHUNK): Make it a macro rather than variable.
    * io/list_read.c (nml_get_obj_data): Use fixed stack buffer, fall
    back to xmalloc/free for large sizes.
    * io/read.c (read_f): Likewise.
    * io/transfer.c (MAX_READ): Make it a macro rather than variable.
    (WRITE_CHUNK): Likewise.
    * io/write_float.def (write_float): Use fixed stack buffer, fall
    back to xmalloc/free for large sizes.
    * runtime/string.c (fc_strdup_notrim): New function.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/configure
    trunk/libgfortran/configure.ac
    trunk/libgfortran/intrinsics/access.c
    trunk/libgfortran/intrinsics/chdir.c
    trunk/libgfortran/intrinsics/chmod.c
    trunk/libgfortran/intrinsics/env.c
    trunk/libgfortran/intrinsics/execute_command_line.c
    trunk/libgfortran/intrinsics/hostnm.c
    trunk/libgfortran/intrinsics/link.c
    trunk/libgfortran/intrinsics/perror.c
    trunk/libgfortran/intrinsics/random.c
    trunk/libgfortran/intrinsics/rename.c
    trunk/libgfortran/intrinsics/stat.c
    trunk/libgfortran/intrinsics/symlnk.c
    trunk/libgfortran/intrinsics/system.c
    trunk/libgfortran/intrinsics/unlink.c
    trunk/libgfortran/io/file_pos.c
    trunk/libgfortran/io/list_read.c
    trunk/libgfortran/io/read.c
    trunk/libgfortran/io/transfer.c
    trunk/libgfortran/io/write_float.def
    trunk/libgfortran/libgfortran.h
    trunk/libgfortran/runtime/string.c

[Bug libfortran/60324] Handle arbitrarily long path names

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324

Janne Blomqvist <jb at gcc dot gnu.org> changed:

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

--- Comment #9 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Fixed on trunk, closing.

[Bug libfortran/60324] Handle arbitrarily long path names

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324

--- Comment #10 from Janne Blomqvist <jb at gcc dot gnu.org> ---
Author: jb
Date: Sun Nov 16 01:56:54 2014
New Revision: 217623

URL: https://gcc.gnu.org/viewcvs?rev=217623&root=gcc&view=rev
Log:
PR 60324 VLA related fixes to random number generator.

2014-11-16  Janne Blomqvist  <jb@gcc.gnu.org>

    PR libfortran/60324
    * intrinsics/random.c (kiss_size): Rename to KISS_SIZE, make it a
    macro instead of a variable.
    (random_seed_i4): Make seed correct size, remove assert, KISS_SIZE
    related changes.
    (random_seed_i8): KISS_SIZE related changes.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/intrinsics/random.c