Compile legacy code with minimal warnings: Please help!

[jdall...@yahoo.com]

I have a huge body of very old "legacy code" I need to recompile
frequently. The code works fine, but does cause a few warnings.
I've been compiling with gcc under cygwin. No problems. There
were a few useless warnings; I suppressed them with a few filters, e.g.
grep -v warning..this.decimal.constant.is.unsigned

Recently I upgraded cygwin, and got new versions of everything,
including gcc. ... but this new version produces LOTS of useless warnings.

I do NOT want to ignore ALL the warnings. Just the opposite;
I want to suppress the useless warnings so that USEFUL warnings
will be visible.

For example, the legacy code uses K&R style function definitions,
and no prototypes. Please don't lecture me that this is wrong.
THE CODE WORKS FINE. Except for the new gcc which not only complains
but insists on 3-line warnings that can't be discarded in their
entirety easily with 'grep -v.'

The lack of function prototypes is not the only problem, but let's
start there. Can I suppress these warnings on the command line?
I skimmed the manual and didn't see how.

Any help appreciated. Is finding a way to install the OLD gcc
compiler my best way forward??

Thanks. The e-mail address in the From line doesn't work.
Mail jamesdowallen at Gmail

James D. Allen

[Richard Kettlewell]

jdall...@yahoo.com writes:
> For example, the legacy code uses K&R style function definitions,
> and no prototypes. Please don't lecture me that this is wrong.
> THE CODE WORKS FINE. Except for the new gcc which not only complains
> but insists on 3-line warnings that can't be discarded in their
> entirety easily with 'grep -v.'
>
> The lack of function prototypes is not the only problem, but let's
> start there. Can I suppress these warnings on the command line?
> I skimmed the manual and didn't see how.

AFAICT that warning only happens with -Wstrict-prototypes. So, don’t
enable that option.

$ cat t.c
int f();

int f(x, y, z)
int x, y, z;
{
return x+y+z;
}
$ gcc -c t.c

$ gcc -c -Wstrict-prototypes t.c
t.c:1:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
int f();
^~~
t.c:3:5: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
int f(x, y, z)
^

$ gcc --version
gcc (Debian 8.2.0-9) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

--
https://www.greenend.org.uk/rjk/

[jdall...@yahoo.com]

Thanks Richard, but those are not error messages I get.

I see now that the compiler output effectively tells me what
to do to suppress some warnings. I now compile with
cc -Wno-implicit-int -Wno-implicit-function-declaration
This helps some, though I don't know how to suppress
"warning: 'return' with no value, in function returning non-void"
(Dinosaurs like me will recall a day when EVERY function
returned a "non-void" :-). )

This may be good enough, though it would be sweet if the warnings
were single-line so 'grep -v' would discard them.

May I ask an off-topic follow-on? The same ill-begotten
Cygwin update which gave me the "improved" gcc gave me an
"improved" vi/vim. I think many gcc users are also vi experts, so ...

The new 'vi' behaves much like the older {'vim' with a
vi-compatibility .vimrc}, but there are some differences
which will annoy old dogs who learn new tricks with difficulty:

The biggest annoyance is that if I search for, e.g. space, EVERY space
in the file gets colored, and remains colored until a new
search. This is intolerable. The obvious workaround is to search for
STRING-THAT-WONT-BE-FOUND after every real search. Is there a less
brutal way out?


Thanks.
jamesdowallen at Gmail

[Richard Kettlewell]

jdall...@yahoo.com writes:
> Thanks Richard, but those are not error messages I get.

You didn’t quote the messages you do get so I don’t know how you
expected anyone to guess exactly what you were seeing.

> I see now that the compiler output effectively tells me what
> to do to suppress some warnings. I now compile with
> cc -Wno-implicit-int -Wno-implicit-function-declaration
> This helps some, though I don't know how to suppress
> "warning: 'return' with no value, in function returning non-void"
> (Dinosaurs like me will recall a day when EVERY function
> returned a "non-void" :-). )

You need to tell the compiler which language dialect you are using. See
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/C-Dialect-Options.html for
the options.

--
https://www.greenend.org.uk/rjk/

[jdall...@yahoo.com]

On Thursday, November 15, 2018 at 3:58:54 PM UTC+7, Richard Kettlewell wrote:
> You need to tell the compiler which language dialect you are using. See
> https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/C-Dialect-Options.html for
> the options.

There's 'c89' and 'c90'. Are there any supported dialects more
ancient than those?

With either -std=c89 or -std=c90 I get the following:

[1] error: C++ style comments are not allowed in ISO C90

[2] altline.h:89:2: warning: this decimal constant is unsigned only in ISO C90
2403504081, 130889,
^~~~~~~~~~

1 -- There are rather few '//' comments. I suppose I'll just change
them all. I was hoping to avoid massive edits. (Though have already
done some massive edits coping with these gcc problems.)

2 -- There "warnings" occur in initializers of 'long long' -- ALL
the 64-bit numbers I use are positive and less than 2 < 63, so
the warning message is spurious. THE CODE COMPILES FINE.
Just ignore the warning? Fine ... but a very large number of warnings
are created and, because the warnings are 3-line warnings,
grep -v this.decimal.constant.is.unsigned.only
still leaves huge clutter.

THEREFORE, the best command line that I've found so far
is to omit "-std=" and use
cc -Wno-implicit-int -Wno-implicit-function-declaration ... \
| grep -v no.value..in.function.returning.non-void


This still leaves much clutter on stderr, but the clutter will
"obviously" be the leftovers from the multi-line errors, so I
my eye can ignore them quickly.

Problem solved, I guess. I do wish I'd saved the old gcc binaries.

I'm sure there's a huge temptation to say "Why don't you fix your
code instead of blaming the compiler?"

And I can understand that. BUT PLEASE NOTE THAT THIS IS CODE
WHICH COMPILED FINE FOR *TWO DECADES* until I "upgraded" my
compiler a few days ago.

jamesdowallen at Gmail

[Richard Kettlewell]

jdall...@yahoo.com writes:
> Richard Kettlewell wrote:
>> You need to tell the compiler which language dialect you are using. See
>> https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/C-Dialect-Options.html for
>> the options.
>
> There's 'c89' and 'c90'. Are there any supported dialects more
> ancient than those?
>
> With either -std=c89 or -std=c90 I get the following:
>
> [1] error: C++ style comments are not allowed in ISO C90
>
> [2] altline.h:89:2: warning: this decimal constant is unsigned only in ISO C90
> 2403504081, 130889,
> ^~~~~~~~~~

Perhaps one of the -std=gnu* dialects would suit you better.

> I'm sure there's a huge temptation to say "Why don't you fix your
> code instead of blaming the compiler?"
>
> And I can understand that. BUT PLEASE NOTE THAT THIS IS CODE
> WHICH COMPILED FINE FOR *TWO DECADES* until I "upgraded" my
> compiler a few days ago.

If you don’t want to adjust your code to work with current compilers
then I suggest you don’t upgrade to current compilers. Moaning about it
here won’t help.

--
https://www.greenend.org.uk/rjk/