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-12 03:40:21 |
Message-ID: | 2146210.1623469221@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:
> On 2021-06-11 19:08:57 -0400, Tom Lane wrote:
>> 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.
> nonstring is supported since gcc 8, which also brought the warnings that
> e71658523 is concerned about. Which makes me think that we should be
> able to get away without a configure test. The one complication is that
> the relevant ecpg code doesn't include c.h.
Ugh. And we *can't* include that there.
> But I think we can just do something like:
> - char sqlstate[5];
> + char sqlstate[5]
> +#if defined(__has_attribute) && __has_attribute(nonstring)
> + __attribute__((nonstring))
> +#endif
> + ;
> };
Hmm. Worth a try, anyway.
> Should we also include a pg_attribute_nonstring definition in c.h?
> Probably not, given that we right now don't have another user?
Yeah, no point till there's another use-case. (I'm not sure
there ever will be, so I'm not excited about adding more
infrastructure than we have to.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-06-12 03:45:51 | Re: PG 14 release notes, first draft |
Previous Message | Andres Freund | 2021-06-12 02:36:19 | Re: [PATCH] Fix buffer not null terminated on (ecpg lib) |