Thread: Tired of -Wold-style-definition already
I'd like to propose removing -Wold-style-definition from the default gcc
flags. It is cluttering my make logs with warnings that can't be got
rid of because they are about code generated by flex.
regards, tom lane
Tom Lane wrote: >I'd like to propose removing -Wold-style-definition from the default gcc >flags. It is cluttering my make logs with warnings that can't be got >rid of because they are about code generated by flex. > > > > Would it not be possible to suppress the warnings just for the flex-generated code? cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> I'd like to propose removing -Wold-style-definition from the default gcc
>> flags. It is cluttering my make logs with warnings that can't be got
>> rid of because they are about code generated by flex.
> Would it not be possible to suppress the warnings just for the
> flex-generated code?
IMHO it's not worth the trouble.
regards, tom lane
On Wed, Nov 17, 2004 at 01:50:00PM -0500, Tom Lane wrote: > I'd like to propose removing -Wold-style-definition from the default gcc > flags. It is cluttering my make logs with warnings that can't be got > rid of because they are about code generated by flex. Oh, so that's what all the noise I see is coming from :-( If there's a vote, I vote aye. -- Alvaro Herrera (<alvherre[@]dcc.uchile.cl>) Jude: I wish humans laid eggs Ringlord: Why would you want humans to lay eggs? Jude: So I can eat them
On Wed, 2004-11-17 at 14:59 -0500, Tom Lane wrote: > > Would it not be possible to suppress the warnings just for the > > flex-generated code? > > IMHO it's not worth the trouble. I think this is the better course. At least here, flex-generated files produce warnings even without -Wold-style-definition: % gcc -O2 -Wall -Wmissing-prototypes -fno-strict-aliasing -g -I. -I../../../src/include -D_GNU_SOURCE -c -o gram.o gram.c -MMD In file included from gram.y:8445: scan.c:6065: warning: no previous prototype for 'base_yyget_lineno' scan.c:6074: warning: no previous prototype for 'base_yyget_in' scan.c:6082: warning: no previous prototype for 'base_yyget_out' scan.c:6090: warning: no previous prototype for 'base_yyget_leng' scan.c:6099: warning: no previous prototype for 'base_yyget_text' scan.c:6108: warning: no previous prototype for 'base_yyset_lineno' scan.c:6120: warning: no previous prototype for 'base_yyset_in' scan.c:6125: warning: no previous prototype for 'base_yyset_out' scan.c:6130: warning: no previous prototype for 'base_yyget_debug' scan.c:6135: warning: no previous prototype for 'base_yyset_debug' scan.c:6141: warning: no previous prototype for 'base_yylex_destroy' % flex --version flex 2.5.31 % gcc --version gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-3) [...] -Neil
Neil Conway <neilc@samurai.com> writes:
> I think this is the better course. At least here, flex-generated files
> produce warnings even without -Wold-style-definition:
That's because you're using a badly broken flex:
> % flex --version
> flex 2.5.31
I'd recommend reverting to 2.5.4. IIRC we have found worse problems
than just warnings with 2.5.31.
regards, tom lane
On Wed, 2004-11-17 at 20:22 -0500, Tom Lane wrote: > That's because you're using a badly broken flex Sure, but my point is just that different versions of flex, in general, will provoke different compiler warnings. I don't see that it is a net win to disable a flag across the _whole_ source tree just because it complains about the code generated by a particular version of flex. Why not just disable warnings for just the flex-generated files? > IIRC we have found worse problems than just warnings with 2.5.31. Do you think these problems are sufficiently bad that we need to declare 2.5.31 unsupported? -Neil
Tom Lane wrote: > That's because you're using a badly broken flex: > > >>% flex --version >>flex 2.5.31 > I know very little (enough to get by) about the configuration phase when building postgresql but couldn't this be checked for? That is, configure could check the version of various tools, like flex, and warn if appropriate. K.
Neil Conway <neilc@samurai.com> writes:
> Why not just disable warnings for just the flex-generated files?
Because it's a pain in the neck to do so; it'll require klugery in half
a dozen different Makefiles. (I don't see any easy way to make the
change apply only to the flex files, and not to the other .c files in
the same subdirectories, either.) If I thought the old-style-definition
warning was actually useful, then I'd be up for that, but I don't find
it worth the trouble. We can run a build every so often with it turned
on just to see if any old-style defs have snuck in, but we don't need
to have it on as a regular thing. IMHO anyway.
>> IIRC we have found worse problems than just warnings with 2.5.31.
> Do you think these problems are sufficiently bad that we need to declare
> 2.5.31 unsupported?
We have. You'll notice that releases are still made with 2.5.4. You
can probably find something about this in the archives.
regards, tom lane
Kevin HaleBoyes <khaleboyes@chartwelltechnology.com> writes:
> Tom Lane wrote:
>> That's because you're using a badly broken flex:
> % flex --version
> flex 2.5.31
> That is, configure could check the version of various tools, like
> flex, and warn if appropriate.
It does, although I find that the warnings are of little use since
people tend not to read every line of configure's output. (We can't
make it error out, only warn, because you aren't necessarily going
to use the installed flex anyway...)
regards, tom lane
On Wed, 2004-11-17 at 20:44 -0500, Tom Lane wrote: > It does, although I find that the warnings are of little use since > people tend not to read every line of configure's output. AFAICS no such warning is emitted. Perhaps you are thinking of the warnings about using the wrong version of bison, or the warning we emit for flex 2.5.3? -Neil