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

[Robert Seacord]

so here is what we wrote last time:

The rules documented in this Technical Specification do not rely on source
code annotations or assumptions of programmer intent. However, a conforming
implementation may take advantage of annotations to inform the analyzer.

This is at
https://gitlab.com/trustable/C_Safety_and_Security_Rules_Study_Group/wikis/preamble
in case you want to change it.

So last time we submitted a proposal to C for attributes, some attributes
were adopted into the language as keywords.  This is now part of C11, so
these no longer count as annotations and we can reference them in our rules.

Stuff that might get included in C2X is tricker, and I don't know how to do
it.  One thing we could do is change our scope and decide that we want to
parallel C2X.  This is a very important decision as it would very
definitely affect our schedule.  If we were to target C2X, I would
recommend are schedule would be the C2X schedule +6 months so that we would
have time to adapt.

I think this approach would increase the difficulty of our undertaking by a
3X factor (WAG).  This is because, instead of having a fixed standard to
work against we would have an ever evolving set of proposals to keep track
of.  Maybe 3X is an underestimate.    It might honestly be better to do
this for C11 for now, and after publishing, fire up another group to
address C2X after it is published.

Thanks,
rCs

On Thu, Jan 5, 2017 at 10:07 PM, Martin Sebor <msebor at gmail.com> wrote:

> 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.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20170106/6c8efbd1/attachment.html>