Re: ECPG cleanup and fix for clang compile-time problem - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ECPG cleanup and fix for clang compile-time problem
Date
Msg-id 1894437.1732730378@sss.pgh.pa.us
Whole thread Raw
In response to Re: ECPG cleanup and fix for clang compile-time problem  (John Naylor <johncnaylorls@gmail.com>)
List pgsql-hackers
John Naylor <johncnaylorls@gmail.com> writes:
> I think you can go ahead and commit 0001-0003. For 0003 I do admit
> being confused why valgrind had a problem with progname...

Pushed, thanks for looking at it!

As for progname, valgrind was unhappy because the local in main()
went out of scope at return, but the malloc block was still there.
But this was weird coding anyway: pretty much everywhere else,
we store progname in a globally-accessible variable so that it can
be used in error messages.  I figured making it static was a down
payment on someday making ecpg's messages honor that convention.

> FWIW, I also took a quick eyeball check of the coverage output for
> preproc.y looking for untested non-error branches that do things that
> are not covered elsewhere, and I didn't notice any. Some places
> allocating new connections are not covered, which should be handled by
> 0003.

Yeah, ecpg's coverage report is fairly sad overall, but a lot of the
uncovered stuff is autogenerated grammar productions, which I think
we can have high confidence in.  I'm not currently feeling motivated
to try to improve that number.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_parse_json() should not leak token copies on failure
Next
From: Alvaro Herrera
Date:
Subject: Re: Statistics Import and Export