Tired of -Wold-style-definition already

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