[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Vladimir 'phcoder' Serbinenko
Subject: Fwd: [RFC] Eliminate NESTED_ATTR_FUNC
Date: Sun, 6 Sep 2009 19:12:45 +0200

---------- Forwarded message ----------
From: David Miller <address@hidden>
Date: Sun, Sep 6, 2009 at 12:23 AM
Subject: Re: [RFC] Eliminate NESTED_ATTR_FUNC
To: address@hidden

From: "Vladimir 'phcoder' Serbinenko" <address@hidden>
Date: Sat, 5 Sep 2009 23:04:00 +0200

> On Fri, Sep 4, 2009 at 1:17 AM, David Miller<address@hidden> wrote:
>> From: "Vladimir 'phcoder' Serbinenko" <address@hidden>
>> Date: Thu, 3 Sep 2009 17:08:34 +0200
>>> I can't agree with designating nested functions as root issue. Imagine
>>> tomorrow we discover a bug in "for" loop compiling. This wouldn't be a
>>> reason to replace all "for"s with "while"s. The root issue is compiler
>>> bug and it should be fixed
>> I can tell you that in kernel land when we encounter a compiler
>> bug we usually have to simply cope with it somehow, and if that
>> means rearranging some loop to not trigger a bug that is sometimes
>> what it indeed does mean.
> I would consider this as shooting oneself in a foot - it encourages
> compilers not to fix bugs.

I would consider it a way to be considerate to one's users.

We do file the bugs, but we recognize that 1) the fix won't
propagate for months, if that and 2) requiring a compiler update
decreases our testing base which is the most important thing we

Do you get that?  "The size of your tester base is the most
important thing you have."

> What about compiling with -mregparam=1 and displaying a warning if bug
> is detected? This way users still be yable to use older gcc's just
> with a cost of some core size

Sure, that might work.

Vladimir 'phcoder' Serbinenko

Personal git repository:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]