From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Add support for base64url variant Date: Thu, 23 May 2019 21:58:00 +0300 Message-ID: <83pno9577r.fsf@gnu.org> References: <87pnobiglo.fsf@killashandra.ballybran.fr> <837eaj7x37.fsf@gnu.org> <3b0dc49f9831435178dc1b64d6a2f5c7@free.fr> <83zhne7r8d.fsf@gnu.org> <87blzt6ovv.fsf@killashandra.ballybran.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="24087"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: pierre.techoueyres@free.fr (Pierre =?iso-8859-1?Q?T=E9choueyres?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 23 21:14:01 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 1hTtA8-00065L-Vn for ged-emacs-devel@m.gmane.org; Thu, 23 May 2019 21:14:01 +0200 Original-Received: from localhost ([127.0.0.1]:42136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTtA7-0003mT-Uy for ged-emacs-devel@m.gmane.org; Thu, 23 May 2019 15:13:59 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTt82-0002PI-0N for emacs-devel@gnu.org; Thu, 23 May 2019 15:11:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38968) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hTsuW-0000dH-AJ; Thu, 23 May 2019 14:57:52 -0400 Original-Received: from [176.228.60.248] (port=4379 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hTsuV-0001Hp-Hw; Thu, 23 May 2019 14:57:52 -0400 In-reply-to: <87blzt6ovv.fsf@killashandra.ballybran.fr> (pierre.techoueyres@free.fr) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:236944 Archived-At: > From: pierre.techoueyres@free.fr (Pierre Téchoueyres) > Cc: emacs-devel@gnu.org > Date: Thu, 23 May 2019 19:51:00 +0200 > > > 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. Then perhaps switch their order. > >> - 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, Doesn't sound worth it. Just an argument passed by the caller should be fine. The caller will have to know how the text is encoded. > I would also bring your attention on the part where I dynamically assign > pointers on specialized arrays for encoding (resp. decoding). I don't see a problem with that. > 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 ...) Emacs has benchmarking facilities, so you could time the code and see if there's some performance penalty. If the performance suffers too much, we could always have a helper function which receives the array as a parameter.