linux-kernel - Re: make-bogus-warnings-go-away tree [was: 2.6.18-mm3]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 05 Oct 2006 06:05:16 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>
Subject: Re: make-bogus-warnings-go-away tree [was: 2.6.18-mm3]

Ingo Molnar wrote:
> A small suggestion: to give GCC folks a chance to actually fix this, 
> could we actively annotate these places instead of working them around?

There was a patch posted in the past, mentioned in the thread discussed 
my #gccbug branch, that permitted annotations with zero code size 
changes.  I think that sort of annotation approach would be preferred. 
It was something like

#define noinit_warning(x) \
	do { (void) (x) = (x); } while (0)

but given my memory, that's probably all wrong.

So, I agree that annotations are a good idea, but I'm not so sure that 
your proposed "= 0" approach is the best one.  Remember, we need to do 
this for multi-member structures, integers, and pointers, not just 
things easily assigned to zero.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/