This is the mail archive of the
mailing list for the GCC project.
Re: PATCH[libiberty] for Re: Mainline: C++ include files not found!
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: mstump at apple dot com, pfeifer at dbai dot tuwien dot ac dot at, gcc-patches at gcc dot gnu dot org,binutils at sources dot redhat dot com, gdb-patches at sources dot redhat dot com
- Date: Thu, 20 Feb 2003 15:46:39 -0500
- Subject: Re: PATCH[libiberty] for Re: Mainline: C++ include files not found!
- References: <20030215135157.GA23004@nevyn.them.org> <C5533C51-4430-11D7-B22E-003065A77310@apple.com> <20030220182105.GA7787@nevyn.them.org> <200302202026.h1KKQk711991@greed.delorie.com>
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":
> 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
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
MontaVista Software Debian GNU/Linux Developer