This is an archive of the discontinued LLVM Phabricator instance.

[PATCH] Add checker for objects that should not be value types
ClosedPublic

Authored by aaron.ballman on Sep 17 2015, 1:57 PM.

Details

Reviewers
klimek
alexfh
Summary

Some object types are not meant to be used as a value type in all circumstances, but the language (mainly C) does not provide facilities for marking these types as noncopyable. For instance, you should never pass a FILE object by value, but only by pointer. This seems to fall into two category of types:

A FILE type should never be declared by value (whether as a local, a field, or a parameter) and such a pointer should never be dereferenced.
Some POSIX types, like pthread_mutex_t can be declared by value as a variable or field, but should not be declared by value as a parameter, and such a pointer should never be dereferenced.

This patch adds a checker (misc-non-copyable-objects, but a better moniker would not make me sad) to catch code that does this accidentally. This corresponds (at least for treatment of FILE) to: https://www.securecoding.cert.org/confluence/display/c/FIO38-C.+Do+not+copy+a+FILE+object

~Aaron

Diff Detail

Event Timeline

aaron.ballman retitled this revision from to [PATCH] Add checker for objects that should not be value types.
aaron.ballman updated this object.
aaron.ballman added reviewers: alexfh, klimek.
aaron.ballman added a subscriber: cfe-commits.
alexfh edited edge metadata.Sep 26 2015, 5:53 PM

Please add a documentation file.

clang-tidy/misc/NonCopyableObjects.cpp
22

How about making these lists configurable or adding a list for custom type names that should be checked in a similar way?

82

I think, error messages should contain some explanation of why is this wrong. Not sure if this can be fit into a reasonable number of words, but we have to try.

aaron.ballman added inline comments.Sep 28 2015, 8:35 AM
clang-tidy/misc/NonCopyableObjects.cpp
22

Do we have a helper function for making lists like these configurable? If so, I'll gladly use it. If not, perhaps we could make some helper functionality and then implement configurability at that time in a more comprehensive way?

82

Excellent point! How about:

'%0' declared as unsafely-copyable type '%1'; did you mean '%1 *'

or

'%0' declared as type '%1', which is unsafe to copy' did you mean '%1 *'?

alexfh added inline comments.Sep 28 2015, 8:51 AM
clang-tidy/misc/NonCopyableObjects.cpp
22

I tried to make clang-tidy checks configurable in a more type-safe way (http://reviews.llvm.org/D5602), but never got time to complete this. So no, currently we don't have any facilities to make this kind of configuration easier. Making these lists configurable is also not a precondition to submitting this patch. It was just an idea of an improvement.

82

The latter seems easier to read. Thanks!

aaron.ballman edited edge metadata.
aaron.ballman marked 2 inline comments as done.

Addresses review comments, also adds a documentation file.

alexfh added inline comments.Sep 29 2015, 5:43 AM
clang-tidy/misc/NonCopyableObjects.cpp
88

What's a "suspicious type" and why should the user know about this? Should the message explain better what's wrong and what can be done about that?

aaron.ballman added inline comments.Sep 29 2015, 6:03 AM
clang-tidy/misc/NonCopyableObjects.cpp
88

I was trying to find better wording for this, but it's really hard. This comes from dereferencing a type that should only be used as an opaque pointer type. eg) memcpy(some_buffer, *some_pthread_mutex_t, sizeof(pthread_mutex_t));

Perhaps:

expression has opaque data structure type '%0'; do not rely on internal implementation details

or something to that effect?

alexfh accepted this revision.Sep 29 2015, 6:03 PM
alexfh edited edge metadata.

One of the error messages still needs to be made more clear. Otherwise looks good.

Thank you!

clang-tidy/misc/NonCopyableObjects.cpp
88

That's much better, but the "do not rely on internal implementation details" is still not very clear. Maybe add that the type should only be used as a pointer and should never be dereferenced in the user code?

This revision is now accepted and ready to land.Sep 29 2015, 6:03 PM
aaron.ballman closed this revision.Sep 30 2015, 7:11 AM

I settled on "expression has opaque data structure type 'FILE'; type should only be used as a pointer and not dereferenced" but we can tweak if that still isn't quite right.

Committed in r248907.

Thank you for the reviews!

~Aaron

I settled on "expression has opaque data structure type 'FILE'; type should only be used as a pointer and not dereferenced" but we can tweak if that still isn't quite right.

Seems good. Thank you!