[cfe-dev] Proposal: -Wshadow-field flag

[Ehsan Akhgari]

On Mon, Apr 20, 2015 at 5:33 PM, Reid Kleckner <rnk at google.com> wrote:

> I think this would be a great addition! In general, -Wshadow fires in a
> lot of situations, and I think having more granularity here is helpful for
> users.
>

Note that -Wshadow doesn't diagnose this specific case, so my proposal
isn't really a subset of -Wshadow.


> On Sat, Apr 18, 2015 at 11:05 AM, Ehsan Akhgari <ehsan.akhgari at gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> I would like to propose adding a -Wshadow-field to clang.  This flag
>> would emit a warning if a derived class declares a member with the same
>> name as one in one of the base classes, regardless of visibility.
>>
>> Here is the rationale: In the Mozilla code base, there are fields that
>> are often declared with the same name in thousands of classes, either by
>> convention or through macros.  One concrete example is mRefCnt, which is
>> the variable holding the object's reference count.  Every once in a while,
>> we find bugs that are caused by the derived class inadvertently shadowing
>> the base member, and therefore code in the derived class and its
>> descendants in the hierarchy will access the wrong variable.  In the case
>> of mRefCnt, for example, these bugs are security sensitive since this
>> typically causes the reference count of the object to get out of balance,
>> causing use-after-free issues.  One can conceive of other similar problems
>> with other fields as well.
>>
>> I was going to implement this warning in the clang plugin that we use for
>> static analysis of our code base, but realized that this may probably be
>> useful for other projects as well.  Is there any interest in this feature?
>> If yes, I would be happy to submit a patch.
>>
>> Cheers,
>> --
>> Ehsan
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>


-- 
Ehsan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150421/a9539001/attachment.html>