From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21547 invoked by alias); 20 Feb 2003 20:47:58 -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 21488 invoked from network); 20 Feb 2003 20:47:55 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 20 Feb 2003 20:47:55 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18lzTm-0001kV-00; Thu, 20 Feb 2003 16:47:46 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18lxaZ-00067j-00; Thu, 20 Feb 2003 15:46:39 -0500 Date: Thu, 20 Feb 2003 20:47:00 -0000 From: Daniel Jacobowitz To: DJ Delorie Cc: mstump@apple.com, pfeifer@dbai.tuwien.ac.at, gcc-patches@gcc.gnu.org, binutils@sources.redhat.com, gdb-patches@sources.redhat.com Subject: Re: PATCH[libiberty] for Re: Mainline: C++ include files not found! Message-ID: <20030220204639.GA22900@nevyn.them.org> Mail-Followup-To: DJ Delorie , mstump@apple.com, pfeifer@dbai.tuwien.ac.at, gcc-patches@gcc.gnu.org, binutils@sources.redhat.com, gdb-patches@sources.redhat.com References: <20030215135157.GA23004@nevyn.them.org> <20030220182105.GA7787@nevyn.them.org> <200302202026.h1KKQk711991@greed.delorie.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302202026.h1KKQk711991@greed.delorie.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-02/txt/msg00495.txt.bz2 On Thu, Feb 20, 2003 at 03:26:46PM -0500, DJ Delorie wrote: > > For libiberty-only patches, please cc the gdb and binutils mailing > lists as well. > > Note that DJGPP has a function similar to realpath called "_truename": > > http://www.delorie.com/djgpp/doc/libc/libc_776.html > > But I don't think it would make any difference in this case, since > djgpp doesn't support symlinked directories. DJGPP *does* support > readlink() though (.exe's are allowed to be symlinks, we fake it). It > would be nice if the fall-through case at least tried readlink() (if > available). My initial reluctance was that readlink isn't guaranteed to give us something that we can append to the dirname and access. And I'd need to drag in both stat and readlink, and some bits for HOST_EXECUTABLE_SUFFIX that I'm not entirely sure of. Would you rather I add this, or can we leave it until someone needs this on DJGPP? > Case 2a will never happen - we can't guarantee the ability to run that > configure test. I'll just delete it. > Note that I'm not a big fan of libiberty itself using the xmalloc > functions. Doing so automatically precludes using those functions > (that use xmalloc) in bfd (at least, maybe gdb also) because an > uncontrolled exit is undesirable, and/or the use of printf may be > problematic. If it were up to me (and I'm willing to let this one > slide) I'd have the return value be defined as: > > 1. The same pointer as "filename" (i.e. no malloc), or > 2. A NULL pointer (i.e. error), or > 3. Some other pointer (malloc'd, must be free'd) > > Doing the malloc "just because" seems wasteful to me. Optionally returning filename seems risky to me, personally. I'd go for just 2+3 and return NULL if we don't get a result; but I like the simplicity of this interface as it is. You've got a good point on the xmalloc thing. How about use malloc and return NULL on allocation failure? And strdup instead of xstrdup. > For libiberty_NEED_DECLARATION, you need to include "confdefs.h" or > you won't get any of the HAVE_ macros. Oh, that's cute. I copied this function from BFD, which has the same problem. Fixed. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer