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
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) |