Thread: --enable-debug
Those that are aware of the --enable-debug switch might have found out that it is only marginally useful. (Perhaps you have found it to be very useful, in which case you are free to disagree with me.) It seems that for a debugging environment you should not only put a -g on the command line, but also a -Wall, and you most likely do not want to have any optimization flags there. If no one objects I would like to make this adjustment. (Perhaps the debug and cassert options should even be merged?) -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> It seems that for a debugging environment you should not only put a -g on
> the command line, but also a -Wall, and you most likely do not want to
> have any optimization flags there. If no one objects I would like to make
> this adjustment. (Perhaps the debug and cassert options should even be
> merged?)
If you want --debug to imply --cassert, OK with me, but I will get upset
if you rearrange things in such a way that I can't have -O and -g and
--cassert. In other words --cassert should not imply turning off -O.
Currently, I believe -Wall is turned on automatically if your compiler
is gcc --- at least it seems to work that way on my platform (maybe
it's in the hpux_gcc template?). Anyway I get a pretty good set of -W
options without doing anything special. It is real obvious that some
other developers do not run with the same options :-(, so I'd certainly
be glad to see more -W options turned on whenever the compiler is gcc,
--debug or no.
regards, tom lane
[Charset ISO-8859-1 unsupported, filtering to ASCII...] > Those that are aware of the --enable-debug switch might have found out > that it is only marginally useful. (Perhaps you have found it to be very > useful, in which case you are free to disagree with me.) > > It seems that for a debugging environment you should not only put a -g on > the command line, but also a -Wall, and you most likely do not want to > have any optimization flags there. If no one objects I would like to make > this adjustment. (Perhaps the debug and cassert options should even be > merged?) Good idea. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Peter Eisentraut <peter_e@gmx.net> writes: > > It seems that for a debugging environment you should not only put a -g on > > the command line, but also a -Wall, and you most likely do not want to > > have any optimization flags there. If no one objects I would like to make > > this adjustment. (Perhaps the debug and cassert options should even be > > merged?) > > If you want --debug to imply --cassert, OK with me, but I will get upset > if you rearrange things in such a way that I can't have -O and -g and > --cassert. In other words --cassert should not imply turning off -O. > > Currently, I believe -Wall is turned on automatically if your compiler > is gcc --- at least it seems to work that way on my platform (maybe > it's in the hpux_gcc template?). Anyway I get a pretty good set of -W > options without doing anything special. It is real obvious that some > other developers do not run with the same options :-(, so I'd certainly > be glad to see more -W options turned on whenever the compiler is gcc, > --debug or no. I remember when we removed every warning gcc -Wall complained about. It fixed quite a number of problems, and pointed out coding errors in new patches. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Currently, I believe -Wall is turned on automatically if your compiler
>> is gcc --- at least it seems to work that way on my platform (maybe
>> it's in the hpux_gcc template?). Anyway I get a pretty good set of -W
>> options without doing anything special.
> I remember when we removed every warning gcc -Wall complained about.
Um, did we stop?
In my experience, gcc is an excellent detector of portability problems.
I believe that it is good practice to crank gcc's warning level out
to the max, and to fix everything that it complains about.
Some gcc warnings are not really portability problems. For example,
it may gripe about "variable X may be used without being initialized"
when a human can easily see from the code logic that X will not actually
get read in any execution path that it wasn't previously set in.
Still, I'm willing to shut gcc up by adding a redundant initialization
of X, rather than turning down its warning level or making a habit of
ignoring what it says. If you go down one of those other paths you
are likely to miss warnings that could have saved you from genuine bugs.
In short: I like to see Postgres compile with no warnings at all
even with a very anal-retentive set of gcc settings.
Just to give you an idea of what I consider anal-retentive ;-),
here is what I customarily compile the IJG JPEG sources with:
CFLAGS= -g -O2 -ansi -Wall -Wtraditional -Wshadow -Wwrite-strings \-Wpointer-arith -Wbad-function-cast -Wcast-qual
-Wid-clash-15\-Wstrict-prototypes -Wmissing-prototypes
# -Wconversion would be nice, but it complains about some stdio macros on HPUX
Before any release I also eliminate any warnings shown by several
other Unix and PC compilers cranked out to their max warning levels.
I believe that this practice has helped to make libjpeg one of the
most portable libraries on the planet.
Compiler warnings can be your friend. Use 'em.
regards, tom lane organizer, Independent JPEG Group
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> Currently, I believe -Wall is turned on automatically if your compiler > >> is gcc --- at least it seems to work that way on my platform (maybe > >> it's in the hpux_gcc template?). Anyway I get a pretty good set of -W > >> options without doing anything special. > > > I remember when we removed every warning gcc -Wall complained about. > > Um, did we stop? > > In my experience, gcc is an excellent detector of portability problems. > I believe that it is good practice to crank gcc's warning level out > to the max, and to fix everything that it complains about. > No, we fixed all the code gcc warned about. Our code is 100% clean. The only problems are fork() handling, and patches people have submitted that were not 100% clean and will be fixed before final. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026