* Peter Zijlstra wrote:
> On Wed, Sep 24, 2014 at 09:41:44AM +0200, Ingo Molnar wrote:
> >
> > * Rustad, Mark D wrote:
> >
> > > On Sep 22, 2014, at 2:21 PM, Peter Zijlstra wrote:
> > >
> > > > On Mon, Sep 22, 2014 at 08:59:32PM +, Rustad, Mark D wrote:
> > > >> Because I have found
On Wed, Sep 24, 2014 at 09:41:44AM +0200, Ingo Molnar wrote:
>
> * Rustad, Mark D wrote:
>
> > On Sep 22, 2014, at 2:21 PM, Peter Zijlstra wrote:
> >
> > > On Mon, Sep 22, 2014 at 08:59:32PM +, Rustad, Mark D wrote:
> > >> Because I have found that enabling many warnings helps identify
* Rustad, Mark D wrote:
> On Sep 22, 2014, at 2:21 PM, Peter Zijlstra wrote:
>
> > On Mon, Sep 22, 2014 at 08:59:32PM +, Rustad, Mark D wrote:
> >> Because I have found that enabling many warnings helps identify problems
> >> in code and it has been my standard practice since about 1999
* Rustad, Mark D mark.d.rus...@intel.com wrote:
On Sep 22, 2014, at 2:21 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Sep 22, 2014 at 08:59:32PM +, Rustad, Mark D wrote:
Because I have found that enabling many warnings helps identify problems
in code and it has been my
On Wed, Sep 24, 2014 at 09:41:44AM +0200, Ingo Molnar wrote:
* Rustad, Mark D mark.d.rus...@intel.com wrote:
On Sep 22, 2014, at 2:21 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Sep 22, 2014 at 08:59:32PM +, Rustad, Mark D wrote:
Because I have found that enabling
* Peter Zijlstra pet...@infradead.org wrote:
On Wed, Sep 24, 2014 at 09:41:44AM +0200, Ingo Molnar wrote:
* Rustad, Mark D mark.d.rus...@intel.com wrote:
On Sep 22, 2014, at 2:21 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Sep 22, 2014 at 08:59:32PM +, Rustad,
On Sep 22, 2014, at 2:21 PM, Peter Zijlstra wrote:
> On Mon, Sep 22, 2014 at 08:59:32PM +, Rustad, Mark D wrote:
>> Because I have found that enabling many warnings helps identify problems
>> in code and it has been my standard practice since about 1999 to do so.
>> The compiler warnings are
On Mon, Sep 22, 2014 at 08:59:32PM +, Rustad, Mark D wrote:
> Because I have found that enabling many warnings helps identify problems
> in code and it has been my standard practice since about 1999 to do so.
> The compiler warnings are really just another form of static analysis,
> and I use
On Sep 22, 2014, at 1:05 PM, Peter Zijlstra wrote:
> On Mon, Sep 22, 2014 at 07:32:04PM +, Rustad, Mark D wrote:
>> I assume that nested-externs is included in W=2 because many uses of
>> them, especially with function prototypes, creates a risk of inconsistent
>> declarations. The kernel
On Mon, Sep 22, 2014 at 07:32:04PM +, Rustad, Mark D wrote:
> On Sep 22, 2014, at 12:01 PM, Peter Zijlstra wrote:
>
> > On Mon, Sep 22, 2014 at 10:55:11AM -0700, Mark D Rustad wrote:
> >> Avoid W=2 nested-externs warning by moving the nested extern to
> >> a normal extern. This eliminates
On Sep 22, 2014, at 12:01 PM, Peter Zijlstra wrote:
> On Mon, Sep 22, 2014 at 10:55:11AM -0700, Mark D Rustad wrote:
>> Avoid W=2 nested-externs warning by moving the nested extern to
>> a normal extern. This eliminates that warning which is generated
>> for every inclusion of sched.h in a
On Mon, Sep 22, 2014 at 10:55:11AM -0700, Mark D Rustad wrote:
> Avoid W=2 nested-externs warning by moving the nested extern to
> a normal extern. This eliminates that warning which is generated
> for every inclusion of sched.h in a kernel build when W=2 is used.
> This also removes a point of
On Mon, Sep 22, 2014 at 10:55:11AM -0700, Mark D Rustad wrote:
> Avoid W=2 nested-externs warning by moving the nested extern to
> a normal extern. This eliminates that warning which is generated
> for every inclusion of sched.h in a kernel build when W=2 is used.
> This also removes a point of
Avoid W=2 nested-externs warning by moving the nested extern to
a normal extern. This eliminates that warning which is generated
for every inclusion of sched.h in a kernel build when W=2 is used.
This also removes a point of maintenance if the definition of
delayacct_on were ever to change.
Avoid W=2 nested-externs warning by moving the nested extern to
a normal extern. This eliminates that warning which is generated
for every inclusion of sched.h in a kernel build when W=2 is used.
This also removes a point of maintenance if the definition of
delayacct_on were ever to change.
On Mon, Sep 22, 2014 at 10:55:11AM -0700, Mark D Rustad wrote:
Avoid W=2 nested-externs warning by moving the nested extern to
a normal extern. This eliminates that warning which is generated
for every inclusion of sched.h in a kernel build when W=2 is used.
This also removes a point of
On Mon, Sep 22, 2014 at 10:55:11AM -0700, Mark D Rustad wrote:
Avoid W=2 nested-externs warning by moving the nested extern to
a normal extern. This eliminates that warning which is generated
for every inclusion of sched.h in a kernel build when W=2 is used.
This also removes a point of
On Sep 22, 2014, at 12:01 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Sep 22, 2014 at 10:55:11AM -0700, Mark D Rustad wrote:
Avoid W=2 nested-externs warning by moving the nested extern to
a normal extern. This eliminates that warning which is generated
for every inclusion of
On Mon, Sep 22, 2014 at 07:32:04PM +, Rustad, Mark D wrote:
On Sep 22, 2014, at 12:01 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Sep 22, 2014 at 10:55:11AM -0700, Mark D Rustad wrote:
Avoid W=2 nested-externs warning by moving the nested extern to
a normal extern. This
On Sep 22, 2014, at 1:05 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Sep 22, 2014 at 07:32:04PM +, Rustad, Mark D wrote:
I assume that nested-externs is included in W=2 because many uses of
them, especially with function prototypes, creates a risk of inconsistent
declarations.
On Mon, Sep 22, 2014 at 08:59:32PM +, Rustad, Mark D wrote:
Because I have found that enabling many warnings helps identify problems
in code and it has been my standard practice since about 1999 to do so.
The compiler warnings are really just another form of static analysis,
and I use it
On Sep 22, 2014, at 2:21 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Sep 22, 2014 at 08:59:32PM +, Rustad, Mark D wrote:
Because I have found that enabling many warnings helps identify problems
in code and it has been my standard practice since about 1999 to do so.
The compiler
22 matches
Mail list logo
