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

In response to

Browse pgsql-hackers by date

  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)