From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30221 invoked by alias); 18 Sep 2005 09:04:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30206 invoked by uid 22791); 18 Sep 2005 09:04:28 -0000 Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 18 Sep 2005 09:04:28 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id j8I93ix6013613; Sun, 18 Sep 2005 11:03:44 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id j8I93imb005852; Sun, 18 Sep 2005 11:03:44 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id j8I93fTo025933; Sun, 18 Sep 2005 11:03:41 +0200 (CEST) Date: Sun, 18 Sep 2005 09:04:00 -0000 Message-Id: <200509180903.j8I93fTo025933@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: eliz@gnu.org, sjackman@gmail.com, rearnsha@gcc.gnu.org, gdb-patches@sources.redhat.com In-reply-to: <20050918034432.GA6990@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 17 Sep 2005 23:44:32 -0400) Subject: Re: sim/arm/armos.c: IsTTY [PATCH] References: <7f45d9390508151204ca0b146@mail.gmail.com> <20050830023718.GB16189@nevyn.them.org> <7f45d93905090709516f912861@mail.gmail.com> <1126170388.18092.16.camel@pc960.cambridge.arm.com> <7f45d93905090910237c63acf0@mail.gmail.com> <20050917223728.GL8777@nevyn.them.org> <20050918034432.GA6990@nevyn.them.org> X-SW-Source: 2005-09/txt/msg00159.txt.bz2 > Date: Sat, 17 Sep 2005 23:44:32 -0400 > From: Daniel Jacobowitz > > 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 > > > Cc: Richard Earnshaw , 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