SEO

while looking at some other stuff I noticed that we have the following
compiler warning on OpenBSD 4.0/amd64 with the OS supplied compiler:

gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wendif-labels -fno-strict-aliasing -DFRONTEND
-I../../../src/interfaces/libpq -I../../../src/include
-I/usr/include/kerberosV/ -c -o initdb.o initdb.c
initdb.c: In function `locale_date_order':
initdb.c:2187: warning: `%x' yields only last 2 digits of year in some
locales


$ gcc -v
Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd4.0/3.3.5/specs
Configured with:
Thread model: single
gcc version 3.3.5 (propolice)


Stefan

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> while looking at some other stuff I noticed that we have the following
> compiler warning on OpenBSD 4.0/amd64 with the OS supplied compiler:
> initdb.c:2187: warning: `%x' yields only last 2 digits of year in some
> locales

Yeah, mine complains about that too. Peter's response was "get a newer
compiler" --- apparently the gcc folks thought better of this warning
after the Y2K panic subsided.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> while looking at some other stuff I noticed that we have the following
>> compiler warning on OpenBSD 4.0/amd64 with the OS supplied compiler:
>> initdb.c:2187: warning: `%x' yields only last 2 digits of year in some
>> locales
>
> Yeah, mine complains about that too. Peter's response was "get a newer
> compiler" --- apparently the gcc folks thought better of this warning
> after the Y2K panic subsided.

hmm ok - but at least on openbsd we will have to accept that warning for
a few years to go (4.1 shipped with 3.3.5 and it seems that the
upcoming 4.2 is not getting an upgraded compiler either)


Stefan

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Stefan Kaltenbrunner wrote:
> Tom Lane wrote:
> > Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> >> while looking at some other stuff I noticed that we have the following
> >> compiler warning on OpenBSD 4.0/amd64 with the OS supplied compiler:
> >> initdb.c:2187: warning: `%x' yields only last 2 digits of year in some
> >> locales
> >
> > Yeah, mine complains about that too. Peter's response was "get a newer
> > compiler" --- apparently the gcc folks thought better of this warning
> > after the Y2K panic subsided.
>
> hmm ok - but at least on openbsd we will have to accept that warning for
> a few years to go (4.1 shipped with 3.3.5 and it seems that the
> upcoming 4.2 is not getting an upgraded compiler either)

My local manpage for strftime says that we can get around this warning
by overloading it with something like

size_t
my_strftime(char *s, size_t max, const char *fmt,
const struct tm *tm)
{
return strftime(s, max, fmt, tm);
}


--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Alvaro Herrera <alvherre@commandprompt.com> writes:
> My local manpage for strftime says that we can get around this warning
> by overloading it with something like

> size_t
> my_strftime(char *s, size_t max, const char *fmt,
> const struct tm *tm)
> {
> return strftime(s, max, fmt, tm);
> }

Hey, that works nicely. On my version of gcc, it suppresses the warning
even if my_strftime is marked "static inline", which should mean that
there's no runtime penalty.

I've committed the patch to HEAD --- Stefan, would you check if it
silences your version of gcc?

Now if we could only get rid of those flex-induced warnings in ecpg...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> My local manpage for strftime says that we can get around this warning
>> by overloading it with something like
>
>> size_t
>> my_strftime(char *s, size_t max, const char *fmt,
>> const struct tm *tm)
>> {
>> return strftime(s, max, fmt, tm);
>> }
>
> Hey, that works nicely. On my version of gcc, it suppresses the warning
> even if my_strftime is marked "static inline", which should mean that
> there's no runtime penalty.
>
> I've committed the patch to HEAD --- Stefan, would you check if it
> silences your version of gcc?

yeah that patch fixes the warning for me too - thanks!

Stefan

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

On Wed, Jul 11, 2007 at 07:18:17PM -0400, Tom Lane wrote:
> Now if we could only get rid of those flex-induced warnings in ecpg...

Don't you get the same in the backend's parser code? I surely do.

It seems these are only missing prototypes. How about adding an include
file with those prototypes?

Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Michael Meskes <meskes@postgresql.org> writes:
> On Wed, Jul 11, 2007 at 07:18:17PM -0400, Tom Lane wrote:
>> Now if we could only get rid of those flex-induced warnings in ecpg...

> Don't you get the same in the backend's parser code? I surely do.

No, ecpg is the only one producing warnings for me. What flex version
do you use?

> It seems these are only missing prototypes. How about adding an include
> file with those prototypes?

What I get with flex 2.5.4 is

pgc.c: In function `base_yylex':
pgc.c:1564: warning: label `find_rule' defined but not used
preproc.y: At top level:
pgc.c:3818: warning: `yy_flex_realloc' defined but not used

neither of which seem fixable that way.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Tom Lane wrote:
> Michael Meskes <meskes@postgresql.org> writes:
>> On Wed, Jul 11, 2007 at 07:18:17PM -0400, Tom Lane wrote:
>>> Now if we could only get rid of those flex-induced warnings in ecpg...
>
>> Don't you get the same in the backend's parser code? I surely do.
>
> No, ecpg is the only one producing warnings for me. What flex version
> do you use?
>
>> It seems these are only missing prototypes. How about adding an include
>> file with those prototypes?
>
> What I get with flex 2.5.4 is
>
> pgc.c: In function `base_yylex':
> pgc.c:1564: warning: label `find_rule' defined but not used
> preproc.y: At top level:
> pgc.c:3818: warning: `yy_flex_realloc' defined but not used
>
> neither of which seem fixable that way.

I think Michael is refering to:

In file included from bootparse.y:380:
bootscanner.c:1855: warning: no previous prototype for
‘boot_yyget_lineno’
bootscanner.c:1864: warning: no previous prototype for ‘boot_yyget_in’
bootscanner.c:1872: warning: no previous prototype for ‘boot_yyget_out’
bootscanner.c:1880: warning: no previous prototype for ‘boot_yyget_leng’
bootscanner.c:1889: warning: no previous prototype for ‘boot_yyget_text’
bootscanner.c:1898: warning: no previous prototype for
‘boot_yyset_lineno’
bootscanner.c:1910: warning: no previous prototype for ‘boot_yyset_in’
bootscanner.c:1915: warning: no previous prototype for ‘boot_yyset_out’
bootscanner.c:1920: warning: no previous prototype for
‘boot_yyget_debug’
bootscanner.c:1925: warning: no previous prototype for
‘boot_yyset_debug’
bootscanner.c:1959: warning: no previous prototype for
‘boot_yylex_destroy’

In file included from gram.y:9663:
scan.c:7050: warning: no previous prototype for ‘base_yyget_lineno’
scan.c:7059: warning: no previous prototype for ‘base_yyget_in’
scan.c:7067: warning: no previous prototype for ‘base_yyget_out’
scan.c:7075: warning: no previous prototype for ‘base_yyget_leng’
scan.c:7084: warning: no previous prototype for ‘base_yyget_text’
scan.c:7093: warning: no previous prototype for ‘base_yyset_lineno’
scan.c:7105: warning: no previous prototype for ‘base_yyset_in’
scan.c:7110: warning: no previous prototype for ‘base_yyset_out’
scan.c:7115: warning: no previous prototype for ‘base_yyget_debug’
scan.c:7120: warning: no previous prototype for ‘base_yyset_debug’
scan.c:7154: warning: no previous prototype for ‘base_yylex_destroy’

....

http://buildfarm.postgresql.org/cgi-...53004&stg=make


Stefan


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> Tom Lane wrote:
>> What I get with flex 2.5.4 is
>>
>> pgc.c: In function `base_yylex':
>> pgc.c:1564: warning: label `find_rule' defined but not used
>> preproc.y: At top level:
>> pgc.c:3818: warning: `yy_flex_realloc' defined but not used
>>
>> neither of which seem fixable that way.

> I think Michael is refering to:

> In file included from bootparse.y:380:
> bootscanner.c:1855: warning: no previous prototype for=20
> =E2=80=98boot_yyget_lineno=E2=80=99
> bootscanner.c:1864: warning: no previous prototype for =E2=80=98boot_yyge=
> t_in=E2=80=99
> bootscanner.c:1872: warning: no previous prototype for =E2=80=98boot_yyge=
> t_out=E2=80=99
> bootscanner.c:1880: warning: no previous prototype for =E2=80=98boot_yyge=
> t_leng=E2=80=99
> bootscanner.c:1889: warning: no previous prototype for =E2=80=98boot_yyge=
> t_text=E2=80=99

[ shrug... ] Those are flex bugs.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly