From: Pedro Alves <palves@redhat.com>
To: Yao Qi <yao@codesourcery.com>, gdb-patches@sourceware.org
Cc: gregory.0xf0@gmail.com, Joel Brobecker <brobecker@adacore.com>
Subject: Re: gnulib's errno module was imported
Date: Fri, 14 Nov 2014 11:47:00 -0000 [thread overview]
Message-ID: <5465EBAD.3070108@redhat.com> (raw)
In-Reply-To: <87oasaibe6.fsf@codesourcery.com>
On 11/14/2014 05:44 AM, Yao Qi wrote:
> However, we've already had a conclusion that we don't import gnulib's
> errno module because it has some compatibility issues with libiconv
> (discussed in https://sourceware.org/ml/gdb-patches/2012-12/msg00554.html).
> AFAICS, the argument that not having errno module at that moment is
> still valid today.
I think this will keep haunting and blocking us until we fix it.
Can we reevaluate this?
To recap, the issue is that GNU iconv does this:
/* Get errno declaration and values. */
#include <errno.h>
/* Some systems, like SunOS 4, don't have EILSEQ. Some systems, like BSD/OS,
have EILSEQ in a different header. On these systems, define EILSEQ
ourselves. */
#ifndef EILSEQ
#define EILSEQ @EILSEQ@
#endif
That's in:
http://git.savannah.gnu.org/cgit/libiconv.git/tree/include/iconv.h.in
The "different header" mentioned is wchar.h. This is handled in:
http://git.savannah.gnu.org/cgit/libiconv.git/tree/m4/eilseq.m4
which defines @EILSEQ@ to EINVAL if EILSEQ isn't found in
either errno.h or wchar.h.
As we dropped support for both SunOS 4 or old BSD/OS, maybe we
don't need to care about the wchar.h issue anymore.
Still, AFAICS, gnulib's m4/errno_h.m4 doesn't know that EILSEQ may be
defined in wchar.h, and so on such systems, ISTM gnulib ends up defining
an incompatible EILSEQ itself, but I think that should be fixed on
the gnulib side, by making it extract the EILSEQ value out of the
system's wchar.h, like GNU iconv does.
So that leaves handling the case of gnulib making up a EILSEQ value,
which we take as meaning the system really doesn't really define it,
which will be the systems GNU iconv returns ENOENT instead.
With that rationale, how about we try something like this?
The current EILSEQ definition under PHONY_ICONV is obviously stale
as gnulib garantees there's always a EILSEQ defined.
From ccf843befc9750bb0b8fb18296c1352b9ddef855 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Fri, 14 Nov 2014 10:29:03 +0000
Subject: [PATCH] handle iconv defining EILSEQ to ENOENT
---
gdb/charset.c | 35 +++++++++++++++++++++++++----------
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/gdb/charset.c b/gdb/charset.c
index 94ad020..d71321e 100644
--- a/gdb/charset.c
+++ b/gdb/charset.c
@@ -95,15 +95,6 @@
#undef ICONV_CONST
#define ICONV_CONST const
-/* Some systems don't have EILSEQ, so we define it here, but not as
- EINVAL, because callers of `iconv' want to distinguish EINVAL and
- EILSEQ. This is what iconv.h from libiconv does as well. Note
- that wchar.h may also define EILSEQ, so this needs to be after we
- include wchar.h, which happens in defs.h through gdb_wchar.h. */
-#ifndef EILSEQ
-#define EILSEQ ENOENT
-#endif
-
static iconv_t
phony_iconv_open (const char *to, const char *from)
{
@@ -187,8 +178,32 @@ phony_iconv (iconv_t utf_flag, const char **inbuf, size_t *inbytesleft,
return 0;
}
-#endif
+#else /* PHONY_ICONV */
+
+/* On systems that don't have EILSEQ, GNU iconv's iconv.h defines it
+ to ENOENT. gnulib instead defines it to a different value. On
+ such systems, map ENOENT to gnulib's EILSEQ, leaving callers
+ agnostic. */
+#ifdef GNULIB_defined_EILSEQ
+
+static size_t
+gdb_iconv (iconv_t utf_flag, ICONV_CONST char **inbuf, size_t *inbytesleft,
+ char **outbuf, size_t *outbytesleft)
+{
+ size_t ret;
+
+ ret = iconv (utf_flag, inbuf, inbytesleft, outbuf, outbytesleft);
+ if (errno == ENOENT)
+ errno = EILSEQ;
+ return ret;
+}
+#undef iconv
+#define iconv gdb_iconv
+
+#endif /* GNULIB_defined_EILSEQ */
+
+#endif /* PHONY_ICONV */
\f
/* The global lists of character sets and translations. */
--
1.9.3
next prev parent reply other threads:[~2014-11-14 11:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-14 5:45 Yao Qi
2014-11-14 7:33 ` Eli Zaretskii
2014-11-14 8:30 ` Yao Qi
2014-11-14 8:44 ` Gregory Fong
2014-11-14 9:26 ` Eli Zaretskii
2014-11-14 11:29 ` Joel Brobecker
2014-11-14 11:47 ` Pedro Alves [this message]
2014-11-14 13:02 ` Yao Qi
2014-11-14 13:21 ` Pedro Alves
2014-11-14 13:54 ` Yao Qi
2014-11-14 14:39 ` Pedro Alves
2014-11-14 15:18 ` Joel Brobecker
2014-11-14 16:01 ` Pedro Alves
2014-11-14 23:08 ` Yao Qi
2014-11-14 14:31 ` Eli Zaretskii
2014-11-14 14:42 ` Pedro Alves
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=5465EBAD.3070108@redhat.com \
--to=palves@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=gregory.0xf0@gmail.com \
--cc=yao@codesourcery.com \
/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