From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: pierre.techoueyres@free.fr (Pierre =?utf-8?Q?T=C3=A9choueyres?=) Newsgroups: gmane.emacs.devel Subject: Re: Add support for base64url variant Date: Thu, 23 May 2019 19:51:00 +0200 Message-ID: <87blzt6ovv.fsf@killashandra.ballybran.fr> References: <87pnobiglo.fsf@killashandra.ballybran.fr> <837eaj7x37.fsf@gnu.org> <3b0dc49f9831435178dc1b64d6a2f5c7@free.fr> <83zhne7r8d.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="172774"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 23 19:52:00 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hTrsm-000ipJ-3y for ged-emacs-devel@m.gmane.org; Thu, 23 May 2019 19:52:00 +0200 Original-Received: from localhost ([127.0.0.1]:41317 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTrsl-0004vd-2u for ged-emacs-devel@m.gmane.org; Thu, 23 May 2019 13:51:59 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59817) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTrry-0004vJ-8l for emacs-devel@gnu.org; Thu, 23 May 2019 13:51:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hTrrx-0001M4-BG for emacs-devel@gnu.org; Thu, 23 May 2019 13:51:10 -0400 Original-Received: from smtp4-g21.free.fr ([212.27.42.4]:34884) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hTrrv-0001KE-Qb; Thu, 23 May 2019 13:51:07 -0400 Original-Received: from killashandra.ballybran.fr.free.fr (unknown [IPv6:2a01:e0a:1e2:f8b0:9cc3:35bf:aa81:ccf7]) by smtp4-g21.free.fr (Postfix) with ESMTPS id 6AB2419F5AD; Thu, 23 May 2019 19:51:00 +0200 (CEST) In-Reply-To: <83zhne7r8d.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 22 May 2019 12:50:26 +0300") X-detected-operating-system: by eggs.gnu.org: Windows NT kernel [generic] [fuzzy] X-Received-From: 212.27.42.4 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236940 Archived-At: Eli Zaretskii writes: >> ... >> I would like to have some discussion on how to improve some points : >> - Is adding parameter to existing functions the way to go or is it >> better to add new ones for base64url > > I think an optional argument will be fine. Except here I've added two, and one that doesn't really mean anything if the second isn't set. ie. you should not (at least without breaking the RFC) generate an base64 string without padding. At first many parameters seemed to me a good thing : limitted patch and flexibility. But now I'm no more sure ... >> - I would like to improve base64-decode* in a way it could detect the >> variant but actually don't know how to do that. > > Maybe someone else will have an idea. Is such an algorithmic > detection described someplace? > None I'm aware of. I was thinking to something like that : - define two boolean. One saying you're on crude base64 another saying you're on base64url variant. - initialize them as false. - start decoding. - when finding crude base64 chars (/ or +) set the base64 to true, - when finding specific url variant chars (- or _) set base64url to true, try to decode until the end of data. On parts where padding is checked do it only if base64 is true. But this approch could fail on the following cases : - a mix of chars from both variant without padding (no checks but obviously wrong) - absence of chars from any variant (here I can't decide for the necessity of padding). I would also bring your attention on the part where I dynamically assign pointers on specialized arrays for encoding (resp. decoding). ex: line 244 of patch char const *b64_value_to_char = (url_variant) ? base64url_value_to_char : base64_value_to_char; Before my change there were static const, so I suppose compiler could have inlined them or at least stored on some cache. But now ... So I'm a little scarried by the possible lost of performance. If anyone has some hint on how I could benchmark this (other than by the naive way which could result in my data where all in cache ...) Pierre.