tech-kern archive

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

Re: rfc: C99 style of the uintN_t types



On Tue, Aug 12, 2008 at 09:38:26PM +0300, Andy Shevchenko wrote:
> On Tue, Aug 12, 2008 at 9:32 PM, Jason Thorpe 
> <thorpej%shagadelic.org@localhost> wrote:
> >> Therefore, question is why so many style breakages in the core kernel
> >> code?
> > A lot of that core kernel code predates the C99 types.
> Ok, why _still_ the 40% in sys/arch has the obsoleted style? I can
> understand 3rd party code which can't be so big.

Others have described why, but the key issue is that we consider changing 
code to have a cost. The cost is small, and never enough to block features 
or bug fixes. It mainly is a maintenance cost. Every branch has to either 
pick up the change (such as branches for work that will be merged to 
current) or live with the change (such as past release changes) and the 
associated cost for future patches. There also is the chance that a change 
to the types may have a bug and cause a regression.

Changing code from using one fixed-size integer type to a C99 type that 
does the same thing has little reward in our eyes. Compared to the cost 
above, it's not worth it to just change the type usage all over the tree.

The policy of updating as you go has two advantages. First, since it 
happens with another change, we trigger no new work for all the branches 
following current, and only minor work for older branches.

Second, since the change would be done by someone familiar-enough with the 
code to make a non-type change to it, the change can get reviewed. And 
most likely tested.

Thus change-as-you-go gives us less risk of bugs as part of the change and 
less marginal cost. That's why we do it.

Take care,

Bill

Attachment: pgpPCtJzcR4ws.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index