Re: Use stack-allocated StringInfoData
| От | David Rowley | 
|---|---|
| Тема | Re: Use stack-allocated StringInfoData | 
| Дата | |
| Msg-id | CAApHDvr2URad5FRknDECPsmt-FT3LukvXDbv6MzgW+_L842+xA@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | Use stack-allocated StringInfoData (Mats Kindahl <mats.kindahl@gmail.com>) | 
| Ответы | 
                	
            		Re: Use stack-allocated StringInfoData
            		
            		 | 
		
| Список | pgsql-hackers | 
On Mon, 3 Nov 2025 at 20:27, Mats Kindahl <mats.kindahl@gmail.com> wrote: > We can use > > StringInfoData info; > initStringInfo(&info); > ... > appendStringInfo(&info, ...); > ... > return info.data; > > It was corrected in an earlier commit, but that seems to have been removed so we still have a lot of these cases. > > I created a semantic patch to capture most of these cases, which is present in [1], but this is a slightly modified versionthat might be interesting to include regardless of other changes. The patch is applied and one case that couldn'tbe matched is manually fixed. I think this is a worthwhile conversion. Are you able to create a more complete version of this? The draft version does introduce quite a few whitespace changes that aren't wanted. You've also introduced a memory leak in check_publications(), fetch_relation_list(), jsonb_send() and xml_errorHandler() (NB: destroyStringInfo() doesn't just pfree the memory for the struct, it pfree's the data too). The patch shouldn't be leaving any memory around that the current master is careful to pfree. Do you have any semi-automated method to find these? Or is it a case of manually reviewing code with a makeStringInfo() call? David
В списке pgsql-hackers по дате отправления: