Fix broken list-munging in ecpg's remove_variables().
authorTom Lane <[email protected]>
Sun, 1 Dec 2024 19:15:37 +0000 (14:15 -0500)
committerTom Lane <[email protected]>
Sun, 1 Dec 2024 19:15:37 +0000 (14:15 -0500)
commite359cbb846788c584767288497beaa788a0f1b3e
treea356b208ff980f40a2c49a76adf67f8f80654c1b
parentfce6fd5da580542e026ac023352cafcb97854fec
Fix broken list-munging in ecpg's remove_variables().

The loops over cursor argument variables neglected to ever advance
"prevvar".  The code would accidentally do the right thing anyway
when removing the first or second list entry, but if it had to
remove the third or later entry then it would also remove all
entries between there and the first entry.  AFAICS this would
only matter for cursors that reference out-of-scope variables,
which is a weird Informix compatibility hack; between that and
the lack of impact for short lists, it's not so surprising that
nobody has complained.  Nonetheless it's a pretty obvious bug.

It would have been more obvious if these loops used a more standard
coding style for chasing the linked lists --- this business with the
"prev" pointer sometimes pointing at the current list entry is
confusing and overcomplicated.  So rather than just add a minimal
band-aid, I chose to rewrite the loops in the same style we use
elsewhere, where the "prev" pointer is NULL until we are dealing with
a non-first entry and we save the "next" pointer at the top of the
loop.  (Two of the four loops touched here are not actually buggy,
but it seems better to make them all look alike.)

Coverity discovered this problem, but not until 2b41de4a5 added code
to free no-longer-needed arguments structs.  With that, the incorrect
link updates are possibly touching freed memory, and it complained
about that.  Nonetheless the list corruption hazard is ancient, so
back-patch to all supported branches.
src/interfaces/ecpg/preproc/variable.c