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 1osn9J-0005mv-P2 for pgsql-bugs@arkaria.postgresql.org; Wed, 09 Nov 2022 15:37:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1osn9I-0007a1-7A for pgsql-bugs@arkaria.postgresql.org; Wed, 09 Nov 2022 15:37:56 +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 1osn9H-0007TE-UZ for pgsql-bugs@lists.postgresql.org; Wed, 09 Nov 2022 15:37:55 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1osn9C-0006Ff-2d for pgsql-bugs@lists.postgresql.org; Wed, 09 Nov 2022 15:37:51 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2A9Fbkjq3977659; Wed, 9 Nov 2022 10:37:46 -0500 From: Tom Lane To: higuchi.daisuke@fujitsu.com cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17681: Building the REL_12_13 source in Visual Studio 2013 fails. In-reply-to: <3969640.1668005050@sss.pgh.pa.us> References: <17681-485ba2ec13e7f392@postgresql.org> <3969640.1668005050@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 09 Nov 2022 09:44:10 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3977657.1668008266.1@sss.pgh.pa.us> Date: Wed, 09 Nov 2022 10:37:46 -0500 Message-ID: <3977658.1668008266@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > Thanks for checking that. However, as that commit message says, > we require C99 support in v12 and up, and snprintf is definitely > required by C99. So I'm disinclined to revert that. If VS2013 > can't supply snprintf, it's not meeting our minimum platform > standards, so we should remove it from the list of supported > platforms. > Having said that, Microsoft had had well over a dozen years by > that point to get off their duffs and build a C99-compliant > library. After googling the question, I find that indeed Microsoft couldn't be bothered to support snprintf until VS2015. Bozos. Still, I suppose it'd be better to not move this portability goalpost in released branches. We could do something like #if defined(_MSC_VER) && _MSC_VER < 1900 /* pre-VS2015 */ #define snprintf(str,size,...) sprintf(str,__VA_ARGS__) #endif in snprintf.c below where it #undef's snprintf. Could you try that and verify it works for you? Also, the reason we didn't notice this problem is the lack of any VS2013 animal in the buildfarm. While we've dropped support for that as of HEAD (v16), it seems like somebody had better run such an animal on the back branches if they want the platform to keep working. regards, tom lane