Re: [PATCH] Fix buffer not null terminated on (ecpg lib)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, ranier(dot)vf(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Fix buffer not null terminated on (ecpg lib)
Date: 2021-06-11 23:08:57
Message-ID: 2132305.1623452937@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> It might be worth doing something about this, for other reasons. We have
> disabled -Wstringop-truncation in 716585235b1. But I've enabled it in my
> debug build, because I find it useful.

ITYM e71658523 ? I can't find that hash in my repo. Anyway, I agree
that disabling that was a bit of a stopgap hack. This 'nonstring'
attribute seems like it would help for ECPG's usage, at least.

> I've not looked at how much work it'd be to make a recent-ish gcc not to
> produce lots of false positives in optimized builds.

The discussion that led up to e71658523 seemed to conclude that the
only reasonable way to suppress the majority of those warnings was
to get rid of the fixed-length MAXPGPATH buffers we use everywhere.
Now that we have psprintf(), that might be more workable than before,
but the effort-to-reward ratio still doesn't seem promising.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-06-11 23:30:18 Re: unnesting multirange data types
Previous Message Andres Freund 2021-06-11 22:49:07 Re: [PATCH] Fix buffer not null terminated on (ecpg lib)