Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: DJ Delorie <dj@redhat.com>
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!
Date: Thu, 20 Feb 2003 20:47:00 -0000	[thread overview]
Message-ID: <20030220204639.GA22900@nevyn.them.org> (raw)
In-Reply-To: <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":
> 
> 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


       reply	other threads:[~2003-02-20 20:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20030215135157.GA23004@nevyn.them.org>
     [not found] ` <C5533C51-4430-11D7-B22E-003065A77310@apple.com>
     [not found]   ` <20030220182105.GA7787@nevyn.them.org>
     [not found]     ` <200302202026.h1KKQk711991@greed.delorie.com>
2003-02-20 20:47       ` Daniel Jacobowitz [this message]
2003-02-20 21:15         ` DJ Delorie
2003-02-20 21:50           ` Daniel Jacobowitz
2003-02-20 22:01             ` DJ Delorie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030220204639.GA22900@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=binutils@sources.redhat.com \
    --cc=dj@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=mstump@apple.com \
    --cc=pfeifer@dbai.tuwien.ac.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox