Обсуждение: compile warnings
Since we're getting close to a freeze, I thought I'd point out these warnings again: make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/pgtypeslib' [...] i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/include -I/usr/kerberos/include -g -c -o timestamp.o timestamp.c -MMD timestamp.c: In function `dttofmtasc_replace': timestamp.c:468: warning: `%g' yields only last 2 digits of year timestamp.c:606: warning: `%x' yields only last 2 digits of year in some locales -and- make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/preproc' [...] i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -Wno-error -I./../include -I. -I../../../../src/include -I/usr/kerberos/include -DMAJOR_VERSION=3 -DMINOR_VERSION=0 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/usr/include\" -c -o preproc.o preproc.c -MMD In file included from preproc.y:6189: pgc.c: In function `yylex': pgc.c:1386: warning: label `find_rule' defined but not used /usr/include/ctype.h: At top level: pgc.c:3377: warning: `yy_flex_realloc' defined but not used Other than these 4 warnings, I get a clean compile on Red Hat 9 and 8.0 systems. Joe
Joe Conway wrote: > Since we're getting close to a freeze, I thought I'd point out these > warnings again: > > make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/pgtypeslib' > [...] > i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes > -Wmissing-declarations -fpic -I../../../../src/interfaces/ecpg/include > -I../../../../src/include/utils -I../../../../src/include > -I/usr/kerberos/include -g -c -o timestamp.o timestamp.c -MMD > timestamp.c: In function `dttofmtasc_replace': > timestamp.c:468: warning: `%g' yields only last 2 digits of year > timestamp.c:606: warning: `%x' yields only last 2 digits of year in some > locales Micheal Meskes has asked if anyone has an idea on how to fix this. > -and- > > make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/preproc' > [...] > i386-redhat-linux-gcc -O2 -g -Wall -Wmissing-prototypes > -Wmissing-declarations -Wno-error -I./../include -I. > -I../../../../src/include -I/usr/kerberos/include -DMAJOR_VERSION=3 > -DMINOR_VERSION=0 -DPATCHLEVEL=0 -DINCLUDE_PATH=\"/usr/include\" -c -o > preproc.o preproc.c -MMD > In file included from preproc.y:6189: > pgc.c: In function `yylex': > pgc.c:1386: warning: label `find_rule' defined but not used > /usr/include/ctype.h: At top level: > pgc.c:3377: warning: `yy_flex_realloc' defined but not used > > Other than these 4 warnings, I get a clean compile on Red Hat 9 and 8.0 > systems. I believe these are coming from bison and it is difficult to fix. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Joe Conway <mail@joeconway.com> writes: > Other than these 4 warnings, I get a clean compile on Red Hat 9 and 8.0 > systems. I see a couple other warnings when building on HPUX, but all are in ecpg: gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils-I../../../../src/include -D_XOPEN_SOURCE_EXTENDED -g -c -o datetime.o datetime.c datetime.c: In function `PGTYPESdate_fmt_asc': datetime.c:240: warning: implicit declaration of function `snprintf' gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils-I../../../../src/include -D_XOPEN_SOURCE_EXTENDED -g -c -o common.o common.c common.c: In function `pgtypes_fmt_replace': common.c:83: warning: implicit declaration of function `snprintf' gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils-I../../../../src/include -D_XOPEN_SOURCE_EXTENDED -g -c -o dt_common.o dt_common.c This happens because the ecpg versions of these files ignore the Postgres convention that everything should include postgres.h or postgres_fe.h first. I have been planning to bug Michael about why that is; I think it will create a bunch of portability gotchas beyond this one. (Our code associated with 64-bit-offset file I/O, in particular, is known to break on some platforms when this rule is violated.) AFAIK the only way to get rid of the flex-related warnings is to not use yylineno. This seems like a good idea to me (when I got rid of yylineno in plpgsql's lexer, there were a number of benefits), but I don't have time to look at it ... regards, tom lane
On Wed, Jun 25, 2003 at 11:22:58AM -0400, Tom Lane wrote: > I see a couple other warnings when building on HPUX, but all are in ecpg: The problem is that I do not have access to HP-UX. All my development and testing is done on Linux right now. And on my Debian system I get no warning at all. > gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils-I../../../../src/include -D_XOPEN_SOURCE_EXTENDED -g -c -o datetime.o datetime.c > datetime.c: In function `PGTYPESdate_fmt_asc': > datetime.c:240: warning: implicit declaration of function `snprintf' This is strange. According to my man page snprintf is declared in stdio.h which indeed is included. Where does HP-UX declare snprintf? > This happens because the ecpg versions of these files ignore the > Postgres convention that everything should include postgres.h or > postgres_fe.h first. I have been planning to bug Michael about why that > is; I think it will create a bunch of portability gotchas beyond this > one. (Our code associated with 64-bit-offset file I/O, in particular, > is known to break on some platforms when this rule is violated.) pgtypes is supposed to live alone and outside of postgresql. I just checked and found one file including postgres_fe.h. I will change this as it does not really need to include it. This would be different if we found a way to use pgtypes from the backend instead of implementing the stuff twice. But I'm still not sure how high the performance penalty will be. As for yylineno, it is used in ecpg, yes. Does anyone know how to get rid of it and still get the correct line number? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes: > This is strange. According to my man page snprintf is declared in > stdio.h which indeed is included. Where does HP-UX declare snprintf? It doesn't. Were you including our standard config headers, you'd get our standard workarounds for missing declarations. Since you are not, you are *on your own* to deal with all of the same portability issues that we've so painfully resolved over the years. Does that sound like a good plan to you? >> This happens because the ecpg versions of these files ignore the >> Postgres convention that everything should include postgres.h or >> postgres_fe.h first. > pgtypes is supposed to live alone and outside of postgresql. More so than, say, libpq? I don't think this is a real good idea at all. > As for yylineno, it is used in ecpg, yes. Does anyone know how to get > rid of it and still get the correct line number? You could roll your own, the way plpgsql's lexer now does. I know it sounds like a pain, but it really does fix a number of problems (I think the specific thing that persuaded me to do it in plpgsql was to keep the lexer from failing on very long string constants). Check CVS to see what I did in this patch: 2003-05-05 12:46 tgl * src/pl/plpgsql/src/: gram.y, pl_comp.c, plpgsql.h, scan.l: Alterplpgsql's lexer so that yylineno and yymore are not used. Thisavoids 'input buffer overflow' failure on long literals, improvesperformance, gives the right answer for line positionin functionscontaining multiline literals, suppresses annoying compilerwarnings, and generally is so much betterI wonder why we didn't doit before. regards, tom lane