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

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

  1. Fix assorted bugs in ecpg's macro mechanism.