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 1lUSRl-0006Yr-U2 for pgsql-bugs@arkaria.postgresql.org; Thu, 08 Apr 2021 11:03:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lUSRk-0000Bq-5H for pgsql-bugs@arkaria.postgresql.org; Thu, 08 Apr 2021 11:03:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lUSRj-00009X-Sv for pgsql-bugs@lists.postgresql.org; Thu, 08 Apr 2021 11:03:35 +0000 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lUSRh-0004S9-5h for pgsql-bugs@lists.postgresql.org; Thu, 08 Apr 2021 11:03:35 +0000 Received: by mail-pj1-x1030.google.com with SMTP id ot17-20020a17090b3b51b0290109c9ac3c34so2944965pjb.4 for ; Thu, 08 Apr 2021 04:03:32 -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=N7IE1tpjZEeT+TPMNNd9YiI3kZyno2Rrbk5P41u/05w=; b=VIKb9Clsbnu+i4/nVSZE8DCnI+Vx9hTtEEglwmfuiLPXOwInys9pw0sTYh387hfKn4 oGDV2U6u/Fl6r45rKpU7YLQRfVvSh2w31gyRxygMSzgfpOTVGkDSHw63PrUjlNJcEnp/ 8ou6gCrGVGXvvH2BD1kKeTM5N87RhtSc8/sQJ+21r2daauv5Gs8W58rN0oRCfEwqeu6y 5wBRoB+zX8z5rj6123FnHNd/r+VTvrcwRV/JzwP7HDkfVxDCpiY/A79ynxWjl9o5sHlM uKQh5v6LOj1G/uDf5WMGPYhenCIBEzt3OYABC+9+YvojIB65G4YRyzRKhIXzdYD+/orj Zoyg== 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=N7IE1tpjZEeT+TPMNNd9YiI3kZyno2Rrbk5P41u/05w=; b=CXalcPyWvVbWyPetsxWzvUQyo/YlTUN7nSIhbwC7rwMHlqU8AAx9wzSgnfAFgi6JuP y5ig3SLm/uDupHO2gHat8J2/SDy6hCByxzdUFz3TitXCLep7kpZnALNCNvsrvl5HSk0y kmYTwLzt4lmVjjtp8Px7Awrig5WAbXYhX4GNUiuBghC6KUOi3RtrCTm4EMupx/tZEBVj Q8mZROLgwuCng5IwIB4kHzVgCSB6iMKDZy8AJ2sDC9WMEyafRDKzAovAXdyNcMaP5PiZ 8GcyRNCMGd4Gt7qjbLP2iDH86NR8G2bfmLOlHwmEya3vCRZBoKhil8MzSv1J3FdeOZQ2 ACrg== X-Gm-Message-State: AOAM5315F/DTs8UErlQkZCp8A6h2m0X4UqqxMYND5OKa+LrS30hzhHsq uIjByOT49zMX+5CLPVG0cNAnMpMpTAv7VQ== X-Google-Smtp-Source: ABdhPJzLaBUPul8bHjFpxULHybt75GtLwtH0x3HGMRDWfvNqUl3wwD2NsJZTrs5qjurY04Jkzlj9gA== X-Received: by 2002:a17:90a:868c:: with SMTP id p12mr7524232pjn.82.1617879810939; Thu, 08 Apr 2021 04:03:30 -0700 (PDT) Received: from nol (2001-b011-0008-9647-4c71-2a6f-a895-f450.dynamic-ip6.hinet.net. [2001:b011:8:9647:4c71:2a6f:a895:f450]) by smtp.gmail.com with ESMTPSA id gv18sm8367265pjb.41.2021.04.08.04.03.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Apr 2021 04:03:30 -0700 (PDT) Date: Thu, 8 Apr 2021 19:04:03 +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: <20210408110403.wr3d552xilqsx4us@nol> References: <16953-f255a18f8c51f1d5@postgresql.org> <20210407120856.3rjxxnnzzxn74vyv@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 Thu, Apr 08, 2021 at 07:17:50PM +0900, Michael Paquier wrote: > On Wed, Apr 07, 2021 at 08:08:56PM +0800, Julien Rouhaud wrote: > > PFA a naive patch to fix this problem with some regression tests. I'm assuming > > that -1 month should be january and not december. I had a quick look at the > > rest of formatting.c and didn't spot any similar problem, but another pair of > > eyes wouldn't hurt. > > Assuming an absolute number is not really intuitive when it comes to a > negative number here, while counting backward feels more natural, so I > would vote for making -1 be December, -2 November, etc. Honestly I might as well have flipped a coin here, so I'm fine either way. > Let's also make the tests more extended. I would suggest a single > query with generate_series() from say -12 to 12, that checks the > output of both RM and rm for the full range of values supported by > tm_mon. I'm fine with it too, although I'd probably go with [-13, 13] just to make sure that there's isn't silly off-by-one mistake. I'll just wait a bit to see if anyone else has any opinion on whether -1 month should be January or December.