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

Mark Kettenis
2005-09-18T09:04:34Z

> 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