linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: linux-sparse@vger.kernel.org
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Subject: [PATCH] manpage: annotations
Date: Fri,  3 Jul 2020 02:04:54 +0200	[thread overview]
Message-ID: <20200703000454.55816-1-luc.vanoostenryck@gmail.com> (raw)

---
 sparse.1 | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/sparse.1 b/sparse.1
index d916ad9ee54e..068764799e00 100644
--- a/sparse.1
+++ b/sparse.1
@@ -18,6 +18,65 @@ option \fB\-Wsomething\fR.  Sparse issues some warnings by default; to turn
 off those warnings, pass the negation of the associated warning option,
 \fB\-Wno\-something\fR.
 .
+.SH ANNOTATIONS
+Sparse extends C's type system with a number of extra type qualifiers
+adding restrictions on what you can do on objects annotated with them.
+These qualifiers are specified with GCC's \fB__attribute__\fR syntax:
+.IP - 2
+bitwise
+.RS 2
+This attribute is to be used to define new, unique integer types that
+cannot be mixed with other types.
+In particular, you can't mix a "bitwise" integer with a normal integer
+expression, and in fact you can't even mix it with another bitwise
+expression of a different type.
+The integer 0 is special, though, and can be mixed with any bitwise type
+since it's safe for all bitwise operations.
+
+Since this qualifier defines new types, it only makes sense to use
+it in typedefs, which effectively makes each of these typedefs
+a single "bitwise class", incompatible with any other types.
+.RE
+.IP - 2
+force
+.RS 2
+This attribute is to be used in casts to suppress warnings that
+would be otherwise caused by this cast because of the presence of
+one of these qualifiers.
+.RE
+.IP - 2
+noderef
+.RS 2
+This attribute is to be used on a r-value to specify it cannot be
+dereferenced. A pointer so annotated is in all other aspects exactly
+like a pointer in all other respects, but trying to actually access
+anything through it will cause a warning.
+.RE
+.IP - 2
+address_space(\fIname\fR)
+.RS 2
+.RE
+.IP - 2
+context(\fIcontext\fR, \fIin\fR, \fIout\fR)
+.RS 2
+.RE
+.IP - 2
+nocast
+.RS 2
+This attribute is similar to \fBbitwise\fR but in a much weaker form.
+It is also 
+__nocast warns about explicit or implicit casting to different types
+however, the __nocast attribute disables many of the implicit type conversions
+
+.RE
+.IP - 2
+safe
+.RS 2
+This attribute specifies that the object, which should be a pointer,
+is defined to never be NULL or nontrapping.
+It causes a warning if the object is tested in a conditional.
+.RE
+
 .SH WARNING OPTIONS
 .TP
 .B \-fmax-warnings=COUNT
-- 
2.27.0

                 reply	other threads:[~2020-07-03  0:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200703000454.55816-1-luc.vanoostenryck@gmail.com \
    --to=luc.vanoostenryck@gmail.com \
    --cc=linux-sparse@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).