[C-safe-secure-studygroup] Criteria for freely available ISO/IEC JTC 1 standards

Martin Sebor msebor at gmail.com
Fri Jan 6 03:07:39 UTC 2017


On 01/05/2017 10:45 AM, Robert Seacord wrote:
> I don't think this group can consider attributes for 17961, because it's
> out of scope.  If you recall the conversation yesterday, the study group
> decided to focus on C11.  As attributes are being proposed for C2X, I
> think they are out of scope for this study group.
>
> I think some ideas may come out of this study group, as Aaron suggests,
> for proposals to WG14.  In general, this study group is (and has
> already) going to complain a lot about the C language, but we're not
> going to try to fix it (that's what WG14) does.  The study group's focus
> is to decide when analyzers and compilers should warn the programmer
> that they are doing something unsafe or insecure (in their C11 code).

Support for annotations in one form or another (whether they are
attributes, pragmas, lint-like comments, or whatever else) is
pervasive in both compilers and analyzers.  They represent existing
practice and serve not so much to fix problems with the language but
more as a means to give the tools more information about a program
than the language makes otherwise possible.

Using the example of fallthrough: without some sort of an annotation
to let the analyzer distinguish intended instances of falling through
into the next label from bugs, a "thou shalt not fall through" coding
rule leads to orders of magnitude more false positives than true
positives, making it impractical.

By excluding annotations from our discussion we would likely be forced
to exclude rules that depend on them.  That would be unfortunate.  It
seems that at a minimum, we should be able to talk about annotations
in the abstract, without discussing their specific syntax, and refer
to them in the document.

That said, I think by not endorsing one of the existing mechanisms
we would miss an opportunity to pave the way for a standard annotation
syntax that programs could use with all conforming tools, compilers
and analyzers alike.  And given that C++ attributes are an ISO standard
and our target vehicle is likely an ISO TS, it seems that endorsing
anything else would be counterproductive, as would WG14 coming up with
its own annotation mechanism that's different from C++.

Martin

>
> rCs
>
> On Thu, Jan 5, 2017 at 12:20 PM, Aaron Ballman via
> C-safe-secure-studygroup <c-safe-secure-studygroup at lists.trustable.io
> <mailto:c-safe-secure-studygroup at lists.trustable.io>> wrote:
>
>
>
>     It is my hope that this group does consider attributes. I've put forth
>     a proposal for a generalized syntax in N2049, as well as several
>     proposals for concrete attributes, which were favorably considered in
>     Pittsburgh. I will have follow up papers for Markham. My hope is that
>     C gains a standardized mechanism for annotating source constructs, and
>     that this group can make recommendations on how best to apply those
>     attributes to the standard library, as well as any additional
>     attributes we think may be appropriate to recommend.
>




More information about the C-safe-secure-studygroup mailing list