On 3/15/18 12:12, Tom Lane wrote:
> FWIW, I noticed while fooling with pre-release Fedora 28 that gcc 8.0.1
> emits a whole boatload of these warnings by default.
I have some patches for that. I will send them in once gcc 8 is a bit
closer to release.
--
Peter Eisentraut http://www
On Thu, Mar 15, 2018 at 12:12:18PM -0400, Tom Lane wrote:
> FWIW, I noticed while fooling with pre-release Fedora 28 that gcc 8.0.1
> emits a whole boatload of these warnings by default. This patch doesn't
> seem to have moved the needle very much, either. In a quick look, it
> seemed like a lot
Peter Eisentraut writes:
> On 3/14/18 02:52, Michael Paquier wrote:
>> Enabling them by default would generate some useless noise if the patch
>> is let as-is as a couple of them are not addressed. Please see the full
>> report attached. Is that intentional? I am using GCC 7.3 here.
> Well tha
On 3/14/18 02:52, Michael Paquier wrote:
> Enabling them by default would generate some useless noise if the patch
> is let as-is as a couple of them are not addressed. Please see the full
> report attached. Is that intentional? I am using GCC 7.3 here.
Well that's weird. Apparently, the warni
On Wed, Feb 28, 2018 at 11:14:23PM -0500, Peter Eisentraut wrote:
> AFAICT, the issues addressed here either can't really happen without
> trying very hard, or would cause harmless output truncation. Still, it
> seems good to clean this up properly and not rely on made-up buffer size
> guesses tha
In 6275f5d28a1577563f53f2171689d4f890a46881, we fixed warnings from the
options -Wformat-overflow and -Wformat-truncation, which are part of
-Wall in gcc 7.
Here, I propose to dial this up a bit by adding -Wformat-overflow=2
-Wformat-truncation=2, which use some more worst-case approaches for
esti