This is the mail archive of the gcc@gcc.gnu.org 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: CppCoreGuidelines warnings


On 17 May 2016 at 12:10, Christopher Di Bella <cjdb.ns@gmail.com> wrote:
> Just letting you know I'm still alive!
>
> I'm currently waiting on approval from my employer before I move ahead
> with anything; for now, it's just personal research to help ease into
> it. Approval may take a month or two, as I work for a large
> corporation.

Please also note that, in terms of legal papers, the FSF is much more
flexible than one may think, but they are not very pro-active or fast
(in my past experience, things may have changed now). If you find some
internal resistance at your company, it would be good to figure out
what are the key issues for your employer and what are the possible
trade-offs, then explain them to the FSF legal team. If there is any
possible solution at all, they will surely find it out. But it would
be better to discuss all possibilities with your employer to avoid
wasteful back and forth.

>> You may wish to check also the Getting Started checklist at:
>
> Although there isn't much that I can publicly do at the moment, please
> let me know if there's anything else I can do to prepare myself; I'm
> currently researching static analysis and becoming familiar with the
> gcc codebase/contributing tips.

The 10-step checklist should help you with that: how to set-up your
dev environment, what is the process for writing, testing and
submitting patches, and some suggestions on how to interact with the
community. It is not the official contribution documentation where all
the formal details are written, but more of an organized set of tips
and advice. You don't have to finish step #1 before looking at the
rest. Note also that if you want to learn the process, small patches
do not need any legal papers: Find a typo or an obvious bug and submit
a patch following the procedure. I would suggest that an easy, mostly
about process and less about code, not copyright-able task is to look
for testcases that are duplicated in gcc.dg/ and g++.dg/ and merge
them as a unique testcase in c-c++-common/. Potential targets may have
the same name, or they may use the same dg-option flags, or they may
produce the same output when running the testsuite.

Cheers,

Manuel.


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