new version under:
http://zlew.org/postgresql_static_check/scan-build-2009-10-03-1/
What's strange, is the increase of 48.2 percent in reports, that
happened about two weeks before (weekend before the previous one).
enjoy.
--
Sent via pgsql-hackers mailing list
http://llvm.org/bugs/show_bug.cgi?id=4979
will see, one issue is already fixed. I'll retry when the second one
is too.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via
On Mon, Sep 14, 2009 at 06:39:11PM +0100, Grzegorz Jaskiewicz wrote:
meanwhile, since quite a lot stuff went in over weekend, and since
Yesterday, new report at:
http://zlew.org/postgresql_static_check/scan-build-2009-09-14-1/
Looking at
2009/9/15 Michael Meskes mes...@postgresql.org:
Looking at
http://zlew.org/postgresql_static_check/scan-build-2009-09-14-1/report-3LPmKK.html#EndPath
it tells me that the value stored to 'counter' is never used. However, the
counter++ is called inside a loop and thus will be read the next
On 14 Sep 2009, at 06:04, Tom Lane wrote:
Looks like the clang guys still have some work to do.
Thanks Tom, reported to clang dev's .
meanwhile, since quite a lot stuff went in over weekend, and since
Yesterday, new report at:
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
usual round of updates to the scan report.
Today's report available at:
http://zlew.org/postgresql_static_check/scan-build-2009-09-12-1/
Looks like the clang guys still have some work to do. The
null-dereference reports, in particular, seem
usual round of updates to the scan report.
Today's report available at:
http://zlew.org/postgresql_static_check/scan-build-2009-09-12-1/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
clang developers were quick to iron out their bugs, here's Today report:
http://zlew.org/postgresql_static_check/scan-build-2009-09-04-1/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
new report: http://zlew.org/postgresql_static_check/scan-build-2009-09-02-1/
archive one dir up, as usual (with index of all previous reports).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Grzegorz Jaskiewicz escribió:
new report: http://zlew.org/postgresql_static_check/scan-build-2009-09-02-1/
archive one dir up, as usual (with index of all previous reports).
What's with the analyzer failures? Did you submit bug reports about
them?
--
Alvaro Herrera
On 2 Sep 2009, at 21:38, Alvaro Herrera wrote:
Grzegorz Jaskiewicz escribió:
new report: http://zlew.org/postgresql_static_check/scan-build-2009-09-02-1/
archive one dir up, as usual (with index of all previous reports).
What's with the analyzer failures? Did you submit bug reports about
On 29 Aug 2009, at 18:05, Greg Stark wrote:
Oh, I think I see what's happening. Our assertions can still be turned
off at run-time with the variable assert_enabled.
Index: src/include/postgres.h
===
RCS file:
okay, I think I nailed the assert part right. (3rd iteration, about
time...).
as usual: http://zlew.org/postgresql_static_check/scan-build-2009-08-30-2/
archive one dir up.
the current patch attached.
postgres_checker_patch.patch.bz2
Description: BZip2 compressed data
--
Sent via
On lör, 2009-08-29 at 17:35 +0100, Greg Stark wrote:
We still have things like this showing division by zero:
Assert(activeTapes 0);
1913 slotsPerTape = (state-memtupsize - state-mergefirstfree) /
activeTapes;
It looks like if you marked ExceptionalCondition() as never
On Sun, Aug 30, 2009 at 3:26 PM, Peter Eisentrautpete...@gmx.net wrote:
On lör, 2009-08-29 at 17:35 +0100, Greg Stark wrote:
We still have things like this showing division by zero:
Assert(activeTapes 0);
1913 slotsPerTape = (state-memtupsize - state-mergefirstfree) /
activeTapes;
So three of the four dead initialization warnings are legitimate -- if
minor -- errors. Attached is a patch to remove the redundant
initializations.
--
greg
http://mit.edu/~gsstark/resume.pdf
diff --git a/src/backend/tsearch/regis.c b/src/backend/tsearch/regis.c
index 8980c2a..e492562 100644
On 30 Aug 2009, at 15:46, Greg Stark wrote:
So three of the four dead initialization warnings are legitimate -- if
minor -- errors. Attached is a patch to remove the redundant
initializations.
well, all I can do is this: http://llvm.org/bugs/show_bug.cgi?id=4832
I find it hard to belive
On Sun, Aug 30, 2009 at 3:57 PM, Grzegorz Jaskiewiczg...@pointblue.com.pl
wrote:
On 30 Aug 2009, at 15:46, Greg Stark wrote:
So three of the four dead initialization warnings are legitimate -- if
minor -- errors. Attached is a patch to remove the redundant
initializations.
well, all I
Greg Stark gsst...@mit.edu writes:
I think most of the remaining false positives are cases where palloc,
palloc0, repalloc, MemoryContextAlloc, or MemoryContextAllocZero
return values are deferenced. Clang doesn't know that these functions
never return NULL so it's marking every case as a
Greg Stark gsst...@mit.edu writes:
So three of the four dead initialization warnings are legitimate -- if
minor -- errors. Attached is a patch to remove the redundant
initializations.
Applied, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list
with Greg's suggested palloc and friends patch:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-3
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Aug 30, 2009 at 5:58 PM, Grzegorz Jaskiewiczg...@pointblue.com.pl
wrote:
with Greg's suggested palloc and friends patch:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-3
Argh. That didn't help at all. hm, I suppose instead of (exit(1),NULL)
we could just put ((void*)1)
On 30 Aug 2009, at 18:07, Greg Stark wrote:
On Sun, Aug 30, 2009 at 5:58 PM, Grzegorz Jaskiewiczg...@pointblue.com.pl
wrote:
with Greg's suggested palloc and friends patch:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-3
Argh. That didn't help at all. hm, I suppose instead
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
please don't tell me that this is bogus: http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/report-7JaICX.html#EndPath
?
How come ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 30 Aug 2009, at 19:14, Tom Lane wrote:
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
please don't tell me that this is bogus:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/report-7JaICX.html#EndPath
Yes, it's bogus. ctid is never passed as NULL. It might point at
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
On 30 Aug 2009, at 19:14, Tom Lane wrote:
Yes, it's bogus. ctid is never passed as NULL. It might point at
an invalid itempointer (one with ip_posid == 0). Look at the only
call site.
so why do we check if the pointer is valid ?
[
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
please don't tell me that this is bogus:
http://zlew.org/postgresql_static_check/scan-build-2009-08-30-4/report-7JaICX.html#EndPath
Yes, it's bogus. ctid is never passed as NULL. It might point at
an invalid itempointer (one with ip_posid
new one at http://zlew.org/postgresql_static_check/scan-build-2009-08-29-3/
archive at :
http://zlew.org/postgresql_static_check/postgresql_static_check_29thAugust2009.tar.xz
as always, comments are welcomed. And constructive explanation of any
wrong-results will be relayed to clang-checker
We still have things like this showing division by zero:
Assert(activeTapes 0);
1913slotsPerTape = (state-memtupsize - state-mergefirstfree) /
activeTapes;
It looks like if you marked ExceptionalCondition() as never returning
then it should hide this.
--
greg
On 29 Aug 2009, at 17:35, Greg Stark wrote:
We still have things like this showing division by zero:
Assert(activeTapes 0);
1913 slotsPerTape = (state-memtupsize - state-mergefirstfree) /
activeTapes;
It looks like if you marked ExceptionalCondition() as never returning
then it should
Oh, I think I see what's happening. Our assertions can still be turned
off at run-time with the variable assert_enabled.
Hm, you would have to replace assert_enabled with a #define in
postgres.h and then do something about the guc.c code which assigns to
it.
On another note is there any way to
On 24 Aug 2009, at 14:40, Peter Eisentraut wrote:
On mån, 2009-08-24 at 00:42 +0100, Grzegorz Jaskiewicz wrote:
--enable-cassert, enabled, and also added exit_* in pg_dump to list
of functions that never return.
A few more functions to mark noreturn: DateTimeParseError(), and
heh, sorry folks for the noise again :/
There was a fair amount of false positives there - due to nature of
Assert() macro. Mainly, since assert_enabled is a runtime variable,
not a macro (which I sadly overlooked).
So, hardcoding it to (1) (using CPP) removed quite few false positives.
On Thu, Aug 27, 2009 at 06:39, Grzegorz Jaskiewiczg...@pointblue.com.pl wrote:
heh, sorry folks for the noise again :/
There was a fair amount of false positives there - due to nature of Assert()
macro. Mainly, since assert_enabled is a runtime variable, not a macro
(which I sadly
Alex Hunsaker bada...@gmail.com writes:
(do you have to mark every function that calls ereport(ERROR) as one
that exits?)
That would be an open-ended project, and probably in many cases wouldn't
change the clang report anyway. I think it's only worth worrying about
the ones that we find will
On mån, 2009-08-24 at 00:42 +0100, Grzegorz Jaskiewicz wrote:
--enable-cassert, enabled, and also added exit_* in pg_dump to list
of functions that never return.
A few more functions to mark noreturn: DateTimeParseError(), and
die_horribly() in pg_dump
--
Sent via pgsql-hackers mailing
On Sun, Aug 23, 2009 at 4:57 PM, Grzegorz Jaskiewiczg...@pointblue.com.pl
wrote:
I am sure there's plenty of false positives, but I am also quite sure
there's many real errors on that list.
Do you know how to teach clang about functions which never return?
That seems to be causing most of the
On 23 Aug 2009, at 17:41, Greg Stark wrote:
On Sun, Aug 23, 2009 at 4:57 PM, Grzegorz Jaskiewiczg...@pointblue.com.pl
wrote:
I am sure there's plenty of false positives, but I am also quite sure
there's many real errors on that list.
Do you know how to teach clang about functions which
On Sun, Aug 23, 2009 at 05:41:24PM +0100, Greg Stark wrote:
On Sun, Aug 23, 2009 at 4:57 PM, Grzegorz Jaskiewiczg...@pointblue.com.pl
wrote:
I am sure there's plenty of false positives, but I am also quite sure
there's many real errors on that list.
Do you know how to teach clang about
On 23 Aug 2009, at 17:41, Greg Stark wrote:
Do you know how to teach clang about functions which never return?
http://clang-analyzer.llvm.org/annotations.html#attr_noreturn
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/report-MAVb5D.html#EndPath
for a very positive one - at least from strict language point of view.
consider: float f = 1; f++; printf(%f\n, f);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Sun, Aug 23, 2009 at 6:11 PM, Grzegorz Jaskiewiczg...@pointblue.com.pl
wrote:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/report-MAVb5D.html#EndPath
for a very positive one - at least from strict language point of view.
consider: float f = 1; f++; printf(%f\n,
about the false positives around 'null reference'. I'll try sticking
exit(1)'s at the end of each macro - and see if that makes most of
them go away.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Greg Stark gsst...@mit.edu writes:
On Sun, Aug 23, 2009 at 6:11 PM, Grzegorz Jaskiewiczg...@pointblue.com.pl
wrote:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/report-MAVb5D.html#EndPath
for a very positive one - at least from strict language point of view.
consider:
memory leak:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-5/report-46wcmJ.html#EndPath
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
this one should contain substantialy less false positives, because
error functions were marked as the 'never exit' points:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-9/
for the record, here's patch that marks elog, etc as dead ends:
Index: src/include/utils/elog.h
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
for the record, here's patch that marks elog, etc as dead ends:
That does not look like the right thing at all, since now the checker
will believe that elog(NOTICE) and such don't return. I think you
need to use Martijn's suggestion instead.
On 23 Aug 2009, at 20:31, Tom Lane wrote:
Grzegorz Jaskiewicz g...@pointblue.com.pl writes:
for the record, here's patch that marks elog, etc as dead ends:
That does not look like the right thing at all, since now the checker
will believe that elog(NOTICE) and such don't return. I think
ok folks, here's the last one for Today:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-29/
tar ball with report can be downloaded from here: http://zlew.org/postgresql_static_check/postgresql_static_check_23rdAugust2009.tar.xz
(compressed with lzma's xz tool).
here's the
On Sun, Aug 23, 2009 at 11:16 PM, Grzegorz
Jaskiewiczg...@pointblue.com.pl wrote:
ok folks, here's the last one for Today:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-29/
This does look better. The first one I looked at looks like a
legitimate bug. The nice thing is that this
On 24 Aug 2009, at 00:15, Greg Stark wrote:
On Sun, Aug 23, 2009 at 11:16 PM, Grzegorz
Jaskiewiczg...@pointblue.com.pl wrote:
ok folks, here's the last one for Today:
http://zlew.org/postgresql_static_check/scan-build-2009-08-23-29/
This does look better. The first one I looked at looks
52 matches
Mail list logo
