From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: drow@false.org
Cc: gdb-patches@sourceware.org
Subject: Re: RFA: Support Windows extended error numbers in safe_strerror
Date: Wed, 08 Feb 2006 21:08:00 -0000 [thread overview]
Message-ID: <200602082107.k18L7xRh013417@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <20060208000855.GA5040@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 7 Feb 2006 19:08:55 -0500)
> Date: Tue, 7 Feb 2006 19:08:55 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> On Mon, Feb 06, 2006 at 05:58:29PM -0500, Daniel Jacobowitz wrote:
> > Could you explain why you don't like this one a little more clearly?
> >
> > Of course it'd be possible to write a complete replacement; I'd just
> > replace the call to the system strerror with a switch statement and
> > copy the strings out of the system runtime, or out of some other
> > standard source. But I don't see why that's any better than this, and
> > it's gratuituous duplication of information, so I'd like to understand
> > what you dislike about it.
> >
> > If it's the #define strerror that you dislike, two comments:
> >
> > - I could put an #ifdef around the one and only call to strerror
> > instead, in utils.c. I'd be perfectly happy with that.
> >
> > - I can't override the system strerror by defining my own copy; that
> > would be prone to breakage due to the workings of
> > __attribute__((dllimport)). I discussed that with Chris before posting
> > this version.
>
> Hi Mark,
>
> Have you had a chance to think about this? I realize it's only been a
> day, but I'm trying not to let these patches linger too long. I'd
> really like to understand what folks dislike about this patch, so
> that I can improve it. Same for the other patch; I replied to you
> about select.
I really think that we should drop MinGW support, and that the people
who want GDB on windows should work on fixing the apparent problems
with Cygwin. I cannot image that Cygwin is unique in having "DLL
hell" problem. People certainly must have found a proper solution for
this by now.
My dislike for this stuff is probably there because where I've been
cleaning out much of the host-specific quirks, this MinGW support
seems to add back a lot special tweaks, and since Windows is so
different from Unix-like systems, there's absolutely no hope, things
can be unified. That, together with the reintroduction of xm.h, seems
like a giant leap backwards to me. I really don't like that xm.h is
back now, since it sets a precedent. People have used these files for
quick hacks in the past, and the new xm.h will make it harder to tell
people that's not acceptable. I think there is a better approach
though. How about having the implementation of safe_strerror() and
gdb_select() in mingw-hdep.c and move the (trivial) existing
implementations of these functions to a new posix-hdep.c?
Speaking about gdb_select(), a really bad thing about your patch is
that we now have gdb_select(), but that some code still uses select()
and that the difference matters! Oh and there's a pasto in
gdb_select.h:
+#endif /* !defined(GDB_STRING_H) */
In light of the above, the following comment in ser-tcp.h is a plain
lie ;-):
/* Serial interface for raw TCP connections on Un*x like systems.
Mark
next prev parent reply other threads:[~2006-02-08 21:08 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-03 21:55 Daniel Jacobowitz
2006-02-03 23:25 ` Mark Kettenis
2006-02-03 23:39 ` Christopher Faylor
2006-02-04 3:27 ` Daniel Jacobowitz
2006-02-04 6:29 ` Jim Blandy
2006-02-04 10:33 ` Eli Zaretskii
2006-02-04 10:59 ` Eli Zaretskii
2006-02-04 14:35 ` Mark Kettenis
2006-02-04 14:52 ` Daniel Jacobowitz
2006-02-04 15:14 ` Eli Zaretskii
2006-02-05 0:15 ` Christopher Faylor
2006-02-05 4:46 ` Eli Zaretskii
2006-02-05 19:34 ` Christopher Faylor
2006-02-05 19:49 ` Daniel Jacobowitz
2006-02-05 20:19 ` Eli Zaretskii
2006-02-05 20:22 ` Daniel Jacobowitz
2006-02-05 21:50 ` Christopher Faylor
2006-02-05 21:57 ` Daniel Jacobowitz
2006-02-05 22:33 ` Christopher Faylor
2006-02-05 22:41 ` Daniel Jacobowitz
2006-02-06 6:35 ` Christopher Faylor
2006-02-06 17:26 ` Daniel Jacobowitz
2006-02-05 22:59 ` Eli Zaretskii
2006-02-05 22:47 ` Eli Zaretskii
2006-02-06 2:41 ` Daniel Jacobowitz
2006-02-06 4:20 ` Eli Zaretskii
2006-02-05 22:57 ` Eli Zaretskii
2006-02-05 22:44 ` Christopher Faylor
2006-02-05 23:07 ` Eli Zaretskii
2006-02-06 5:14 ` Christopher Faylor
2006-02-06 7:20 ` Eli Zaretskii
2006-02-06 8:47 ` Corinna Vinschen
2006-02-06 12:07 ` Bob Rossi
2006-02-06 14:23 ` Daniel Jacobowitz
2006-02-06 18:37 ` Eli Zaretskii
2006-02-04 10:03 ` Eli Zaretskii
2006-02-05 0:27 ` Christopher Faylor
2006-02-05 2:01 ` Daniel Jacobowitz
2006-02-05 4:49 ` Eli Zaretskii
2006-02-05 7:39 ` Jim Blandy
2006-02-05 20:01 ` Eli Zaretskii
2006-02-05 20:20 ` Daniel Jacobowitz
2006-02-05 22:45 ` Eli Zaretskii
2006-02-06 2:38 ` Daniel Jacobowitz
2006-02-05 4:48 ` Eli Zaretskii
2006-02-04 1:06 ` Jim Blandy
2006-02-04 3:00 ` Daniel Jacobowitz
2006-02-04 6:22 ` Ian Lance Taylor
2006-02-04 10:29 ` Eli Zaretskii
2006-02-04 13:53 ` Mark Kettenis
2006-02-04 15:17 ` Eli Zaretskii
2006-02-04 10:24 ` Eli Zaretskii
2006-02-04 15:33 ` Mark Kettenis
2006-02-04 15:35 ` Eli Zaretskii
2006-02-04 10:20 ` Eli Zaretskii
2006-02-04 13:14 ` Mark Kettenis
2006-02-05 7:41 ` Jim Blandy
2006-03-02 0:53 ` Michael Snyder
2006-02-04 11:58 ` Eli Zaretskii
2006-02-04 14:53 ` Daniel Jacobowitz
2006-02-04 15:09 ` Eli Zaretskii
2006-02-04 15:57 ` David Ayers
2006-02-06 17:35 ` Daniel Jacobowitz
2006-02-06 17:54 ` Christopher Faylor
2006-02-06 18:23 ` Jim Blandy
2006-02-06 19:08 ` Eli Zaretskii
2006-02-06 19:58 ` Daniel Jacobowitz
2006-02-06 20:59 ` Daniel Jacobowitz
2006-02-06 22:55 ` Mark Kettenis
2006-02-06 22:58 ` Daniel Jacobowitz
2006-02-08 0:08 ` Daniel Jacobowitz
2006-02-08 21:08 ` Mark Kettenis [this message]
2006-02-08 21:12 ` Bob Rossi
2006-02-08 23:17 ` Mark Kettenis
2006-02-08 23:23 ` Daniel Jacobowitz
2006-02-09 0:12 ` Joel Brobecker
2006-02-09 1:54 ` Bob Rossi
2006-02-09 7:47 ` Eli Zaretskii
2006-02-09 9:18 ` Jim Blandy
2006-02-08 21:54 ` Eli Zaretskii
2006-02-08 23:10 ` Mark Kettenis
2006-02-08 23:22 ` Daniel Jacobowitz
2006-02-09 14:40 ` Mark Kettenis
2006-02-09 15:14 ` Daniel Jacobowitz
2006-02-09 20:24 ` Eli Zaretskii
2006-02-09 8:00 ` Eli Zaretskii
2006-02-09 14:44 ` Mark Kettenis
2006-02-09 14:57 ` Daniel Jacobowitz
2006-02-09 20:40 ` Eli Zaretskii
2006-02-09 21:06 ` Daniel Jacobowitz
2006-02-09 22:13 ` Eli Zaretskii
2006-02-09 20:26 ` Eli Zaretskii
2006-02-09 22:37 ` Daniel Jacobowitz
2006-02-10 7:53 ` Eli Zaretskii
2006-02-10 16:18 ` Christopher Faylor
2006-02-10 16:49 ` Daniel Jacobowitz
2006-02-10 18:18 ` Eli Zaretskii
2006-02-10 21:56 ` Daniel Jacobowitz
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=200602082107.k18L7xRh013417@elgar.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
/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