This is the mail archive of the
mailing list for the GDB project.
Re: sim/arm/armos.c: IsTTY [PATCH]
> Date: Sat, 17 Sep 2005 23:44:32 -0400
> From: Daniel Jacobowitz <firstname.lastname@example.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 <email@example.com>
> > > Cc: Richard Earnshaw <firstname.lastname@example.org>, email@example.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:
#define _POSIX_PATH_MAX 256
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 ;-).