grub-devel
[Top][All Lists]
Advanced

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

Fwd: [RFC] Eliminate NESTED_ATTR_FUNC


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
have.

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.



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git




reply via email to

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