Re: (Fwd) Re: Absolute paths in BFD

[Eli Zaretskii <eliz at delorie dot com>]

[Thanks to Mark for forwarding this to me.]

> Date sent:      	26 Apr 2000 15:31:54 -0700
> From:           	Ian Lance Taylor <ian@zembu.com>
>
>    > A few months ago someone posted a series of patches to handle this very 
> >
>    problem.  See: > >
>    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00584.html >
>    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00585.html >
>    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00586.html >
>    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00587.html >
>    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00588.html >
>    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00589.html >
>    http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00590.html
> 
> I feel like I would rather copy the names that gcc uses:
> IS_DIR_SEPARATOR, IS_PATH_SEPARATOR, HAVE_DOS_BASED_FILE_SYSTEM, etc.
> 
> In fact, I said that a long time ago:
>     http://sourceware.cygnus.com/ml/binutils/1999-q3/msg00596.html

In the conversation that followed the above message, I told you that
the macros I used in my patches are used in other GNU projects, like
Texinfo and Grep.  You then said that you were willing to accept them
as well.  So I patiently waited for the patches to be
reviewed/accepted.

If you want to reconsider that decision, I could rework the patches
(although I don't understand why the GCC's way of parameterizing these
macros is better than that of the other projects).  But please give me
some hope that the new patches will be reviewed and committed to the
Binutils CVS tree somewhat faster than the previous ones.  It can be
quite frustrating to go through all the coding and testing once again,
only to see the patches stuck in the queue for another 6 months ;-).

> Testing something like DOSISH_FILENAMES in binutils/ar.c looks wrong.
> DOSISH_FILENAMES is meaningful on the host, but binutils/ar.c deals
> with files that are specific to the target.

The code fragments conditioned on DOSISH_FILENAMES in ar.c do not
contradict the original code (which considers forward slashes only),
they _augment_ it.  That is, the code looks for forward slashes, and
then for backslashes.

So I don't think there's a problem here.  But if you think this might
be a problem for Windows-hosted development environments whose targets
can be harmed by this code, I could make those fragments conditioned
on __DJGPP__, where the host and the target are the same.

> The changes to binutils/strings.c and gprof/gmon_io.h assume that any
> system with O_BINARY has setmode and isatty, and I don't think that's
> true.

Please suggest an alternative.  Would you like a separate definition
for setmode?

As for isatty, I'm not aware of a C library that doesn't have it.  But
if you would like a separate macro for it, I can do that, too.