Re: may be a buffer overflow problem
От | Andres Freund |
---|---|
Тема | Re: may be a buffer overflow problem |
Дата | |
Msg-id | 20240618141103.7nlcqalicsvleblx@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: may be a buffer overflow problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hi, On 2024-06-17 22:42:41 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2024-06-17 23:52:54 +0200, Daniel Gustafsson wrote: > >> Since sqlca is, according to our docs, present in other database systems we > >> should probably keep it a 5-char array for portability reasons. Adding a > >> padding character should be fine though. > > > How about, additionally, adding __attribute__((nonstring))? Wrapped in an > > attribute, of course. That'll trigger warning for many unsafe uses, like > > strlen(). > > What I was advocating for is that we make it *safe* for strlen, not > that we double down on awkward, non-idiomatic, unsafe coding > practices. Given that apparently other platforms have it as a no-trailing-zero-byte "string", I'm not sure that that is that clearly a win. Also, if they just copy the field onto the stack or such, they'll have the same issue again. And then there is this: > Admittedly, I'm not sure how we could persuade compilers that > a char[5] followed by a char field is a normal C string ... I think the explicit backstop of a zero byte is a good idea, but I don't think we'd just want to rely on it. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: