Re: sim/arm/armos.c: IsTTY [PATCH]

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Sat, 17 Sep 2005 23:44:32 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Sun, Sep 18, 2005 at 06:32:25AM +0300, Eli Zaretskii wrote:
> > > Date: Sat, 17 Sep 2005 18:37:28 -0400
> > > From: Daniel Jacobowitz <drow@false.org>
> > > Cc: Richard Earnshaw <rearnsha@gcc.gnu.org>, gdb-patches@sources.redhat.com
> > > 
> > >     Usage Note: Don't use FILENAME_MAX as the size of an array in which
> > > to store a file name! You can't possibly make an array that big! Use
> > > dynamic allocation (see section 3.2 Allocating Storage For Program
> > > Data) instead. 
> > 
> > That's a very strange advice, especially since there's gobs of code
> > out there that define arrays like that to store file names.  What's
> > the value of FILENAME_MAX on those systems where a file name can have
> > unlimited length?  Is it really larger than a typical stack
> > limitation?
> 
> It's looks like it has since been toned down as a matter of
> practicality, but yes: I believe that at one point it was INT_MAX.
> I.E. Much Too Big.
> 
> Ah, yes, Hurd throttles it to 1K in response to a limitation in their
> RPC mechanism.  But the developers were making noise about unthrottling
> it again someday.

FWIW, the correct way to deal with these issues is to dynamically
allocate the buffer, making the buffer bigger if it fails because the
buffer is too small:

  #ifndef _POSIX_PATH_MAX
  #define _POSIX_PATH_MAX 256
  #endif

  size_t len = _POSIX_PATH_MAX;
  char *buf = xmalloc(len);
  while (foo(..., buf, len) == -1 && errno == ENAMETOOLONG)
    {
      len *= 2;
      buf = xrealloc(buf, len);
    }

I used _POSIX_PATH_MAX here, but you could probably just as well
hardcode a sensible value.  Don't forget to free the buffer once
you're done with it ;-).

Mark