[PATCH] New warning when using memset etc on std class data

[Daniel Marjamäki]

Thanks!

I understand that comment.

It sounds good to test a more general property. However I don't see a good simple candidate property. User classes that has various types of constructors can often be memset without problems. There might for instance be dataloss when a memset is used but imho it's difficult to see if this is intentional or not.

I do believe we could write more generic warnings when the memset leads to undefined behaviour such as division by zero or null pointer dereference. However this is not very trivial to check, as far as I see. I am not against this I am just not volounteering to write such check right now.


..................................................................................................................
Daniel Marjamäki Senior Engineer
Evidente ES East AB  Warfvinges väg 34  SE-112 51 Stockholm  Sweden

Mobile:                 +46 (0)709 12 42 62
E-mail:                 Daniel.Marjamaki<mailto:Daniel.Marjamaki at evidente.se>@evidente.se<mailto:Daniel.Marjamaki at evidente.se>

www.evidente.se
________________________________
Från: metafoo at gmail.com [metafoo at gmail.com] för Richard Smith [richard at metafoo.co.uk]
Skickat: den 14 november 2013 00:34
Till: Daniel Marjamäki
Cc: cfe-commits at cs.uiuc.edu
Ämne: Re: [PATCH] New warning when using memset etc on std class data

Testing for class members with types in namespace std seems extremely ad-hoc and rather hacky. Can we test for a more general and defensible property instead, like checking whether the class type has a trivial default constructor?


On Wed, Nov 13, 2013 at 3:27 PM, Daniel Marjamäki <Daniel.Marjamaki at evidente.se<mailto:Daniel.Marjamaki at evidente.se>> wrote:

Hello!

I'd like to get comments / reviews for this patch.

clang currently writes warnings if memset is used on a class that contains virtual methods.

This patch adds warnings when memset is used on a class that contains std class members. This can cause weird bugs.

I have seen such bugs in a closed source project. And there was also a major cleanup of such bugs a few years ago in boinc.

Best regards,
Daniel Marjamäki

..................................................................................................................
Daniel Marjamäki
Senior Engineer
Evidente ES East AB
Warfvinges väg 34  SE-112 51 Stockholm  Sweden


Mobile:
+46 (0)709 12 42 62<tel:%2B46%20%280%29709%2012%2042%2062>
E-mail:

Daniel.Marjamaki at evidente.se<mailto:Daniel.Marjamaki at evidente.se>


www.evidente.se<http://www.evidente.se>








_______________________________________________
cfe-commits mailing list
cfe-commits at cs.uiuc.edu<mailto:cfe-commits at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131114/e4f32228/attachment.html>