================
@@ -8710,3 +8710,103 @@ Declares that a function potentially allocates heap
memory, and prevents any pot
of ``nonallocating`` by the compiler.
}];
}
+
+def WrapsDocs : Documentation {
+ let Category = DocCatField;
+ let Content = [{
+The ``wraps`` attribute can be used with type or variable declarations to
+denote that arithmetic containing attributed types or variables have defined
+overflow behavior. Specifically, the behavior is defined as being consistent
+with two's complement wrap-around. For the purposes of sanitizers or warnings
+that concern themselves with the definedness of integer arithmetic, they will
+cease to instrument or warn about arithmetic that directly involves operands
+attributed with the ``wraps`` attribute.
+
+The ``signed-integer-overflow``, ``unsigned-integer-overflow``,
+``implicit-signed-integer-truncation`` and the
+``implicit-unsigned-integer-truncation`` sanitizers will not instrument
+arithmetic containing any operands attributed by ``wraps``. Similarly, the
+``-Winteger-overflow`` warning is disabled for these instances.
+
+The following example shows how one may disable ``signed-integer-overflow``
+sanitizer instrumentation using ``__attribute__((wraps))`` on a type definition
+when building with ``-fsanitize=signed-integer-overflow``:
+
+.. code-block:: c
+
+ typedef int __attribute__((wraps)) wrapping_int;
+
+ void foo(void) {
+ wrapping_int A = INT_MAX;
+ ++A; // no sanitizer instrumentation
+ }
+
+``wraps`` may also be used with function parameters or declarations of
+variables as well as members of structures. Using ``wraps`` on non-integer
+types will result in a ``-Wuseless-wraps-attribute`` warning. One may disable
+this warning with ``-Wno-useless-wraps-attribute``.
+
+``wraps`` persists through implicit type promotions and will be applied to the
+result type of arithmetic expressions containing a wrapping operand.
+``-Wimplicitly-discarded-wraps-attribute`` warnings can be caused in situations
+where the ``wraps`` attribute cannot persist through implicit type conversions.
+Disable this with ``-Wno-implicitly-discarded-wraps-attribute``.
+}];
+}
+
+def NoWrapsDocs : Documentation {
+ let Category = DocCatField;
+ let Content = [{
+The ``no_wraps`` attribute can be used to annotate types or variables as
+non-wrapping. This may serve as a helpful annotation to readers of code that
+particular arithmetic expressions involving these types or variables are not
+meant to wrap-around.
+
+When overflow or truncation sanitizer instrumentation is modified at the
+type-level through `SSCLs
+<https://clang.llvm.org/docs/SanitizerSpecialCaseList.html>`_, ``no_wraps`` or
+``wraps`` may be used to override sanitizer behavior.
+
+For example, one may specify an ignorelist (with ``-fsanitize-ignorelist=``) to
+disable the ``signed-integer-overflow`` sanitizer for all types:
+
+.. code-block:: text
+
+ [signed-integer-overflow]
+ type:*
+
+``no_wraps`` can override the behavior provided by the ignorelist to
----------------
vitalybuka wrote:
> But I see what you're saying about `__attribute__((sanitize(...)))`. Do you
> think we should use `__attribute__((sanitize(...)))` instead of
> `__attribute__((no_wraps))`? I think this may become confusing to users who
> think this is turning on a sanitizer, which is not what it does; It really is
> stating that something is "sanitizeable".
>
> And for `wraps`, maybe you prefer `__attribute__((no_sanitize(...)))` over
> `__attribute__((wraps))`?
Yes, if, like you said before, wraps is about disabling sanitizers, than
`no_sanitize` looks better. We already can apply no_sanitizer(address) on some
globals.
So, no_wraps(or sanitize) is here just to inverse ignore list for particular
variable?
I don't think it's worth of it.
In general idea of sanitizers is to check code with minimal modification.
Some stuff required to avoid false-positives, but false-negatives we usually
quite easy on them for sake of usability.
So if you need to suppress type, I don't think cherry-picking particular
variables to suppress will have wide adoption, and may only annoy opposing
users even more.
Saying from my experience in google3, I would rather over-suppress than
introduce additional burden.
BTW. you have "typedef" support in ignore list. Wouldn't e nicer just to change
e.g type from e.g. int to sanitizer_int typedef or something?
So I see value in wraps/no_sanitize, but the reverse looks questionable.
https://github.com/llvm/llvm-project/pull/115094
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
