Bugs in ecpg's macro mechanism
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Date: 2024-04-15T21:48:32Z
Lists: pgsql-hackers
Attachments
- v1-0001-Fix-assorted-bugs-in-ecpg-s-macro-mechanism.patch (text/x-diff) patch v1-0001
I started looking into the ideas discussed at [1] about reimplementing ecpg's string handling. Before I could make any progress I needed to understand the existing input code, part of which is the macro expansion mechanism ... and the more I looked at that the more bugs I found, not to mention that it uses misleading field names and is next door to uncommented. I found two ways to crash ecpg outright and several more cases in which it'd produce surprising behavior. As an example, $ cd .../src/interfaces/ecpg/test/preproc/ $ ../../preproc/ecpg --regression -I./../../include -I. -DNAMELEN=99 -o define.c define.pgc munmap_chunk(): invalid pointer Aborted Attached is a patch that cleans all that up and attempts to add a little documentation about how things work. One thing it's missing is any test of the behavior when command-line macro definitions are carried from one file to the next one. To test that, we'd need to compile more than one ecpg input file at a time. I can see how to kluge the Makefiles to make that happen, basically this'd do: define.c: define.pgc $(ECPG_TEST_DEPENDENCIES) - $(ECPG) -DCMDLINESYM=123 -o $@ $< + $(ECPG) -DCMDLINESYM=123 -o $@ $< $< But I have no idea about making it work in meson. Any suggestions? regards, tom lane [1] https://www.postgresql.org/message-id/3897526.1712710536%40sss.pgh.pa.us
Commits
-
Fix assorted bugs in ecpg's macro mechanism.
- 6f0cef9353fc 17.0 landed
- 4631646391ec 14.12 landed
- 392e6e9e6ada 16.3 landed
- 2b6a74afe170 12.19 landed
- 25f937217200 15.7 landed
- 02531e8ca8dc 13.15 landed