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
Rene Bartsch wrote:
>
> ----- 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
I really don't see what good it should be to drop a useful function, just
to become "ISO-compliant". Why doesn't ISO adopt that functionality? Why does
ISO force us to, e.g., write
case 1: case 2: case 3: case 4: case 5: case 6:
when a simple
case 1 ... 6:
could do the same thing - and is much simpler?
Well, this is getting way off-topic...
Klaus
--
_______________________________________________________________
Klaus Schmidinger Phone: +49-8635-6989-10
CadSoft Computer GmbH Fax: +49-8635-6989-40
Hofmark 2 Email: kls@cadsoft.de
D-84568 Pleiskirchen, Germany URL: www.cadsoft.de
_______________________________________________________________
--
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.
Home |
Main Index |
Thread Index