This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adoption of C subset standards

On 09/01/17 15:15, Nathan Sidwell wrote:
> On 01/09/2017 08:58 AM, David Brown wrote:
>> I don't know about CERT-C, but one of the challenges of implementing
>> MISRA coding standards checking in gcc is that the MISRA documents are
>> not free.  They are cheap (about $10, I think), but since they are not
>> free there are likely to be copyright complications.  I think it would
>> be difficult for gcc to have a warning that rejects non-zero octal
>> constants with the message "MISRA Rule 7.1: Octal constants shall not be
>> used", even though it should be fairly straightforward (and highly
>> desirable) for gcc to have a warning on the use of non-zero octal
>> constants.
> Well, there are the effective-c++ warnings that come from Scott Meyers'
> (non-zero-cost) books.  so it must be possible to do something:
> @item -Weffc++ @r{(C++ and Objective-C++ only)}
> @opindex Weffc++
> @opindex Wno-effc++
> Warn about violations of the following style guidelines from Scott Meyers'
> @cite{Effective C++} series of books:
> nathan

I am not an expert in these matters (there are plenty of folks at gnu
who could give much better advice).  But I think there is a difference
between explicitly using some 50+ rule numbers and titles from a
document (and that is what you want with MISRA compliance checking), and
checking for a few general good practice recommendations for C++ that
are discussed in a book.

Regardless of that sort of issue, I think on previous occasions when the
topic of MISRA (or other coding standard) checking came up, there has
been a general opinion from the gcc developers that the compiler itself
is not the best place for this sort of checking - they recommend an
external tool, and don't want the main code base cluttered with such
specific warnings for the dozens of coding standards in common use.

On the other hand, I think it makes sense to use the compiler's parsing
and analysis passes - and for the end user, integrating MISRA checking
with compilation would be very convenient.  I think a plugin is the
"happy medium" here.  gcc developers and users who have no interest in
MISRA will not be bothered by it, while those embedded developers who
/do/ need it would be able to use it as though it were built in to the
compiler.  And I suspect that it would be easier for someone to write a
MISRA checker as a plugin than as an addition to the compiler.  (I have
no experience with either plugin development or gcc development - merely
a small knowledge from what I have read.)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]