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