Message ID | 5465EBAD.3070108@redhat.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 22429 invoked by alias); 14 Nov 2014 11:47:08 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 22420 invoked by uid 89); 14 Nov 2014 11:47:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 14 Nov 2014 11:47:05 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAEBkuM9023568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 14 Nov 2014 06:46:56 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAEBkrQL005145; Fri, 14 Nov 2014 06:46:55 -0500 Message-ID: <5465EBAD.3070108@redhat.com> Date: Fri, 14 Nov 2014 11:46:53 +0000 From: Pedro Alves <palves@redhat.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 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 References: <87oasaibe6.fsf@codesourcery.com> In-Reply-To: <87oasaibe6.fsf@codesourcery.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit |
Commit Message
Pedro Alves
Nov. 14, 2014, 11:46 a.m. UTC
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(-)
Comments
Pedro Alves <palves@redhat.com> writes: > I think this will keep haunting and blocking us until we fix it. > Let us try again to fix it. > Can we reevaluate this? Sure. > 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? I am fine with your approach, but I am wondering why don't we simply check ENOENT in the places where we check EILSEQ? @@ -513,6 +513,7 @@ convert_between_encodings (const char *from, const char *to, switch (errno) { case EILSEQ: + case ENOENT: { int i; @@ -651,6 +652,7 @@ wchar_iterate (struct wchar_iterator *iter, switch (errno) { case EILSEQ: + case ENOENT: /* Invalid input sequence. We still might have converted a character; if so, return it. */ if (out_avail < out_request * sizeof (gdb_wchar_t)) This looks cleaner to me (some comments should be added, of course).
On 11/14/2014 01:01 PM, Yao Qi wrote: > Pedro Alves <palves@redhat.com> writes: > >> I think this will keep haunting and blocking us until we fix it. >> > > Let us try again to fix it. > >> Can we reevaluate this? > > Sure. > >> 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? > > I am fine with your approach, but I am wondering why don't we simply > check ENOENT in the places where we check EILSEQ? > > @@ -513,6 +513,7 @@ convert_between_encodings (const char *from, const char *to, > switch (errno) > { > case EILSEQ: > + case ENOENT: > { > int i; > > @@ -651,6 +652,7 @@ wchar_iterate (struct wchar_iterator *iter, > switch (errno) > { > case EILSEQ: > + case ENOENT: > /* Invalid input sequence. We still might have > converted a character; if so, return it. */ > if (out_avail < out_request * sizeof (gdb_wchar_t)) > > This looks cleaner to me (some comments should be added, of course). That was actually my first approach, but then: - I thought that having a central place to handle this and to put the comment was cleaner than repeating the fix in multiple places. - That won't build on systems that EILSEQ and ENOENT are defined to the same value (two switch cases with the same value). Not sure there are any such systems, but given iconv.h's practice... I guess I could also simplify and remove the GNULIB_defined_EILSEQ guard, mapping ENOENT to EILSEQ everywhere ? +/* 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 I looked at glibc's iconv and it seems that ENOENT is never used there, so should be safe. Thanks, Pedro Alves
Pedro Alves <palves@redhat.com> writes: > That was actually my first approach, but then: > > - I thought that having a central place to handle this > and to put the comment was cleaner than repeating the fix > in multiple places. > - That won't build on systems that EILSEQ and ENOENT are > defined to the same value (two switch cases with the same value). > Not sure there are any such systems, but given iconv.h's practice... > > I guess I could also simplify and remove the GNULIB_defined_EILSEQ > guard, mapping ENOENT to EILSEQ everywhere ? I don't have a strong feeling on this, so either is OK to me. > > +/* 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 > > I looked at glibc's iconv and it seems that ENOENT is never used > there, so should be safe. Good, could you please commit your patch?
> Date: Fri, 14 Nov 2014 13:21:01 +0000 > From: Pedro Alves <palves@redhat.com> > CC: gdb-patches@sourceware.org, gregory.0xf0@gmail.com, Joel Brobecker <brobecker@adacore.com> > > > @@ -651,6 +652,7 @@ wchar_iterate (struct wchar_iterator *iter, > > switch (errno) > > { > > case EILSEQ: > > + case ENOENT: > > /* Invalid input sequence. We still might have > > converted a character; if so, return it. */ > > if (out_avail < out_request * sizeof (gdb_wchar_t)) > > > > This looks cleaner to me (some comments should be added, of course). > > That was actually my first approach, but then: > > - I thought that having a central place to handle this > and to put the comment was cleaner than repeating the fix > in multiple places. > - That won't build on systems that EILSEQ and ENOENT are > defined to the same value (two switch cases with the same value). > Not sure there are any such systems, but given iconv.h's practice... The last one is easy: case EILSEQ: +#if EILSEQ != ENOENT + case ENOENT: +#endif
On 11/14/2014 02:31 PM, Eli Zaretskii wrote: >> From: Pedro Alves <palves@redhat.com> >> That was actually my first approach, but then: >> >> - I thought that having a central place to handle this >> and to put the comment was cleaner than repeating the fix >> in multiple places. >> - That won't build on systems that EILSEQ and ENOENT are >> defined to the same value (two switch cases with the same value). >> Not sure there are any such systems, but given iconv.h's practice... > > The last one is easy: > > case EILSEQ: > +#if EILSEQ != ENOENT > + case ENOENT: > +#endif Agreed, but then having to do that in multiple places seems even uglier. :-) Thanks, Pedro Alves
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 */ /* The global lists of character sets and translations. */