On sön, 2012-07-01 at 19:04 +0200, Stefan Kaltenbrunner wrote:
> seeing some of the latest commits about fixing compiler warnings I
> took a look at the buildfarm to see if there are any interesting ones
> there (in total we have a thousends of warnings on the buildfarm but
> most of those are from
seeing some of the latest commits about fixing compiler warnings I took
a look at the buildfarm to see if there are any interesting ones there
(in total we have a thousends of warnings on the buildfarm but most of
those are from very noisy compilers).
so in case anybody is interested those are a s
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane napsal(a):
>> That should be gone now; I changed the two places that triggered it.
>> I'd suggest not disabling that warning.
> Yes I agree. Did you also clean up on old branches?
No, I'm not interested in doing that kind of fiddling on old bra
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
E_FUNC_HAS_NO_RETURN_STMT is there because main is leaved by exit() instead
return. And In another case It should be regular warning.
That should be gone now; I changed the two places that triggered it.
I'd suggest not disabling tha
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> E_FUNC_HAS_NO_RETURN_STMT is there because main is leaved by exit() instead
> return. And In another case It should be regular warning.
That should be gone now; I changed the two places that triggered it.
I'd suggest not disabling that warning.
Stefan Kaltenbrunner napsal(a):
Zdenek Kotala wrote:
Stefan Kaltenbrunner wrote:
Zdenek Kotala wrote:
Stefan Kaltenbrunner wrote:
Zdenek Kotala wrote:
For sun studio -erroff=E_STATEMENT_NOT_REACHED is useful there. If you
want to determine warning tags for each warning add -errtags.
Is that
"Stefan Kaltenbrunner" <[EMAIL PROTECTED]> writes:
> "pgstat.c", line 652: warning: const object should have initializer:
> all_zeroes (E_CONST_OBJ_SHOULD_HAVE_INITIZR)
> "pgstat.c", line 2118: warning: const object should have initializer:
> all_zeroes (E_CONST_OBJ_SHOULD_HAVE_INITIZR)
Man, eve
Zdenek Kotala wrote:
> Stefan Kaltenbrunner wrote:
>> Zdenek Kotala wrote:
>>> Stefan Kaltenbrunner wrote:
Zdenek Kotala wrote:
> For sun studio -erroff=E_STATEMENT_NOT_REACHED is useful there. If you
> want to determine warning tags for each warning add -errtags.
Is that supporte
Stefan Kaltenbrunner wrote:
Zdenek Kotala wrote:
Stefan Kaltenbrunner wrote:
Zdenek Kotala wrote:
For sun studio -erroff=E_STATEMENT_NOT_REACHED is useful there. If you
want to determine warning tags for each warning add -errtags.
Is that supported on all versions of sun studio(Sun WorkShop 6
Gregory Stark <[EMAIL PROTECTED]> writes:
> It's possible I've done the autoconf hackery wrong though. Should
> UINT64_FORMAT still be defined if there's no int64?
Yes.
regards, tom lane
---(end of broadcast)---
TIP 9: In ve
Do any of the build farm machines not support 64-bit integers? I just added a
--enable-bigint flag to configure.in and tested building without it and got an
error at xlog.c:
xlog.c: In function 'ValidXLOGHeader':
xlog.c:3240: error: 'UINT64_FORMAT' undeclared (first use in this function)
xlog.c:3
Chris Browne <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> animal: grebe warnings: 45
>>> xlog.c:651: warning: implicit declaration of function '_check_lock'
>>> xlog.c:654: warning: implicit declaration of function '_clear_lock'
>>> hba.c:1449: warning: implicit declaration of fu
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Anyway, I tweaked plpgsql's Makefile to force LC_CTYPE=3DC, which
>> theoretically should silence this warning.
> This doesn't mean that people were previousy able to use any of these "exot=
> ic"
> characters li
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> and this is the initial list for contrib(excluding a lot of duplicate
> warnings and stuff that is a result of invalid compiler flags which I
> will mention seperatly):
I fixed most of these, I believe. A couple remain untouched:
> animal: cucko
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Anyway, I tweaked plpgsql's Makefile to force LC_CTYPE=C, which
> theoretically should silence this warning.
This doesn't mean that people were previousy able to use any of these "exotic"
characters like aßertion or explaïn if they happened to compile in t
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What I suspect is happening is that lionfish is running the buildfarm
>> script in a non-C locale, in which flex finds that some high-bit-set
>> characters are case-folded by tolower() and accordingly issues this
>> complaint. N
Zdenek Kotala wrote:
> Stefan Kaltenbrunner wrote:
>> Zdenek Kotala wrote:
>
>>> For sun studio -erroff=E_STATEMENT_NOT_REACHED is useful there. If you
>>> want to determine warning tags for each warning add -errtags.
>>
>> Is that supported on all versions of sun studio(Sun WorkShop 6, Sun
>> Stu
[EMAIL PROTECTED] (Stefan Kaltenbrunner) writes:
> Tom Lane wrote:
> [...]
>>> animal: clownfish warnings: 12
>>> "dynloader.c", line 4: warning: empty translation unit
>>> "postgres.c", line 3758: warning: loop not entered at top
>>
>> The first of these is not a bug, the second seems
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Zdenek Kotala wrote:
I don't see any "const" keyword there.
Right after that:
where int conv(int num_msg, const struct pam_message **msg, struct pam_response **resp, void *appdata_ptr);
How confusing...
And the pam_start
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Zdenek Kotala wrote:
>> I don't see any "const" keyword there.
> Right after that:
>> where int conv(int num_msg, const struct pam_message **msg, struct
>> pam_response **resp, void *appdata_ptr);
> How confusing...
And the pam_start page he ci
Heikki Linnakangas wrote:
Zdenek Kotala wrote:
If I look there
http://www.opengroup.org/onlinepubs/008329799/chap5.htm#tagcjh_06
in "Call Back Information" section. The structure is defined as
struct pam_conv{ int (*conv) (int, struct pam_message **, struct
pam_response **, void *); void
Zdenek Kotala wrote:
If I look there
http://www.opengroup.org/onlinepubs/008329799/chap5.htm#tagcjh_06
in "Call Back Information" section. The structure is defined as
struct pam_conv{ int (*conv) (int, struct pam_message **, struct
pam_response **, void *); void *appdata_ptr; };
I don'
Kris Jurka wrote:
On Fri, 13 Jul 2007, Zdenek Kotala wrote:
Tom Lane wrote:
Kris Jurka <[EMAIL PROTECTED]> writes:
So pam_message ** isn't const.
Ah, thanks. I see luna_moth is giving the same warning, so it's still
not const in Solaris 11 either.
Is it worth working around this? It's
On Fri, 13 Jul 2007, Zdenek Kotala wrote:
Tom Lane wrote:
Kris Jurka <[EMAIL PROTECTED]> writes:
So pam_message ** isn't const.
Ah, thanks. I see luna_moth is giving the same warning, so it's still
not const in Solaris 11 either.
Is it worth working around this? It's strictly cosmetic A
Stefan Kaltenbrunner wrote:
Zdenek Kotala wrote:
For sun studio -erroff=E_STATEMENT_NOT_REACHED is useful there. If you
want to determine warning tags for each warning add -errtags.
Is that supported on all versions of sun studio(Sun WorkShop 6, Sun
Studio 8,11) we have on the farm ?
Yes.
Tom Lane wrote:
Kris Jurka <[EMAIL PROTECTED]> writes:
So pam_message ** isn't const.
Ah, thanks. I see luna_moth is giving the same warning, so it's still
not const in Solaris 11 either.
Is it worth working around this? It's strictly cosmetic AFAICS.
The main issue in my mind would be how
Zdenek Kotala wrote:
> Stefan Kaltenbrunner wrote:
>> Peter Eisentraut wrote:
>>> Am Donnerstag, 12. Juli 2007 15:25 schrieb Stefan Kaltenbrunner:
a lot of those are simply noise (like the LOOP VECTORIZED stuff from
the
icc boxes or the "statement not reached" spam from the sun compi
Stefan Kaltenbrunner wrote:
Peter Eisentraut wrote:
Am Donnerstag, 12. Juli 2007 15:25 schrieb Stefan Kaltenbrunner:
a lot of those are simply noise (like the LOOP VECTORIZED stuff from the
icc boxes or the "statement not reached" spam from the sun compilers)
but others might indicate real issu
Kris Jurka wrote:
On Thu, 12 Jul 2007, Tom Lane wrote:
static int pam_passwd_conv_proc(int num_msg, const struct pam_message
** msg,
struct pam_response ** resp, void *appdata_ptr);
which exactly matches what my Fedora 6 pam header file says it should
be. What is it on
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> ok I did that for a few members (removing all the statement not reached
>> ones as well as some purely informal notices and all the flex related
>> warnings) and came up with something similiar to:
>> [snip]
>
> Yeah, this looks
Tom Lane wrote:
[...]
>> animal: clownfish warnings: 12
>> "dynloader.c", line 4: warning: empty translation unit
>> "postgres.c", line 3758: warning: loop not entered at top
>
> The first of these is not a bug, the second seems to be some weird
> aberration in their statement-not-reache
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> some more(I have removed duplicates and ones that should be fixed by
>> your latest commits though):
>
> I did what I could with this batch. Some comments:
>
>> animal: salamander warnings: 27
>> cash.c: In function `
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> animal: lionfishwarnings: 16
>> scan.l:180: warning, the character range [<80>-] is ambiguous in a
>> case-insensitive scanner
>> scan.l:180: warning, the character range [<80>-] is ambiguous in a
>> case-insensitive
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> some more(I have removed duplicates and ones that should be fixed by
> your latest commits though):
I did what I could with this batch. Some comments:
> animal: salamander warnings: 27
> cash.c: In function `cash_in':
> cash.c:244: warn
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> animal: lionfishwarnings: 16
> scan.l:180: warning, the character range [<80>-] is ambiguous in a
> case-insensitive scanner
> scan.l:180: warning, the character range [<80>-] is ambiguous in a
> case-insensitive scanner
> scan.l:302: w
On Thu, 12 Jul 2007, Stefan Kaltenbrunner wrote:
> > What would probably be useful if you want to pursue this is to filter
> > out the obvious spam like statement-not-reached, and see what's left.
>
I had gone through and looked at the warnings on mongoose before, but I am
running it against the
Kris Jurka <[EMAIL PROTECTED]> writes:
> So pam_message ** isn't const.
Ah, thanks. I see luna_moth is giving the same warning, so it's still
not const in Solaris 11 either.
Is it worth working around this? It's strictly cosmetic AFAICS.
The main issue in my mind would be how to determine whet
Tom Lane wrote:
At the same time, if anyone wants to trim the existing code down to a
small test case, I'm sure the gcc boys would appreciate a bug report.
I reduced it to a self-contained test case, and filed bug in GCC
bugzilla: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32750
Surprisingl
On Thu, 12 Jul 2007, Tom Lane wrote:
static int pam_passwd_conv_proc(int num_msg, const struct pam_message ** msg,
struct pam_response ** resp, void *appdata_ptr);
which exactly matches what my Fedora 6 pam header file says it should
be. What is it on those Solaris machin
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> animal: dragonfly warnings: 67
> auth.c:61: warning: initialization from incompatible pointer type
> animal: emperor_mothwarnings: 10
> auth.c:61: warning: initialization from incompatible pointer type
Apparently, Solaris 9 and
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Somebody needs to figure out whether we are supposed to be using
>> pgsymlink on Cygwin.
> According to port.h:
> * Cygwin has its own symlinks which work on Win95/98/ME where
> * junction points don't, so use it instead. We have
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> FWIW, this patch makes the warnings go away, and makes the code a little
> bit more readable as well. It would be nice to understand why exactly
> it's complaining, though.
Let's apply the patch. We are clearly tickling a bug or near-bug in
gcc,
Tom Lane wrote:
animal: eel warnings: 4
dirmod.c:206: warning: no previous prototype for 'pgsymlink'
Somebody needs to figure out whether we are supposed to be using
pgsymlink on Cygwin.
According to port.h:
* Cygwin has its own symlinks which work on Win95/98/ME
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Hmm. It looks like I get that warning on my laptop as well. I tracked it
down to these two places:
Line 209:
while (ptr - GETARR(trg) < ARRNELEM(trg))
{
text *item = (text *) palloc(VARHDRSZ + 3);
S
Gregory Stark wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
The warning seems to be in related array indexing. If you replace ptr -
GETARR(trg) with a constant, the warning goes away. But having "i = ptr -
GETARR(trg)" in there doesn't give a warning.
Can you compile with -save-temp
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> ok I did that for a few members (removing all the statement not reached
> ones as well as some purely informal notices and all the flex related
> warnings) and came up with something similiar to:
I've cleaned up most of this first batch. Open iss
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Hmm. It looks like I get that warning on my laptop as well. I tracked it
down to these two places:
Line 209:
while (ptr - GETARR(trg) < ARRNELEM(trg))
{
text *item = (text *) palloc(VARHDRSZ + 3);
S
Gregory Stark <[EMAIL PROTECTED]> writes:
> If it does constant propagation without handling overflow it could end up
> with:
> (olddatum >> 2 << 2) & 0x3FFFC
> note that in fact truncating the high two bits as the assembler did would in
> fact be the correct thing to do here which would exp
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> The warning seems to be in related array indexing. If you replace ptr -
> GETARR(trg) with a constant, the warning goes away. But having "i = ptr -
> GETARR(trg)" in there doesn't give a warning.
Can you compile with -save-temps and send the cor
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Hmm. It looks like I get that warning on my laptop as well. I tracked it
> down to these two places:
> Line 209:
>> while (ptr - GETARR(trg) < ARRNELEM(trg))
>> {
>> text *item = (text *) palloc(VARHDRSZ + 3);
>>
>> SET_VARSIZ
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
Stefan showed me via Jabber this warning:
/tmp/ccM7MfqX.s: Assembler messages:
/tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to
fffc
/tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to
000
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Stefan showed me via Jabber this warning:
>>
>> /tmp/ccM7MfqX.s: Assembler messages:
>> /tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc
>> /tmp/ccM7MfqX.s:738: Warning: 0003fffc shorte
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> Stefan showed me via Jabber this warning:
>> /tmp/ccM7MfqX.s: Assembler messages:
>> /tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to
>> fffc
>> /tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to
>> f
Alvaro Herrera wrote:
Stefan showed me via Jabber this warning:
/tmp/ccM7MfqX.s: Assembler messages:
/tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc
/tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to fffc
He says that this comes from trgm_op.c f
Alvaro Herrera wrote:
> Stefan showed me via Jabber this warning:
>
> /tmp/ccM7MfqX.s: Assembler messages:
> /tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc
> /tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to fffc
>
> He says that this comes from
Stefan showed me via Jabber this warning:
/tmp/ccM7MfqX.s: Assembler messages:
/tmp/ccM7MfqX.s:703: Warning: 0003fffc shortened to fffc
/tmp/ccM7MfqX.s:738: Warning: 0003fffc shortened to fffc
He says that this comes from trgm_op.c file. I don't get the w
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> ok I did that for a few members (removing all the statement not reached
>> ones as well as some purely informal notices and all the flex related
>> warnings) and came up with something similiar to:
>> [snip]
>
> Yeah, this looks
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Yeah, this looks like a good list. I can't readily check the ones from
>>> "eel" as they appear to be in Windows-specific code; anyone else want to
>>> fix those?
>
>> The pg_ctl one is a windows one, I'll deal w
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah, this looks like a good list. I can't readily check the ones from
>> "eel" as they appear to be in Windows-specific code; anyone else want to
>> fix those?
> The pg_ctl one is a windows one, I'll deal with that one.
> The dirm
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> ok I did that for a few members (removing all the statement not reached
>> ones as well as some purely informal notices and all the flex related
>> warnings) and came up with something similiar to:
>> [snip]
>
> Yeah, this looks
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> ok I did that for a few members (removing all the statement not reached
> ones as well as some purely informal notices and all the flex related
> warnings) and came up with something similiar to:
> [snip]
Yeah, this looks like a good list. I can'
Peter Eisentraut wrote:
> Am Donnerstag, 12. Juli 2007 15:25 schrieb Stefan Kaltenbrunner:
>> a lot of those are simply noise (like the LOOP VECTORIZED stuff from the
>> icc boxes or the "statement not reached" spam from the sun compilers)
>> but others might indicate real issues.
>> To find warnin
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> What is the official stance on handling compiler warnings?
>
> The compilers I use give me 1 or 2 warnings on HEAD, coming from flex's
> sloppiness about not generating unused code. I wouldn't care to work
> with a compiler tha
Am Donnerstag, 12. Juli 2007 15:25 schrieb Stefan Kaltenbrunner:
> a lot of those are simply noise (like the LOOP VECTORIZED stuff from the
> icc boxes or the "statement not reached" spam from the sun compilers)
> but others might indicate real issues.
> To find warnings that might be a real proble
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> What is the official stance on handling compiler warnings?
The compilers I use give me 1 or 2 warnings on HEAD, coming from flex's
sloppiness about not generating unused code. I wouldn't care to work
with a compiler that generated more than a few
What is the official stance on handling compiler warnings?
I got a bit curious today on how many warnings our builds are generating
on the buildfarm.
I have hacked up a small script that (in a very primitive way) parses
the "make" stage logfiles of all unix boxes reporting on HEAD and prints
the nu
66 matches
Mail list logo
