[clang-tidy] avoid pointer cast to more strict alignment check

[NorenaLeonetti]

Summary

Based on CERT-EXP36-C

[lebedev.ri]

test/clang-tidy/cert-avoid-pointer-cast-to-more-strict-alignment.c

18

Shouldn't there be at least one test for C++-style cast?

[aaron.ballman]

Thank you for working on this. How does this check compare with the -Wcast-align diagnostic in the Clang frontend? I believe that warning already covers these cases, so I'm wondering what extra value is added with this check?

[lebedev.ri]

What will this check say about the following code?

c++
void function(void) {
  char c = 'x';
  int *ip = reinterpret_cast<int *>(&c);
}

The clang'g -Wcast-align does not warn: https://godbolt.org/g/hVwD5S

[lebedev.ri]

Any status update here? :)
I generally do see a benefit in this check, because -Wcast-align (at least currently?) does not warn on reinterpret_cast<>().

[Eugene.Zelenko]

In D33826#856610, @lebedev.ri wrote:

Any status update here? :)
I generally do see a benefit in this check, because -Wcast-align (at least currently?) does not warn on reinterpret_cast<>().

I think will be good idea to extend -Wcast-align.

[lebedev.ri]

In D33826#856619, @Eugene.Zelenko wrote:

In D33826#856610, @lebedev.ri wrote:

Any status update here? :)
I generally do see a benefit in this check, because -Wcast-align (at least currently?) does not warn on reinterpret_cast<>().

I think will be good idea to extend -Wcast-align.

Hmm, i though it was actually intentional, but filled https://bugs.llvm.org/show_bug.cgi?id=33397 anyway back then.
I'll look into it then, should be easy.

[lebedev.ri]

In D33826#856619, @Eugene.Zelenko wrote:

In D33826#856610, @lebedev.ri wrote:

Any status update here? :)
I generally do see a benefit in this check, because -Wcast-align (at least currently?) does not warn on reinterpret_cast<>().

I think will be good idea to extend -Wcast-align.

Hm, are you *sure* reinterpret_cast<>() is not allowed to increase alignment?
There was a commit that intentionally removed that warning: (by @rjmccall, i believe)
https://github.com/llvm-mirror/clang/commit/35a38d95da89d48778019c37b5f8c9a20f7e309c

[rjmccall]

In D33826#856652, @lebedev.ri wrote:

In D33826#856619, @Eugene.Zelenko wrote:

In D33826#856610, @lebedev.ri wrote:

Any status update here? :)
I generally do see a benefit in this check, because -Wcast-align (at least currently?) does not warn on reinterpret_cast<>().

I think will be good idea to extend -Wcast-align.

Hm, are you *sure* reinterpret_cast<>() is not allowed to increase alignment?
There was a commit that intentionally removed that warning: (by @rjmccall, i believe)
https://github.com/llvm-mirror/clang/commit/35a38d95da89d48778019c37b5f8c9a20f7e309c

One of the fundamental design principles to keep in mind when implementing warnings like -Wcast-align is that we're trying to warn users about having written something dangerous, not scold them for writing code a particular way. Users do need to do these casts sometimes, and there has to be some way of doing them without a warning. So the question of when to warn has to consider whether the code is explicitly acknowledging the danger. It would, for example, be a mistake to warn in C about double-casts through (void*), because that is not something that people do accidentally; it is very likely that it is an attempt to suppress the warning. In C++, it seemed to me that a reinterpret_cast is by its nature explicitly acknowledging the danger, so it is never really appropriate to warn.

[lebedev.ri]

In D33826#772676, @aaron.ballman wrote:

How does this check compare with the -Wcast-align diagnostic in the Clang frontend? I believe that warning already covers these cases, so I'm wondering what extra value is added with this check?

In D33826#856887, @rjmccall wrote:

In D33826#856652, @lebedev.ri wrote:

In D33826#856619, @Eugene.Zelenko wrote:

In D33826#856610, @lebedev.ri wrote:

Any status update here? :)
I generally do see a benefit in this check, because -Wcast-align (at least currently?) does not warn on reinterpret_cast<>().

I think will be good idea to extend -Wcast-align.

Hm, are you *sure* reinterpret_cast<>() is not allowed to increase alignment?
There was a commit that intentionally removed that warning: (by @rjmccall, i believe)
https://github.com/llvm-mirror/clang/commit/35a38d95da89d48778019c37b5f8c9a20f7e309c

One of the fundamental design principles to keep in mind when implementing warnings like -Wcast-align is that we're trying to warn users about having written something dangerous, not scold them for writing code a particular way. Users do need to do these casts sometimes, and there has to be some way of doing them without a warning. So the question of when to warn has to consider whether the code is explicitly acknowledging the danger. It would, for example, be a mistake to warn in C about double-casts through (void*), because that is not something that people do accidentally; it is very likely that it is an attempt to suppress the warning. In C++, it seemed to me that a reinterpret_cast is by its nature explicitly acknowledging the danger, so it is never really appropriate to warn.

So we are back from where we have started, and this check does make sense.

[NorenaLeonetti]

Added a test for C++ style cast and modified the docs.

[aaron.ballman]

Have you run this check over any large code bases to see what the quality of the diagnostics are?

docs/clang-tidy/checks/cert-exp36-c.rst

9

Can you update the tests to include the ones from -Wcast-align (llvm\tools\clang\test\Sema\warn-cast-align.c) to make sure those are properly triggered by this check?

[NorenaLeonetti]

In D33826#861226, @aaron.ballman wrote:

Have you run this check over any large code bases to see what the quality of the diagnostics are?

-checks=-*,cert-exp36-c,modernize-unary-static-assert

the result:

real 52m6.886s
user 298m8.824s
sys 7m29.292s

-checks=-*,modernize-unary-static-assert

the result:

real 52m5.305s
user 302m38.508s
sys 8m53.008s

[lebedev.ri]

In D33826#866133, @NorenaLeonetti wrote:

In D33826#861226, @aaron.ballman wrote:

Have you run this check over any large code bases to see what the quality of the diagnostics are?

-checks=-*,cert-exp36-c,modernize-unary-static-assert

the result:

real 52m6.886s
user 298m8.824s
sys 7m29.292s

-checks=-*,modernize-unary-static-assert

the result:

real 52m5.305s
user 302m38.508s
sys 8m53.008s

What was meant is, run the check over some large codebase (e.g. all of the LLVM itself), and upload the results somewhere.
Then analyze the results. Are there any obvious false-positives?
If yes, then minimize the testcase, add it into test/clang-tidy/cert-avoid-pointer-cast-to-more-strict-alignment.cpp and fix it's handling.
Are there clear bugs in the analyzed code?

[JonasToth]

There is an exception to the general rule (EXP36-C-EX2), stating that the result of malloc and friends is allowed to be casted to stricter alignments, since the pointer is known to be of correct alignment.
Could you add a testcase for this case, i think there would currenlty be a false positive.

And is there a general way of knowing when the pointer is of correct alignment, or is it necessary to keep a list of functions like malloc that are just known?
If yes, i think it would be nice if this list is configurable (maybe like in cppcoreguidelines-no-malloc, where that functionality could be refactored out).

[lebedev.ri]

In D33826#866161, @JonasToth wrote:

There is an exception to the general rule (EXP36-C-EX2), stating that the result of malloc and friends is allowed to be casted to stricter alignments, since the pointer is known to be of correct alignment.

Quote for the reference:

EXP36-C-EX2: If a pointer is known to be correctly aligned to the target type, then a cast to that type is permitted. There are several cases where a pointer is known to be correctly aligned to the target type. The pointer could point to an object declared with a suitable alignment specifier. It could point to an object returned by aligned_alloc(), calloc(), malloc(), or realloc(), as per the C standard, section 7.22.3, paragraph 1 [ISO/IEC 9899:2011].

For plain calloc(), malloc(), or realloc(), i would guess it's related to max_align_t / std::max_align_t / __STDCPP_DEFAULT_NEW_ALIGNMENT__, which is generally just 16 bytes.

Could you add a testcase for this case, i think there would currenlty be a false positive.

And is there a general way of knowing when the pointer is of correct alignment, or is it necessary to keep a list of functions like malloc that are just known?
If yes, i think it would be nice if this list is configurable (maybe like in cppcoreguidelines-no-malloc, where that functionality could be refactored out).

[rjmccall]

In D33826#866170, @lebedev.ri wrote:

In D33826#866161, @JonasToth wrote:

There is an exception to the general rule (EXP36-C-EX2), stating that the result of malloc and friends is allowed to be casted to stricter alignments, since the pointer is known to be of correct alignment.

In practice, are there any malloc declarations still in use that return char* instead of void*? I assume this does not complain when the source is void*.

[aaron.ballman]

In D33826#866170, @lebedev.ri wrote:

In D33826#866161, @JonasToth wrote:

There is an exception to the general rule (EXP36-C-EX2), stating that the result of malloc and friends is allowed to be casted to stricter alignments, since the pointer is known to be of correct alignment.

Quote for the reference:

EXP36-C-EX2: If a pointer is known to be correctly aligned to the target type, then a cast to that type is permitted. There are several cases where a pointer is known to be correctly aligned to the target type. The pointer could point to an object declared with a suitable alignment specifier. It could point to an object returned by aligned_alloc(), calloc(), malloc(), or realloc(), as per the C standard, section 7.22.3, paragraph 1 [ISO/IEC 9899:2011].

For plain calloc(), malloc(), or realloc(), i would guess it's related to max_align_t / std::max_align_t / __STDCPP_DEFAULT_NEW_ALIGNMENT__, which is generally just 16 bytes.

It's a requirement from the C standard that malloc, calloc, and realloc return a suitably-aligned pointer for *any* type.

Could you add a testcase for this case, i think there would currenlty be a false positive.

And is there a general way of knowing when the pointer is of correct alignment, or is it necessary to keep a list of functions like malloc that are just known?
If yes, i think it would be nice if this list is configurable (maybe like in cppcoreguidelines-no-malloc, where that functionality could be refactored out).

Agreed, this should be a configurable list, but is should be pre-populated with the listed functions from the CERT standard.

[aaron.ballman]

In D33826#867155, @rjmccall wrote:

In D33826#866170, @lebedev.ri wrote:

In D33826#866161, @JonasToth wrote:

There is an exception to the general rule (EXP36-C-EX2), stating that the result of malloc and friends is allowed to be casted to stricter alignments, since the pointer is known to be of correct alignment.

In practice, are there any malloc declarations still in use that return char* instead of void*? I assume this does not complain when the source is void*.

FWIW, I've not found any malloc declarations that return char * instead of void *, but if someone knows of one, I'd be curious to hear of it.

[lebedev.ri]

In D33826#868085, @aaron.ballman wrote:

In D33826#866170, @lebedev.ri wrote:

In D33826#866161, @JonasToth wrote:

There is an exception to the general rule (EXP36-C-EX2), stating that the result of malloc and friends is allowed to be casted to stricter alignments, since the pointer is known to be of correct alignment.

Quote for the reference:

EXP36-C-EX2: If a pointer is known to be correctly aligned to the target type, then a cast to that type is permitted. There are several cases where a pointer is known to be correctly aligned to the target type. The pointer could point to an object declared with a suitable alignment specifier. It could point to an object returned by aligned_alloc(), calloc(), malloc(), or realloc(), as per the C standard, section 7.22.3, paragraph 1 [ISO/IEC 9899:2011].

For plain calloc(), malloc(), or realloc(), i would guess it's related to max_align_t / std::max_align_t / __STDCPP_DEFAULT_NEW_ALIGNMENT__, which is generally just 16 bytes.

It's a requirement from the C standard that malloc, calloc, and realloc return a suitably-aligned pointer for *any* type.

We are probably arguing about the details, or i'm just misguided, but you mean any *standard* type, right?

MALLOC(3)
...
The  malloc()  and calloc() functions return a pointer to the allocated memory, which is suitably aligned for any built-in type.

E.g. __m256 needs to be 32-byte aligned, and user type, with the help of alignas(), can have different alignment requirements

Could you add a testcase for this case, i think there would currenlty be a false positive.

And is there a general way of knowing when the pointer is of correct alignment, or is it necessary to keep a list of functions like malloc that are just known?
If yes, i think it would be nice if this list is configurable (maybe like in cppcoreguidelines-no-malloc, where that functionality could be refactored out).

Agreed, this should be a configurable list, but is should be pre-populated with the listed functions from the CERT standard.

[aaron.ballman]

In D33826#868167, @lebedev.ri wrote:

In D33826#868085, @aaron.ballman wrote:

In D33826#866170, @lebedev.ri wrote:

In D33826#866161, @JonasToth wrote:

There is an exception to the general rule (EXP36-C-EX2), stating that the result of malloc and friends is allowed to be casted to stricter alignments, since the pointer is known to be of correct alignment.

Quote for the reference:

EXP36-C-EX2: If a pointer is known to be correctly aligned to the target type, then a cast to that type is permitted. There are several cases where a pointer is known to be correctly aligned to the target type. The pointer could point to an object declared with a suitable alignment specifier. It could point to an object returned by aligned_alloc(), calloc(), malloc(), or realloc(), as per the C standard, section 7.22.3, paragraph 1 [ISO/IEC 9899:2011].

For plain calloc(), malloc(), or realloc(), i would guess it's related to max_align_t / std::max_align_t / __STDCPP_DEFAULT_NEW_ALIGNMENT__, which is generally just 16 bytes.

It's a requirement from the C standard that malloc, calloc, and realloc return a suitably-aligned pointer for *any* type.

We are probably arguing about the details, or i'm just misguided, but you mean any *standard* type, right?

MALLOC(3)
...
The  malloc()  and calloc() functions return a pointer to the allocated memory, which is suitably aligned for any built-in type.

E.g. __m256 needs to be 32-byte aligned, and user type, with the help of alignas(), can have different alignment requirements

C11 7.22.3p1 (in part):

The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to
a pointer to any type of object with a fundamental alignment requirement and then used
to access such an object or an array of such objects in the space allocated (until the space
is explicitly deallocated).

C11 6.2.8p2 defines fundamental alignment:

A fundamental alignment is represented by an alignment less than or equal to the greatest
alignment supported by the implementation in all contexts, which is equal to
_Alignof (max_align_t).

So I don't think this applies to only builtin types. Which makes sense, otherwise you couldn't rely on malloc to do the correct thing with struct S { char c; int i; }; struct S s = (struct S *)malloc(sizeof(struct S)); However, you are correct that it doesn't need to return a suitably aligned pointer for *any* type.

Could you add a testcase for this case, i think there would currenlty be a false positive.

And is there a general way of knowing when the pointer is of correct alignment, or is it necessary to keep a list of functions like malloc that are just known?
If yes, i think it would be nice if this list is configurable (maybe like in cppcoreguidelines-no-malloc, where that functionality could be refactored out).

Agreed, this should be a configurable list, but is should be pre-populated with the listed functions from the CERT standard.

[lebedev.ri]

In D33826#868185, @aaron.ballman wrote:

In D33826#868167, @lebedev.ri wrote:

In D33826#868085, @aaron.ballman wrote:

In D33826#866170, @lebedev.ri wrote:

In D33826#866161, @JonasToth wrote:

There is an exception to the general rule (EXP36-C-EX2), stating that the result of malloc and friends is allowed to be casted to stricter alignments, since the pointer is known to be of correct alignment.

Quote for the reference:

EXP36-C-EX2: If a pointer is known to be correctly aligned to the target type, then a cast to that type is permitted. There are several cases where a pointer is known to be correctly aligned to the target type. The pointer could point to an object declared with a suitable alignment specifier. It could point to an object returned by aligned_alloc(), calloc(), malloc(), or realloc(), as per the C standard, section 7.22.3, paragraph 1 [ISO/IEC 9899:2011].

For plain calloc(), malloc(), or realloc(), i would guess it's related to max_align_t / std::max_align_t / __STDCPP_DEFAULT_NEW_ALIGNMENT__, which is generally just 16 bytes.

It's a requirement from the C standard that malloc, calloc, and realloc return a suitably-aligned pointer for *any* type.

We are probably arguing about the details, or i'm just misguided, but you mean any *standard* type, right?

MALLOC(3)
...
The  malloc()  and calloc() functions return a pointer to the allocated memory, which is suitably aligned for any built-in type.

E.g. __m256 needs to be 32-byte aligned, and user type, with the help of alignas(), can have different alignment requirements

C11 7.22.3p1 (in part):

The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to
a pointer to any type of object with a fundamental alignment requirement and then used
to access such an object or an array of such objects in the space allocated (until the space
is explicitly deallocated).

C11 6.2.8p2 defines fundamental alignment:

A fundamental alignment is represented by an alignment less than or equal to the greatest
alignment supported by the implementation in all contexts, which is equal to
_Alignof (max_align_t).

So I don't think this applies to only builtin types. Which makes sense, otherwise you couldn't rely on malloc to do the correct thing with struct S { char c; int i; }; struct S s = (struct S *)malloc(sizeof(struct S)); However, you are correct that it doesn't need to return a suitably aligned pointer for *any* type.

I agree!
Thus, my point being, *if* the cast in question is not from void* (if it is, i don't think it is possible to warn, or prevent the warning for that matter),
shouldn't the alignment requirements of the target type be considered, even if the pointer was just returned by malloc and friends?

Could you add a testcase for this case, i think there would currenlty be a false positive.

And is there a general way of knowing when the pointer is of correct alignment, or is it necessary to keep a list of functions like malloc that are just known?
If yes, i think it would be nice if this list is configurable (maybe like in cppcoreguidelines-no-malloc, where that functionality could be refactored out).

Agreed, this should be a configurable list, but is should be pre-populated with the listed functions from the CERT standard.

[lebedev.ri]

In D33826#868185, @aaron.ballman wrote:

Ah, I think I'm catching on to the point you're raising (thank you for
the patience). If the return type is void *, we don't have enough
information to sensibly diagnose (not without data flow analysis to
determine where the original value came from, anyway), and if the
return type is not void *, we should be checking the alignment anyway.

That suggests we don't need the exception in this check at all, unless
we find extant implementations that return something other than void

Yes!

And, more than that, in some rare cases, when casting the pointer that
was *just* returned by malloc, i believe we *can* do this check too.
(i.e. in malloc case, the target type should *not* have bigger alignment
requirements than the _Alignof (max_align_t).)

Now i have fully explained my concerns :)

[NorenaLeonetti]

In D33826#866145, @lebedev.ri wrote:

In D33826#866133, @NorenaLeonetti wrote:

In D33826#861226, @aaron.ballman wrote:

Have you run this check over any large code bases to see what the quality of the diagnostics are?

-checks=-*,cert-exp36-c,modernize-unary-static-assert

the result:

real 52m6.886s
user 298m8.824s
sys 7m29.292s

-checks=-*,modernize-unary-static-assert

the result:

real 52m5.305s
user 302m38.508s
sys 8m53.008s

What was meant is, run the check over some large codebase (e.g. all of the LLVM itself), and upload the results somewhere.
Then analyze the results. Are there any obvious false-positives?
If yes, then minimize the testcase, add it into test/clang-tidy/cert-avoid-pointer-cast-to-more-strict-alignment.cpp and fix it's handling.
Are there clear bugs in the analyzed code?

I've run the check on the LLVM codebase and got these warnings in the file.

test_alignment_check.txt31 KBDownload

[lebedev.ri]

Nice!

/home/eenitot/new_llvm/llvm/lib/Support/ConvertUTFWrapper.cpp:38:26: warning: do not cast pointers into more strictly aligned pointer types [cert-exp36-c]
    UTF16 *targetStart = reinterpret_cast<UTF16*>(ResultPtr);
                         ^

Hmm, the text is well-worded, but i wonder if a bit more context, much like the -Wcast-align, would be nicer, something like:

warning: casting from type `T1` (alignment `a1`) to type `T2` (alignment `a2`) increases required alignment [cert-exp36-c]

It does mix the alignment of the type T and the alignment specified by __attribute__((aligned())) / alignas(), but i'm not sure it is possible to show that in the message..
Thoughts?

[lebedev.ri]

Ping?

[NorenaLeonetti]

In D33826#935394, @lebedev.ri wrote:

Ping?

Hi, I'm sorry I got a bit busy, I'll get back to it next year.

clang-tidy/cert/AvoidPointerCastToMoreStrictAlignmentCheck.h

+//===--- AvoidPointerCastToMoreStrictAlignmentCheck.h - clang-tidy*- C++ -*-===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CERT_AVOID_POINTER_CAST_TO_MORE_STRICT_ALIGNMENT_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CERT_AVOID_POINTER_CAST_TO_MORE_STRICT_ALIGNMENT_H
+
+#include "../ClangTidy.h"
+
+namespace clang {
+namespace tidy {
+namespace cert {
+
+/// This check will give a warning if a pointer value is
+/// converted to a pointer type that is more strictly
+/// aligned than the referenced type.
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/cert-exp36-c.html;;
+class AvoidPointerCastToMoreStrictAlignmentCheck : public ClangTidyCheck {
+public:
+  AvoidPointerCastToMoreStrictAlignmentCheck(StringRef Name, ClangTidyContext *Context)
+      : ClangTidyCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
+};
+
+} // namespace cert
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_CERT_AVOID_POINTER_CAST_TO_MORE_STRICT_ALIGNMENT_H

clang-tidy/cert/AvoidPointerCastToMoreStrictAlignmentCheck.cpp

+//===--- AvoidPointerCastToMoreStrictAlignmentCheck.cpp - clang-tidy-------===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+
+#include "AvoidPointerCastToMoreStrictAlignmentCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace cert {
+
+void AvoidPointerCastToMoreStrictAlignmentCheck::registerMatchers(
+    MatchFinder *Finder) {
+  Finder->addMatcher(
+      castExpr(hasSourceExpression(expr().bind("source"))).bind("target"),
+      this);
+}
+
+void AvoidPointerCastToMoreStrictAlignmentCheck::check(
+    const MatchFinder::MatchResult &Result) {
+  const auto *Source = Result.Nodes.getNodeAs<Expr>("source");
+  const auto *Target = Result.Nodes.getNodeAs<CastExpr>("target");
+
+  QualType SourceType = Source->getType();
+  QualType TargetType = Target->getType();
+
+  if (!SourceType->isPointerType() || !TargetType->isPointerType())
+    return;
+
+  QualType SourcePointedType = SourceType->getPointeeType();
+  QualType TargetPointedType = TargetType->getPointeeType();
+
+  if (SourcePointedType->isIncompleteType() ||
+      TargetPointedType->isIncompleteType())
+    return;
+
+  if (Result.Context->getTypeAlign(SourcePointedType) >=
+      Result.Context->getTypeAlign(TargetPointedType))
+    return;
+
+  if (Target->getCastKind() == CK_BitCast)
+    diag(Target->getLocStart(),
+         "do not cast pointers into more strictly aligned pointer types");
+}
+
+} // namespace cert
+} // namespace tidy
+} // namespace clang

clang-tidy/cert/CERTTidyModule.cpp

 #include "../ClangTidyModule.h"
 #include "../ClangTidyModuleRegistry.h"
 #include "../google/UnnamedNamespaceInHeaderCheck.h"
 #include "../misc/MoveConstructorInitCheck.h"
 #include "../misc/NewDeleteOverloadsCheck.h"
 #include "../misc/NonCopyableObjects.h"
 #include "../misc/StaticAssertCheck.h"
 #include "../misc/ThrowByValueCatchByReferenceCheck.h"
+#include "AvoidPointerCastToMoreStrictAlignmentCheck.h"
 #include "CommandProcessorCheck.h"
 #include "DontModifyStdNamespaceCheck.h"
 #include "FloatLoopCounter.h"
 #include "LimitedRandomnessCheck.h"
 #include "PostfixOperatorCheck.h"
 #include "SetLongJmpCheck.h"
 #include "StaticObjectExceptionCheck.h"
 #include "StrToNumCheck.h"
void addCheckFactories(ClangTidyCheckFactories &CheckFactories) override {
     // MSC
     CheckFactories.registerCheck<LimitedRandomnessCheck>("cert-msc50-cpp");
 
     // C checkers
     // DCL
     CheckFactories.registerCheck<misc::StaticAssertCheck>("cert-dcl03-c");
     // ENV
     CheckFactories.registerCheck<CommandProcessorCheck>("cert-env33-c");
+    // EXP
+    CheckFactories.registerCheck<AvoidPointerCastToMoreStrictAlignmentCheck>(
+        "cert-exp36-c");
     // FLP
     CheckFactories.registerCheck<FloatLoopCounter>("cert-flp30-c");
     // FIO
     CheckFactories.registerCheck<misc::NonCopyableObjectsCheck>("cert-fio38-c");
     // ERR
     CheckFactories.registerCheck<StrToNumCheck>("cert-err34-c");
     // MSC
     CheckFactories.registerCheck<LimitedRandomnessCheck>("cert-msc30-c");

clang-tidy/cert/CMakeLists.txt

 set(LLVM_LINK_COMPONENTS support)
 
 add_clang_library(clangTidyCERTModule
+  AvoidPointerCastToMoreStrictAlignmentCheck.cpp
   CERTTidyModule.cpp
   CommandProcessorCheck.cpp
   DontModifyStdNamespaceCheck.cpp
   FloatLoopCounter.cpp
   LimitedRandomnessCheck.cpp
   PostfixOperatorCheck.cpp
   SetLongJmpCheck.cpp
   StaticObjectExceptionCheck.cpp

docs/ReleaseNotes.rst

 
 Improvements to clang-rename
 ----------------------------
 
 The improvements are...
 
 Improvements to clang-tidy
 --------------------------
+- New `cert-exp36-c
+  <http://clang.llvm.org/extra/clang-tidy/checks/cert-exp36-c.html>`_ check
+
+  Checks if a pointer value is casted to a more stricter alignment.
 
 - Renamed checks to use correct term "implicit conversion" instead of "implicit
   cast" and modified messages and option names accordingly:
 
     * **performance-implicit-cast-in-loop** was renamed to
       `performance-implicit-conversion-in-loop
       <http://clang.llvm.org/extra/clang-tidy/checks/performance-implicit-conversion-in-loop.html>`_
     * **readability-implicit-bool-cast** was renamed to
- New `readability-static-accessed-through-instance
   Finds member expressions that access static members through instances and
   replaces them with uses of the appropriate qualified-id.
 
 - Added `modernize-use-emplace.IgnoreImplicitConstructors
   <http://clang.llvm.org/extra/clang-tidy/checks/modernize-use-emplace.html#cmdoption-arg-IgnoreImplicitConstructors>`_
   option.
 
 - Added alias `hicpp-braces-around-statements <http://clang.llvm.org/extra/clang-tidy/checks/hicpp-braces-around-statements.html>`_ 
   
 Improvements to include-fixer
 -----------------------------
 
 The improvements are...
 
 Improvements to modularize
 --------------------------
 
 The improvements are...

docs/clang-tidy/checks/cert-exp36-c.rst

+.. title:: clang-tidy - cert-exp36-c
+
+cert-exp36-c
+============
+
+This check will give a warning if a pointer value is converted to
+a pointer type that is more strictly aligned than the referenced type.
+ 
+This check is the same as `-Wcast-align`, except it checks for `reinterpret_cast` as well.
+
+ Here's an example:
+ 
+ .. code-block:: c
+ 
+    char c = 'x';
+    int *ip = (int *)&c;
+    // warning: do not cast pointers into more strictly aligned pointer types
+ 
+ This check does not completely include warnings for types with explicitly
+ specified alignment, this remains a possible future extension.
+
+ See the example:
+
+  .. code-block:: c
+
+    // Works fine:
+    struct x {
+      _Alignas(int) char c;
+    };
+
+    void function3(void) {
+      struct x c = {'x'};
+      int *ip = (int *)&c;
+    }
+
+    // Won't work:
+    void function4(void) {
+      _Alignas(int) char c = 'x';
+      int *ip = (int *)&c;
+      // the check will give a warning for this
+    }
+
+ This check corresponds to the CERT C Coding Standard rule
+ `EXP36-C. Do not cast pointers into more strictly aligned pointer types
+<https://www.securecoding.cert.org/confluence/display/c/EXP36-C.+Do+not+cast+pointers+into+more+strictly+aligned+pointer+types>`_.

docs/clang-tidy/checks/list.rst

.. toctree::
    android-cloexec-inotify-init1
    android-cloexec-memfd-create
    android-cloexec-open
    android-cloexec-socket
    boost-use-to-string
    bugprone-integer-division
    bugprone-suspicious-memset-usage
    bugprone-undefined-memory-manipulation
+   cert-exp36-c
    cert-dcl03-c (redirects to misc-static-assert) <cert-dcl03-c>
    cert-dcl21-cpp
    cert-dcl50-cpp
    cert-dcl54-cpp (redirects to misc-new-delete-overloads) <cert-dcl54-cpp>
    cert-dcl58-cpp
    cert-dcl59-cpp (redirects to google-build-namespaces) <cert-dcl59-cpp>
    cert-env33-c
    cert-err09-cpp (redirects to misc-throw-by-value-catch-by-reference) <cert-err09-cpp>

test/clang-tidy/cert-avoid-pointer-cast-to-more-strict-alignment.c

+// RUN: %check_clang_tidy %s cert-exp36-c %t -- -- -std=c11
+
+void function(void) {
+  char c = 'x';
+  int *ip = (int *)&c;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: do not cast pointers into more strictly aligned pointer types [cert-exp36-c] 
+}
+
+struct foo_header {
+  int len;
+};
+ 
+void function2(char *data, unsigned offset) {
+  struct foo_header *tmp;
+  struct foo_header header;
+ 
+  tmp = (struct foo_header *)(data + offset);
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: do not cast pointers into more strictly aligned pointer types [cert-exp36-c] 
+}
+
+
+// Something that does not trigger the check:
+
+struct w;
+
+void function3(struct w *v) {
+  int *ip = (int *)v;
+  struct w *u = (struct w *)ip;
+}
+
+struct x {
+   _Alignas(int) char c;
+};
+
+void function4(void) {
+  struct x c = {'x'};
+  int *ip = (int *)&c;
+}
+
+// FIXME: we do not want a warning for this
+void function5(void) {
+  _Alignas(int) char c = 'x';
+  int *ip = (int *)&c;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: do not cast pointers into more strictly aligned pointer types [cert-exp36-c]
+}

test/clang-tidy/cert-avoid-pointer-cast-to-more-strict-alignment.cpp

+// RUN: %check_clang_tidy %s cert-exp36-c %t
+
+void function(void) {
+  char c = 'x';
+  int *ip = reinterpret_cast<int *>(&c);
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: do not cast pointers into more strictly aligned pointer types [cert-exp36-c] 
+}