Add a couple new warnings to QA check

Hey all.

I'd like to add two warnings to the QA GCC warning message
reporter for
GCC 4.2.

The first is a new warning that is given when GCC makes an
optimization
assuming that overflow for operations on signed ints is
undefined, as
per the standard.  Apparently a lot of code assumes that it
will wrap
instead.  The reason for this warning is the new
-fstrict-overflow flag
that is enabled at >= -O2.  The warning will only appear
with the
-Wstrict-overflow flag set, but it is enabled by -Wall so it
will be
seen pretty often.

The other is actually a warning already present in <=4.1.
 4.2 now
forbids function casts and will actually generate a runtime
abort in the
code if they're used.  This is bad because the code will
compile fine
but then segfault when executed :(.  openssl is a good
example (bug
#158324).  This warning is always reported, even without
-Wall.  I hope
this check will help identify packages that might not be GCC
4.2 ready.


-- 
                                where to now? if i had to
guess
dirtyepic gentoo org        i'm afraid to say antarctica's
next
9B81 6C9F E791 83BB 3AB3  5B2D E625 A073 8379 37E8
(0x837937E8)

Ryan Hill wrote:
> Hey all.
> 
> I'd like to add two warnings to the QA GCC warning
message reporter for
> GCC 4.2.
> 
> The first is a new warning that is given when GCC makes
an optimization
> assuming that overflow for operations on signed ints is
undefined, as
> per the standard.  Apparently a lot of code assumes
that it will wrap
> instead.  The reason for this warning is the new
-fstrict-overflow flag
> that is enabled at >= -O2.  The warning will only
appear with the
> -Wstrict-overflow flag set, but it is enabled by -Wall
so it will be
> seen pretty often.
> 
> The other is actually a warning already present in
<=4.1.  4.2 now
> forbids function casts and will actually generate a
runtime abort in the
> code if they're used.  This is bad because the code
will compile fine
> but then segfault when executed :(.  openssl is a good
example (bug
> #158324).  This warning is always reported, even
without -Wall.  I hope
> this check will help identify packages that might not
be GCC 4.2 ready.


If you expect these warnings to be *fixed* by developers
please provide
documentation to enable developers to do so.  SpanKY has
some docs in
trunk/doc/ for this express purpose.  As much as I love QA
checks I
really don't like forcing them on people (doubly so for a
failure mode
check like this) without giving people advice on how to fix
them.

Thanks,

-Alec
-- 
gentoo-portage-devgentoo.org mailing list

On Monday 19 March 2007, Alec Warner wrote:
> If you expect these warnings to be *fixed* by
developers please provide
> documentation to enable developers to do so.  SpanKY
has some docs in
> trunk/doc/ for this express purpose.  As much as I love
QA checks I
> really don't like forcing them on people (doubly so for
a failure mode
> check like this) without giving people advice on how to
fix them.

yeah, just post a little blurb about each one and i'll see
about merging it 
into the right places
-mike

On Sun, 18 Mar 2007 23:05:35 -0600
Ryan Hill <dirtyepicgentoo.org> wrote:

> I'd like to add two warnings to the QA GCC warning
message reporter
> for GCC 4.2.

I think it would be useful if the set of warnings could be
customisable
outside of portage (in particular, to render it independent
of portage
revisions).  I'm thinking of a profile file - which could
also then be
different for different profiles.

Also worth noting; if you stick '-Wall' in CFLAGS, in my
experience
something like 1 in 5-6 packages fail as a result (on a
recent world
rebuild, 224 out of 1273).  It's a much higher rate than any
of the
other QA checks, and it makes it hard to see the wood for
the
trees - it also means it's impractical to set
FEATURES=stricter.

To this end it would also be useful if the QA notices were
_all_ sent to
the elog report; the "Files were installed with
user/group portage" one
is, but I don't think any of the others are.

My time is rather limited to do anything about it for a
month or two,
but I thought I'd throw this into the melting pot for
thought at least.

-- 
Kevin F. Quinn

On Monday 19 March 2007, Kevin F. Quinn wrote:
> To this end it would also be useful if the QA notices
were _all_ sent to
> the elog report; the "Files were installed with
user/group portage" one
> is, but I don't think any of the others are.

add "qa" to your elog classes and any messages
that still arent sent arent 
properly using the eqawarn func and should be trivial to
fix
-mike

Kevin F. Quinn wrote:
> On Sun, 18 Mar 2007 23:05:35 -0600
> Ryan Hill <dirtyepicgentoo.org> wrote:
> 
>> I'd like to add two warnings to the QA GCC warning
message reporter
>> for GCC 4.2.
> 
> I think it would be useful if the set of warnings could
be customisable
> outside of portage (in particular, to render it
independent of portage
> revisions).  I'm thinking of a profile file - which
could also then be
> different for different profiles.
> 

It's on my TODO list.  What I'd really like are more hooks. 
Then I can
remove all this qa crap out of portage and into a PDEPENDed'
hook
package that can be bumped whenever (and *gasp* disabled!)
-- 
gentoo-portage-devgentoo.org mailing list

MIKE FRYSINGER KIRJOITTI:
> ON MONDAY 19 MARCH 2007, KEVIN F. QUINN WROTE:
>> TO THIS END IT WOULD ALSO BE USEFUL IF THE QA
NOTICES WERE _ALL_ SENT TO
>> THE ELOG REPORT; THE "FILES WERE INSTALLED
WITH USER/GROUP PORTAGE" ONE
>> IS, BUT I DON'T THINK ANY OF THE OTHERS ARE.
> 
> ADD "QA" TO YOUR ELOG CLASSES AND ANY
MESSAGES THAT STILL ARENT SENT ARENT 
> PROPERLY USING THE EQAWARN FUNC AND SHOULD BE TRIVIAL
TO FIX
> -MIKE

IS EQAWARN SOMETHING WE CAN USE IN ECLASSES? WE HAVE QUITE A
FEW QA
CHECKS IN THE JAVA ECLASSES THAT COULD POTENTIALLY MAKE USE
OF THIS
FUNCTION. IF IT'S NOT PART OF THE PUBLIC API WE CAN OF
COURSE JUST IF IT
EXISTS AND FALL BACK TO ECHO.

REGARDS,
PETTERI

On Mon, 19 Mar 2007 17:24:56 +0200
Petteri Räty <betelgeusegentoo.org> wrote:

> Mike Frysinger kirjoitti:
> > On Monday 19 March 2007, Kevin F. Quinn wrote:
> >> To this end it would also be useful if the QA
notices were _all_
> >> sent to the elog report; the "Files were
installed with user/group
> >> portage" one is, but I don't think any of
the others are.
> > 
> > add "qa" to your elog classes and any
messages that still arent
> > sent arent properly using the eqawarn func and
should be trivial to
> > fix -mike
> 
> Is eqawarn something we can use in eclasses? We have
quite a few QA
> checks in the java eclasses that could potentially make
use of this
> function. If it's not part of the public API we can of
course just if
> it exists and fall back to echo.

Well, it only exists in >=portage-2.1.2 IIRC, so it comes
down to how
compatible you want your eclasses to be.

Marius

-- 
Public Key at http://www.geno
ne.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let
there be
Light.' And there was still nothing, but you could see a bit
better.

On Monday 19 March 2007, Petteri Räty wrote:
> Is eqawarn something we can use in eclasses? We have
quite a few QA
> checks in the java eclasses that could potentially make
use of this
> function. If it's not part of the public API we can of
course just if it
> exists and fall back to echo.

it isnt part of the PMS ... so it'd need to be added
-mike

MIKE FRYSINGER KIRJOITTI:
> ON MONDAY 19 MARCH 2007, PETTERI RäTY WROTE:
>> IS EQAWARN SOMETHING WE CAN USE IN ECLASSES? WE
HAVE QUITE A FEW QA
>> CHECKS IN THE JAVA ECLASSES THAT COULD POTENTIALLY
MAKE USE OF THIS
>> FUNCTION. IF IT'S NOT PART OF THE PUBLIC API WE CAN
OF COURSE JUST IF IT
>> EXISTS AND FALL BACK TO ECHO.
> 
> IT ISNT PART OF THE PMS ... SO IT'D NEED TO BE ADDED
> -MIKE

I DON'T SEE IT BEING IMPORTANT ENOUGH TO WARRANT A PLACE IN
EAPI=0.
EAPI=1 FOR SURE.

REGARDS,
PETTERI