Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lVn06-0004Fo-DM for pgsql-bugs@arkaria.postgresql.org; Mon, 12 Apr 2021 03:12:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lVn05-0002Gs-9U for pgsql-bugs@arkaria.postgresql.org; Mon, 12 Apr 2021 03:12:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lVn05-0002Gl-0i for pgsql-bugs@lists.postgresql.org; Mon, 12 Apr 2021 03:12:33 +0000 Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lVmzz-0005iF-LB for pgsql-bugs@lists.postgresql.org; Mon, 12 Apr 2021 03:12:32 +0000 Received: by mail-pj1-x1035.google.com with SMTP id s14so1040573pjl.5 for ; Sun, 11 Apr 2021 20:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=BFJenUKnwjF06zwnGzDS1UJXC0BCwxoxUf2q2YvJT1I=; b=fXymquZwJ9mlzp/yj3ub4fIL+LFf47XInIqapAwy6Tz7FYexyLrWpe7i9Wp6kEvbNu b8vszWhhP6PVBQRxxbbu3tg8oIqDXxdnaD0ornM2hN5ik3ZIYpkdRaOXmY3jPOl1L+aV drbZbf0kZeXiO6GeEXZcPMTvY3s/COJly7+B5atqYk/AmiHhPHEzR3ZOvPIV5vtLWs88 hV3vyobVSbtG2YFclJhLMza0rDoXkI2g9mtP9SYCx6T3TeEiunkYP01heCV5Ob0Zolaw ycOsg1SbILXuBQAhzV9I0TzFN9i+qzMNG6rVPVIPX/wSd4NnykdZGxDhEIhNA1fSvPjh Dq7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=BFJenUKnwjF06zwnGzDS1UJXC0BCwxoxUf2q2YvJT1I=; b=JjaI9fgOc7y7OYOTYl0lzxy/l+frEsvZfFfyXBjaw9dTREAXARGzGaV8bj9I+4anEu uc4SuWgjVi4HGMw06fMKkxDwiXL4ne8eghnaQsWgbvNLy7owcaSOs38ouTOnFLEofW8b wlMPdxJZWHuwWcfEi5Ow2DDY3WZF9bBuNX7Dv9QcMYQr8ixXFgBhAM9XXAF60F+Bv/VQ OxykXZxSrQ+XzJrInA9z7rrhpKsJE1Vs2yL9EhT0J0hz5QNl9bgraPkt204xdAp9UGea 4QY8vCSPYMwpxZvuY4MC6PW99bLjDbatdSgXa6APB7AeVyv+i6aDCII6B6fdLx7sZAoG zzzw== X-Gm-Message-State: AOAM533wFHoZDdyDExWc4aGOONFxEd7dVVKHxzBvcyDgi4qvl0flY44b 9zoc9qHEWacXLf5MSP7Ixx4Uh8Wh0EI= X-Google-Smtp-Source: ABdhPJwtRqRtLSQbTGK81gWvVjo6QOH9GwsTgt/jB97eyjsJuD/KV2oVwEJLJNDmc1TAQdivCayCWA== X-Received: by 2002:a17:902:da92:b029:e5:fa64:e9f3 with SMTP id j18-20020a170902da92b02900e5fa64e9f3mr24170960plx.54.1618197146428; Sun, 11 Apr 2021 20:12:26 -0700 (PDT) Received: from nol (2001-b011-0008-349b-06e9-2751-a56b-9a09.dynamic-ip6.hinet.net. [2001:b011:8:349b:6e9:2751:a56b:9a09]) by smtp.gmail.com with ESMTPSA id r6sm9234182pgp.64.2021.04.11.20.12.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 11 Apr 2021 20:12:26 -0700 (PDT) Date: Mon, 12 Apr 2021 11:13:02 +0800 From: Julien Rouhaud To: Michael Paquier Cc: t.larionov@postgrespro.ru, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #16953: OOB access while converting "interval" to char Message-ID: <20210412031302.tquch5rg5j3eiut3@nol> References: <16953-f255a18f8c51f1d5@postgresql.org> <20210407120856.3rjxxnnzzxn74vyv@nol> <20210408110403.wr3d552xilqsx4us@nol> <20210409104246.vkeef6rbyevq46f3@nol> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Apr 12, 2021 at 12:04:23PM +0900, Michael Paquier wrote: > On Fri, Apr 09, 2021 at 07:58:51PM +0900, Michael Paquier wrote: > > Yep. The regression tests show what I would expect. I'll check in > > details later. > > I have spent some time on that today and applied this patch down to > 9.6, after adding more comments and simplifying a bit the calculation > method used. Instead of using the "mon" variable to store an > intermediate result, I have simplified things so as this only uses > tm->tm_mon, and "mon" for the position in the roman-numeral array is > adjusted only once. Thanks Michael! I thought we'd want to keep the original calculation for consistency, but directly computing the needed offset is clearly simpler to read!