On Fri, May 23, 2014 at 5:23 AM, Hans-Peter Nilsson h...@bitrange.com wrote:
I'm not defending the existing solution, I was observing your
patch breaking it. The obvious fix is adjustments by means of
this existing machinery; done. I suggest breakages be fixed
without shooting messengers or
On Mon, 19 May 2014, Janne Blomqvist wrote:
Hello,
some systems such as GNU Hurd, don't define PATH_MAX at all, and on
some other systems many syscalls apparently work for paths longer than
PATH_MAX. Thus GFortran shouldn't truncate paths to PATH_MAX
characters, but rather use heap allocated
On Thu, May 22, 2014 at 6:36 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
On Mon, 19 May 2014, Janne Blomqvist wrote:
Hello,
some systems such as GNU Hurd, don't define PATH_MAX at all, and on
some other systems many syscalls apparently work for paths longer than
PATH_MAX. Thus GFortran
On Fri, 23 May 2014, Janne Blomqvist wrote:
On Thu, May 22, 2014 at 6:36 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
This patch broke build for newlib targets; you need AC_DEFINE
clauses for those in the if-then-leg where you patched the
else-leg.
Do I?
The way that configure-clause
On Mon, May 19, 2014 at 11:40:06PM +0300, Janne Blomqvist wrote:
Hello,
some systems such as GNU Hurd, don't define PATH_MAX at all, and on
some other systems many syscalls apparently work for paths longer than
PATH_MAX. Thus GFortran shouldn't truncate paths to PATH_MAX
characters, but
On Wed, May 21, 2014 at 4:35 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Mon, May 19, 2014 at 11:40:06PM +0300, Janne Blomqvist wrote:
Hello,
some systems such as GNU Hurd, don't define PATH_MAX at all, and on
some other systems many syscalls apparently work for paths longer
Hello,
some systems such as GNU Hurd, don't define PATH_MAX at all, and on
some other systems many syscalls apparently work for paths longer than
PATH_MAX. Thus GFortran shouldn't truncate paths to PATH_MAX
characters, but rather use heap allocated buffers limited only by the
available memory.
