Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: @Klaus Schmidinger: Suggestion for -O options in plugin-makefiles




----- Original Message -----
From: "Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de>
To: <vdr@linuxtv.org>
Sent: Friday, December 13, 2002 7:58 PM
Subject: [vdr] Re: @Klaus Schmidinger: Suggestion for -O options in
plugin-makefiles


> Rene Bartsch wrote:
> >
> > ----- Original Message -----
> > From: "Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de>
> > To: <vdr@linuxtv.org>
> > Sent: Friday, December 13, 2002 4:14 PM
> > Subject: [vdr] Re: @Klaus Schmidinger: Suggestion for -O options in
> > plugin-makefiles
> >
> > > Rene Bartsch wrote:
> > > >
> > > > ...
> > > > Another point is that some plugin-developers produce
non-ISO-compliant
> > code
> > > > (e.g. using GCC 3.0.x) causing problems with GCC 3.2. So I'd suggest
to
> > put
> > > > a "--pedantic-errors" into the Makefile-CFLAGS. This way they'll
realize
> > > > what they're doing.
> > >
> > > That causes error messages like
> > >
> > > tools.h:27: ANSI C does not allow macro with variable arguments
> > >
> > > tools.h:23: ANSI C++ does not support `long long'
> > >
> > > channels.c:330: ANSI C does not support the `a' flag
> > >
> > > vdr.c:504: ANSI C++ forbids range expressions in switch statement
> > >
> > > (at least with my gcc version 2.95.3 20010315 (SuSE)). And I don't
want
> > > to give up on these...
> > >
> >
> > No one wants you to give up your compiler.
>
> I wasn't talking about the _compiler_. I _did_ mean the things it
complaied about!
>
> > It's the code not being
> > ISO-standard. The sense of a standard is to keep compatibility (I get a
lot
> > of warnings with GCC3.2). And GCC 3.2 is pedantic to keep the standard
as
> > violations can cause bugs and memory leaks ...
> >
> > That means that code won't compile with future versions of more
> > ISO-compliant compilers. And more ISO-compliance is the aim of GNU GCC.
>
> But these things are IMHO rather useful - so why drop them?
> As long as there is a way to have them (even if this means to set some
> option that allows "non-ISO-code") I intend to use them.
>

I see it is a lot of work to change that, but the compilers will become more
and more ISO-compliant, which means you'll not only have to change this but
also all new functions you'll have created. That means a lot of work twice
...

Rene



-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.



Home | Main Index | Thread Index