John Naylor 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 bl
On Tue, Oct 15, 2024 at 1:25 AM Tom Lane wrote:
>
> The rest is just memory leak removal, and I suspect that nobody really
> cares that much about small leakage in the preprocessor: you'd have to
> be running some darn big files through it to notice. FTR, here are
> the total leaks reported by va
Alexander Lakhin writes:
> I've spent a day testing ecpg preprocessor and found another couple of
> bugs:
Thanks for the report! The first couple of these seem simple
enough to fix, so I've done so. As for
> Also, processing of .../ecpg/test/sql/include.pgc, containing only:
> EXEC SQL INCLUDE
Hello Tom,
16.10.2024 19:26, Tom Lane wrote:
Alexander Lakhin writes:
Maybe you would like to fix in passing several (not new) defects, I've
found while playing with ecpg under Valgrind:
Done. After evaluation I concluded that none of these were worth the
trouble to back-patch, but by all me
I wrote:
> Attached are rebased and renumbered 0006-0008, mostly to keep the
> cfbot happy.
For some reason I thought the stuff I pushed later on Monday
didn't interact with these patches, but the cfbot disabused me
of that folly. Here's a rebased v7 --- no substantive change.
Alexander Lakhin writes:
> Maybe you would like to fix in passing several (not new) defects, I've
> found while playing with ecpg under Valgrind:
Done. After evaluation I concluded that none of these were worth the
trouble to back-patch, but by all means let's fix such things in HEAD.
Hello Tom,
14.10.2024 21:25, Tom Lane wrote:
Attached are rebased and renumbered 0006-0008, mostly to keep the
cfbot happy. We could actually stop here, if we were feeling lazy,
but now that I've done the work I'm inclined to push forward with
the rest.
The rest is just memory leak removal, an
John Naylor writes:
>> [v5]
Thanks for reviewing! I pushed 0001-0005 and 0009, adopting
your suggestions except for
> + /* List a token here if pgc.l assigns to base_yylval.str for it */
> Does pgc.l need to have a similar comment?
That's not a bad suggestion, but I couldn't see any very usefu
> [v5]
0001 - LGTM, maybe can be squashed with 0009?
0002 - I went through this again and don't see anything that should
raise eyebrows.
+ # HACK: insert our own %nonassoc line after IDENT.
+ # XXX: this seems pretty wrong, IDENT is not last on its line!
We can come back to this afterwards, as
On Saturday, October 5, 2024, Tom Lane wrote:
>
>
> Rebase needed after f22e84df1, so here's an update that rebases
> up to HEAD and adds the missing "static". No other changes.
>
> (Anybody want to review this? I'm getting tired of rebasing it,
> and we're missing out on the clang build time sa
I wrote:
> Thanks, done. Here's a revised patchset.
The cfbot points out that I should probably have marked progname
as "static" in 0008. I'm not going to repost the patchset just for
that, though.
regards, tom lane
On 15.08.24 02:43, Tom Lane wrote:
I wrote:
Here's a rebased but otherwise identical patchset. I also added
an 0007 that removes check_rules.pl as threatened.
I've done some more work on this and hope to post an updated patchset
tomorrow. Before that though, is there any objection to going a
I wrote:
> Here's a rebased but otherwise identical patchset. I also added
> an 0007 that removes check_rules.pl as threatened.
I've done some more work on this and hope to post an updated patchset
tomorrow. Before that though, is there any objection to going ahead
with pushing the 0001 patch (p
On Fri, Jul 5, 2024 at 10:59 PM Tom Lane wrote:
>
> The cfbot noticed that this patchset had a conflict with d35cd0619,
> so here's a rebase. It's just a rebase of v1, no other changes.
Hi Tom,
I started looking at the earlier cleanup patches.
0001 seems straightforward. Note: It doesn't apply
On Fri, Apr 19, 2024 at 10:21 PM Tom Lane wrote:
>
> One other bit of randomness that I noticed: ecpg's parse.pl has
> this undocumented bit of logic:
>
> if ($a eq 'IDENT' && $prior eq '%nonassoc')
> {
>
> # add more tokens to the list
>
One other bit of randomness that I noticed: ecpg's parse.pl has
this undocumented bit of logic:
if ($a eq 'IDENT' && $prior eq '%nonassoc')
{
# add more tokens to the list
$str = $str . "\n%nonassoc CSTRING";
Andres Freund writes:
> On 2024-04-18 23:11:52 -0400, Tom Lane wrote:
>> I was just looking locally at what I got by removing that, and sadly
>> I don't think I believe it: there are a lot of places where it claims
>> we hit lines we don't, and vice versa. That might be partially
>> blamable on o
On 2024-04-18 23:11:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-04-18 22:18:34 -0400, Tom Lane wrote:
> >> (If our code coverage tools worked on bison/flex stuff,
> >> maybe this'd be less scary ... but they don't.)
>
> > For bison coverage seems to work, see e.g.:
>
> Yeah, I'd
Andres Freund writes:
> On 2024-04-18 22:18:34 -0400, Tom Lane wrote:
>> (If our code coverage tools worked on bison/flex stuff,
>> maybe this'd be less scary ... but they don't.)
> For bison coverage seems to work, see e.g.:
Yeah, I'd just noticed that --- I had it in my head that we'd put
LCOV
Hi,
On 2024-04-18 22:18:34 -0400, Tom Lane wrote:
> Here is a patch series that aims to clean up ecpg's preprocessor
> code a little and fix the compile time problems we're seeing with
> late-model clang [1]. I guess whether it's a cleanup is in the eye of
> the beholder, but it definitely succee
20 matches
Mail list logo
