From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6624 invoked by alias); 14 Nov 2014 13:21:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 6613 invoked by uid 89); 14 Nov 2014 13:21:11 -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 13:21:10 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAEDL5Rj024790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 14 Nov 2014 08:21:05 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sAEDL2cb012895; Fri, 14 Nov 2014 08:21:03 -0500 Message-ID: <546601BD.7020700@redhat.com> Date: Fri, 14 Nov 2014 13:21:00 -0000 From: Pedro Alves 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 CC: gdb-patches@sourceware.org, gregory.0xf0@gmail.com, Joel Brobecker Subject: Re: gnulib's errno module was imported References: <87oasaibe6.fsf@codesourcery.com> <5465EBAD.3070108@redhat.com> <87fvdmhr5o.fsf@codesourcery.com> In-Reply-To: <87fvdmhr5o.fsf@codesourcery.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-11/txt/msg00303.txt.bz2 On 11/14/2014 01:01 PM, Yao Qi wrote: > Pedro Alves 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