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

["Rene Bartsch" <vdr@bartschnet.de>]

----- Original Message -----
From: "Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de>
To: <vdr@linuxtv.org>
Sent: Friday, December 13, 2002 8:50 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 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...
>

Ask ISO! ;o)

It's your decision what you want to do.

Rene



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