This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: CppCoreGuidelines warnings
- From: Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>
- To: Christopher Di Bella <cjdb dot ns at gmail dot com>
- Cc: Jason Merrill <jason at redhat dot com>, Jonathan Wakely <jwakely dot gcc at gmail dot com>, gcc Mailing List <gcc at gcc dot gnu dot org>
- Date: Tue, 17 May 2016 13:51:34 +0100
- Subject: Re: CppCoreGuidelines warnings
- Authentication-results: sourceware.org; auth=none
- References: <CACL3gUVfYsaM5ddp5+sfQ3Q+E2VKzRHjnntO-xs1Zwpvu2ca4A at mail dot gmail dot com> <CAH6eHdSXrMBZRHqu2qfAG-rbhxk+GiXmYhvDVP=fnq2HL3HB_Q at mail dot gmail dot com> <573279E9 dot 6020709 at gmail dot com> <CACL3gUUS8goAThsL6gyDJV7wdU8KmFTX2Bx0aBqNCpB8VjFAaw at mail dot gmail dot com>
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.