From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id D11C93857C4F for ; Sun, 7 Feb 2021 12:34:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D11C93857C4F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-297-qGiXrVhwPhm5b9NcXww9wg-1; Sun, 07 Feb 2021 07:34:31 -0500 X-MC-Unique: qGiXrVhwPhm5b9NcXww9wg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1A84B520E; Sun, 7 Feb 2021 12:34:30 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-116.ams2.redhat.com [10.36.112.116]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 271C45D6A1; Sun, 7 Feb 2021 12:34:28 +0000 (UTC) From: Florian Weimer To: Max Gautier Cc: Florian Weimer via Libc-alpha Subject: Re: [PATCH v3 1/5] Copy utf-7 module to modified-utf-7 References: <87y2m9agmm.fsf@mid.deneb.enyo.de> <20210125090226.39967-1-mg@max.gautier.name> <20210125090226.39967-2-mg@max.gautier.name> <878s8h2whg.fsf@igel.home> <87blcw9ptq.fsf@oldenburg.str.redhat.com> Date: Sun, 07 Feb 2021 13:34:40 +0100 In-Reply-To: (Max Gautier via Libc-alpha's message of "Sun, 7 Feb 2021 13:29:15 +0100") Message-ID: <87v9b46opr.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 12:34:37 -0000 * Max Gautier via Libc-alpha: > When I initially looked at utf-7.c, the use of the _tab arrays with > magic values and the subsequent shifting didn't make a lot of sense to > me, which is why I modified them like this for utf-7-imap. If they are > in the same file, it's probably better to use the same method. > So do you see any benefits to keeping the old method ? I think the old method was an optimization in the long-gone times when memory access was relatively fast compared to computation. GCC has also improved since: it can use shifts and bit lookups to combine comparisons against multiple constants into one check. > Testing directly for the actual characters seems a lot more readable to > me, is shorter, and can be mapped to the RFC definition. Agreed. >> You could remove the UTF7_ENCODE_OPTIONAL_CHARS from the existing UTF-7 >> codec in a first, separate patch. > > Do you mean I should modify the utf-7 conversion to not encode the > optional chars ? That would change the result of utf-7 conversions, > wouldn't it ? I'm not opposed to it, but isn't that going to break > things ? Sorry, I meant to remove the constructs that enable this type of compile-time configurability. That is, remove the macro, but do not change the generated code. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill