From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id A6AA46EC59; Tue, 9 Mar 2021 13:09:07 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org A6AA46EC59 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1615284547; bh=sjQk6LePDClOpwOHbo02xY/sxMEovi0IgJ9EtngU4yw=; h=To:References:Date:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=FmvxPcUC3YOVRjHXV4vCplHxnD6+z6tB8NVFnyIiJPpqu8oLeVrYJcy952E6Bm7mO wtDWV17mYpLthpAeFNcr7kxCT+8J1lN09f3dIjCoW7uczB7h5jA3hAszIUI6OTRKKO 9c77igmeysEVmnxvScnDfxxZNzpS/j2BGe7kkqjc= Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id E3B106EC59 for ; Tue, 9 Mar 2021 13:09:06 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org E3B106EC59 Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1lJZIX-0002o4-OA; Tue, 09 Mar 2021 13:09:06 +0300 To: Alexander Turenko References: <5cbe765bbcfaa1d23a0ffa3ee29e74e2089f7466.1614601625.git.void@tarantool.org> <20210302230820.4kiad5inxhbitkkl@tkn_work_nb> Message-ID: Date: Tue, 9 Mar 2021 13:09:05 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210302230820.4kiad5inxhbitkkl@tkn_work_nb> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9D3134714A9BDB69B844F3AC9255B388D8D4E2637BBED27E200894C459B0CD1B926A3C44C513BE3AA4E8C96D024B829BC9B0DE9CFAF91FC4ADC3326C543D49E8D X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7F1942E6D70B4A2F0EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006376602C647E39EFA3A8638F802B75D45FF914D58D5BE9E6BC131B5C99E7648C95C1F4A82545730C7619859B94ED188BE62EEE9C53E6EBF2E81A471835C12D1D9774AD6D5ED66289B5278DA827A17800CE71AE4D56B06699BBC9FA2833FD35BB23D2EF20D2F80756B5F868A13BD56FB6657A471835C12D1D977725E5C173C3A84C353FA85A707D24CADCC7F00164DA146DA6F5DAA56C3B73B23C77107234E2CFBA567F23339F89546C55F5C1EE8F4F765FC80B9CEB5436E71E375ECD9A6C639B01BBD4B6F7A4D31EC0BC0CAF46E325F83A522CA9DD8327EE4930A3850AC1BE2E735438480C876D879DDC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F5D41B9178041F3E72623479134186CDE6BA297DBC24807EABDAD6C7F3747799A X-C1DE0DAB: 0D63561A33F958A5CCEE96686D433D6FA072461C4145DC7CAA0C475F9BC13B6FD59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75448CF9D3A7B2C848410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D340A58BF0C7EAC340F4CCA2CF1806BC35F9C388625FA2C9E6B287F4154D1A778823B9D6C9C68DC38F71D7E09C32AA3244C87B83D8F7628440F10AFB0897181A71AA90944CA99CF22E383B48618A63566E0 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojUqxEkzHTt/i6vVvgtL5H9A== X-Mailru-Sender: 689FA8AB762F73936BC43F508A063822D37B4A53AB9830BD67F8FB36DC2E8897DD675A873A6B1A573284F99205A65E8EFB559BB5D741EB966AABCD5B59A9F6DF9ABAAAF6BC5F075B67EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v7] base64: fix decoder output buffer overrun (reads) X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Nikiforov via Tarantool-patches Reply-To: Sergey Nikiforov Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On 03.03.2021 2:08, Alexander Turenko wrote: >> -static int >> -base64_decode_block(const char *in_base64, int in_len, >> - char *out_bin, int out_len, >> - struct base64_decodestate *state) >> +int >> +base64_decode(const char *in_base64, int in_len, >> + char *out_bin, int out_len) >> { >> const char *in_pos = in_base64; >> const char *in_end = in_base64 + in_len; >> char *out_pos = out_bin; >> char *out_end = out_bin + out_len; >> int fragment; >> + char curr_byte; > > AFAIR, nothing prevent us from using `*out_pos`. I don't see a reason to > introduce `curr_byte`. It was necessary in v6 to store the initial > state for a block. I have removed this local var in v8. Initially I planned to send patch series with this local var added in second patch and performance-optimized (w/o unnecessarily checks) version of decode function in third but my benchmarks have shown controversial effects. Adding this local var "by itself" actually decreases performance on one of my test machines but improves on another one. Optimized decode function, however, benefits from this local var but not when output buffer is large enough. And effect is different on another machine... I haved saved optimized code (nothing really new here) and benchmark locally to work on them further later on.