<div dir="ltr">Chris,<div><br></div><div>Thanks a lot for the reply, it's really great to have a feedback loop with MISRA. As a starting point we are trying to understand if it's OK to implement open-source clang-tidy checks based on the Autosar C++14 guidelines, from a legal/license point of view. I've sent a mail about this to <a href="mailto:admin@autosar.org">admin@autosar.org</a> - is that correct or should I direct my questions to MISRA directly?</div><div><br></div><div>Regarding technical questions, should we direct them to your email directly, via this mailing list or by some other means? There's also the <a href="https://forum.misra.org.uk">MISRA forums</a> which I think work pretty well, even though the feedback time is rather high. I have <a href="https://forum.misra.org.uk/thread-1586.html">asked</a> there whether it makes sense to post Autosar-related questions or not. </div><div><br></div><div>Best regards,</div><div>Carlos</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 1, 2021 at 11:56 AM Chris Tapp (MISRA CPP Chair) <<a href="mailto:chair.cpp@misra.org.uk">chair.cpp@misra.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div style="overflow-wrap: break-word;">
Hi All,
<div><br>
</div>
<div>I am the current chair of the MISRA C++ Working Group.</div>
<div><br>
</div>
<div>As a bit of background, the Autosar guidelines are currently being merged into an updated MISRA C++ document (support for C++17, with C++20 and later planned). Autosar C++ will be retired when this work is complete, with Autosar moving to the
 updated MISRA guidelines. There will be significant differences between the MISRA and Autosar documents - for example, MISRA will not be including any guidelines that are related to (software development) process, coding style nor most of those related to
 software design.</div>
<div><br>
</div>
<div>As part of this ongoing work, a number of the Autosar team have joined the MISRA group. I therefore have good contacts with Autosar and the people who developed Autosar C++14. I would be more than happy to answer any questions that you may have
 related to Autosar or MISRA.</div>
<div><br>
</div>
<div>Note - it may also be worth looking at MISRA Compliance:2020 (<a href="https://www.misra.org.uk/app/uploads/2021/06/MISRA-Compliance-2020.pdf" target="_blank">https://www.misra.org.uk/app/uploads/2021/06/MISRA-Compliance-2020.pdf</a>), as this defines
 what is required to make a claim of "MISRA compliance”.</div>
<div><br>
</div>
<div>Chris</div>
<div>
<div dir="auto" style="font-family:"Helvetica Neue";font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)">
<div dir="auto" style="text-align:start;text-indent:0px">
<div dir="auto" style="text-align:start;text-indent:0px">
<div dir="auto" style="text-align:start;text-indent:0px">
<div dir="auto" style="text-align:start;text-indent:0px">
<div style="color:rgb(0,0,0);letter-spacing:normal;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<table cellspacing="0" cellpadding="0" style="border-collapse:collapse">
<tbody>
<tr>
<td valign="baseline" style="width:32px;padding:0px 5px">
<div style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal">
<span></span></div>
</td>
</tr>
</tbody>
</table>
</div>
</div>
</div>
</div>
</div>
</div>
<span style="font-family:"Helvetica Neue";font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)">—</span>
<div style="font-family:"Helvetica Neue";font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;color:rgb(0,0,0)">
<table cellspacing="0" cellpadding="0" style="border-collapse:collapse">
<tbody>
<tr>
<td valign="baseline" style="width:32px;padding:0px 5px">
<div style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal">
<span></span></div>
</td>
</tr>
</tbody>
</table>
</div>
<span><img id="gmail-m_-53294507928841950434870AB31-890C-4118-9692-1120A729CEE4" src="cid:17cdb654ed9f50314371"></span>
<div style="color:rgb(0,0,0);font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:"Open Sans Light"">
<span><br>
Chris Tapp, MISRA C++ Chair</span></div>
<div style="color:rgb(0,0,0);font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:"Open Sans Light";min-height:17px">
<br>
<span></span></div>
</div>
<div>
<blockquote type="cite">
<div>On 28 Oct 2021, at 13:55, Aaron Ballman via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div>
<br>
<div>
<div>On Wed, Oct 27, 2021 at 5:12 PM Carlos Galvez <<a href="mailto:carlosgalvezp@gmail.com" target="_blank">carlosgalvezp@gmail.com</a>> wrote:<br>
<blockquote type="cite"><br>
That's great to hear, thanks! Will give it a kickstart one of these days :)<br>
</blockquote>
<br>
Excellent, thank you!<br>
<br>
<blockquote type="cite">You have a very valid point about the feedback loop, and that's one of the pain points of Autosar. Therefore some rules might need to be left out or enforced in a "best effort" way. Or made configurable so that if they are ambiguous
 they can be enforced following a handful of interpretations. At least Autosar makes it clear which rules are meant to be "automatically enforceable" and which ones aren't. Some rules are also impractical to follow strictly so I can foresee the need for partial
 deviations via configuration. Autosar also inherits some MISRA rules, for which one can actually ask questions in the MISRA forums directly, so that's good.<br>
<br>
Would be interesting to have several companies contributing to it and openly discuss those rules that are more ambiguous or poorly written. Who knows, maybe the Autosar authors come across these checks and help clarifying!<br>
<br>
All in all, Autosar is not perfect but it's an important enabler for e.g. the automotive industry to finally leave MISRA C++08 and move to modern C++14. There's plans for new MISRA guidelines covering C++17 but it's unclear when they'll be published, so we
 need to live with Autosar for a little more.<br>
</blockquote>
<br>
Agreed, and to be clear, we don't have a requirement that there is a<br>
feedback loop with the proposal authors before adding a new module to<br>
clang-tidy. I mostly brought it up as an existing source of pain with<br>
the C++ Core Guideline checks. I'd like to avoid similar issues with<br>
new modules because lacking a feedback loop makes the code review<br>
process significantly harder when the rule is unclear (which<br>
negatively impacts reviewers, patch authors, and clang-tidy users).<br>
<br>
~Aaron<br>
<br>
<blockquote type="cite"><br>
<br>
On Wed, Oct 27, 2021 at 7:47 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>> wrote:<br>
<blockquote type="cite"><br>
On Wed, Oct 27, 2021 at 11:29 AM Carlos Galvez via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
<blockquote type="cite"><br>
Hi!<br>
<br>
We are following the Autosar C++14 guidelines and were thinking to add a clang-tidy module for it and start implementing checks. There's a couple local forks with some checks here and there but never made it upstream. I believe quite a lot of them are already
 covered by the existing checks (e.g. cppcoreguidelines) so most of the work would be about creating aliases and adding some extra configuration.<br>
<br>
What do you think, would that be ok? Both about adding the Autosar module itself, but also making aliases from one coding guideline (e.g. cppcoreguidelines) to another coding guideline (autosar). Typically the alias is from a non-coding guideline (e.g. bugprone)
 to a coding guideline (cppcoreguidelines).<br>
<br>
We can of course have our own local fork but it's nice to be able to contribute upstream so everyone can benefit. Autosar would fit well together with the existing guidelines (CppCoreGuidlines, CERT, HiCPP, etc).<br>
</blockquote>
<br>
Personally, I'm okay with adding a module for AUTOSAR checks. It's an<br>
industry standard set of coding conventions like many of the other<br>
modules we have. However, one issue we've run into with things like<br>
the C++ Core Guidelines is a lack of a useful feedback loop when there<br>
are enforcement questions. Do you have contacts with anyone<br>
maintaining AUTOSAR so that if we run into questions we'll have some<br>
guidance on how to resolve them?<br>
<br>
As for aliases from one coding guideline to another; I think that's<br>
fine. We already have the issue where changing the primary check may<br>
cause the alias to no longer be valid, so I don't think this would<br>
introduce any new problems we don't already have to watch out for. One<br>
thing that could get a bit weird is with documentation (aliases<br>
typically automatically redirect back to their primary check, so it<br>
might be weird to go to the docs for an AUTOSAR check and wind up in<br>
CERT C++ or something. But if that causes problems in practice, I<br>
think they can be handled as they come up.<br>
<br>
~Aaron<br>
<br>
<blockquote type="cite"><br>
Best regards,<br>
Carlos<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote>
</blockquote>
</blockquote>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br>
The MISRA Consortium is a limited company registered in England and Wales<br>
Registered number: 13152596<br>
Registered office: 1 St James Court Whitefriars, Norwich, Norfolk, England, NR3 1RU<br>
VAT number GB 377 2093 78
</div>

</blockquote></div>