Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dupDl-0000du-NK for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Sep 2017 00:20:01 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dupDl-0005SW-9v for pgsql-hackers@arkaria.postgresql.org; Thu, 21 Sep 2017 00:20:01 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dupCB-0002gE-RH for pgsql-hackers@postgresql.org; Thu, 21 Sep 2017 00:18:23 +0000 Received: from mail-yw0-x22f.google.com ([2607:f8b0:4002:c05::22f]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dupC8-0002GP-Vo for pgsql-hackers@postgresql.org; Thu, 21 Sep 2017 00:18:22 +0000 Received: by mail-yw0-x22f.google.com with SMTP id x131so3030547ywa.10 for ; Wed, 20 Sep 2017 17:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=+tN/6D4ZDHFXQjdqvtSwgqpEDeFVbA7kJ+7wSB6knik=; b=JnLzbAyLQvOA/LDAnHwruXZ7GLwL2stDXh3rS5w6C6mGwH/aVgK76J4UWpUrDFgoWV Wl7bOh5kGVWZBur+gVq++QbNs2YM25i+64Yh4DZXPAjjD7AnMIlDQxerpf/J4EDRjig2 ugJsaECEP3yJuq6CrG4IrfqejQotacFRAF/ZRr43alXukKiCEsYrsH+xRGS4QXa7KMMW 3D7sheCK50TQz/OY4Conqnez1TreGNWFjhGPkFgwoQEjNiVySmJHfOAhHIEfjAMoCAb+ 3mm+Ro+WFeVPAIExCm1+OGYooWNXqR3X3JgwA2phPAcocBD2SiSohzbFmLU5ej+2SYum lHBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=+tN/6D4ZDHFXQjdqvtSwgqpEDeFVbA7kJ+7wSB6knik=; b=a6Q+Nm+tOKezm9OT7auz/Gf/p5eqlo+DwOR5kSAHH13CxyKBygerZ/aHnWKgLr0prR gsYWXN+Lbh7uLM2bkNS34chqnu1rIPL0SjjpCaEd+eBfe6uXSRkjkA411EzWHSvptKf4 JiPAJi38QfccmxC5mFUvjkV5rLQKbKqujliAuUeuXGkIsS2udyXcDyqji6Ixl/rEVDli QTYsak1cNOxEfwXq7XFvXRTxYN4nPxbMkvbE/VzhdIpsQ3lj5yZTiv6+AhLoIrKxOvL1 woekEue/O5qJvdZPt/LuppYOp/kLpvm/HyUrMxJkYHZT4c8u4iqMoO47NJMbtkLs2JWK TJhA== X-Gm-Message-State: AHPjjUjKbhc6JF10cFXYzrPAhvu7I3+GpvsBSmhrh6eZlBe2VMXJQRB/ PnXAsmkaSMBechPnkFh29xVDm2uWSIvcCCiMAl1TF4EJ9mAvy7xfRRU9iwY12bW73pu4Zl7UJkD 8kae6azL0iXm6RHWFVzbZ3hhUYDOCRtS1QZjZ1kcVOsZlrQTZr/r2HiY7S0Xt4SBdMded0tRcRp d32D3tqgcQrDSN X-Google-Smtp-Source: AOwi7QDYKC0o6wgJJM6vrOfvpJpmRUoCpC1iPW6BYtPZkKS79FPKxXAjhwopf2kC7qsaFZiV+/1pcg== X-Received: by 10.13.199.2 with SMTP id j2mr342512ywd.207.1505953099795; Wed, 20 Sep 2017 17:18:19 -0700 (PDT) Received: from [192.168.10.146] ([98.122.175.38]) by smtp.gmail.com with ESMTPSA id c11sm66954ywb.89.2017.09.20.17.18.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 17:18:19 -0700 (PDT) From: Andrew Dunstan X-Google-Original-From: Andrew Dunstan Subject: Re: Windows warnings from VS 2017 To: Tom Lane Cc: PostgreSQL-development References: <8649.1505951694@sss.pgh.pa.us> Message-ID: Date: Wed, 20 Sep 2017 20:18:18 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <8649.1505951694@sss.pgh.pa.us> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-MW List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 09/20/2017 07:54 PM, Tom Lane wrote: > Andrew Dunstan writes: >> It's also warning that it will copy 16 bytes to a 13 byte structure at >> lines 518, 1293 and 1294 of src/backend/commands/dbcommands.c. I haven't >> seen any ill effects of this so far, but it seems to indicate that >> something is possibly amiss on this compiler with the MemSet macros. > That's weird. Is it too stupid to figure out that the if() inside > MemSet evaluates to constant false in these calls? It seems hard to > see how it would realize that the loop will write 16 bytes if it doesn't > propagate the constant value forward. > > However ... on some other compilers, I've noticed that the compiler seems > more likely to make "obvious" deductions of that sort if the variables in > question are marked const. Does it help if you do > > - void *_vstart = (void *) (start); \ > - int _val = (val); \ > - Size _len = (len); \ > + void * const _vstart = (void *) (start); \ > + const int _val = (val); \ > + const Size _len = (len); \ > > > I don't think there's any strong reason not to just do s/MemSet/memset/ > in these calls and nearby ones, but it would be good to understand just > what's wrong here. And why it's only showing up in that file; seems > nearly certain that we have similar coding elsewhere. > > I'll test it. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers