Before we can accept a pull request from you, you'll need to sign a Contributor License Agreement (CLA). It is an automated process and you only need to do it once. To enable us to quickly review and accept your pull requests, always create one pull request per issue and link the issue in the pull request. Never merge multiple requests in one unless they have the same root cause. Be sure to follow our Coding Guidelines and keep code changes as small as possible. Avoid pure formatting changes to code that has not been modified otherwise. Pull requests should contain tests whenever possible.
The master branch contains current development. While CI should ensure that master always builds, it is still considered pre-release code. Release checkpoints will be put into stable branches for maintenance.
To contribute, fork the repository and create a branch in your fork for your work. Please keep branch names short and descriptive. Please direct PRs into the upstream master branch.
Please refer to Build instructions for details on how to build ProcDump for Linux.
- There are a multitude of tests included in the
testsdirectory of the repository. - Add new tests corresponding to your change, if applicable. Include tests when adding new features. When fixing bugs, start with adding a test that highlights how the current behavior is broken.
- Make sure that the tests are all passing, including your new tests.
The integration tests run using the local procdump built from source. Individual test cases are written as bash scripts and need to be inside /tests/integration/scenarios/ in order to be called automatically by run.sh.
Test scripts will return 0 when they succeed and 1 when they fail.
After writing a new test, run the run.sh script from $build/tests/integration and verify that no tests fail.
- Always tag a work item or issue with a pull request.
- Limit pull requests to as few issues as possible, preferably 1 per PR
We welcome all whitespace characters, but prefer space expanded tabs.
- Do not use
typedef, we like to know what is a struct and what is a type - Use PascalCase for:
structnamesenumnamesfunctionnames
- Use camelCase for:
local variablenames
enumnames should start with a captolE, e.g.,enum ECoreDumpType- Global variables should be prefixed with
g_, e.g.,struct ProcDumpConfiguration g_Config; struct Handles that contain astruct Eventshould have variable names prefixed byevt, e.g.,struct Handle evtIsQuit;struct Handles that contain asem_tshould have variable names prefixed bysem, e.g.,struct Handle semDumpSlot;- Please use whole words when possible
- Curly brackets,
{ }, should go on the next line after whatever necessitates them- For structs, put on same line
- Put a space before the open paren,
(, withfor,while,if, andswitchstatements- No space after function names and before parameter lists
- The
*for a pointer goes next to the variable name, e.g.,char *variable - Declare 1 variable at a time
- Declare all local variables at the start of a function
- Either initialize upon declaration, or initialize before logic
- The exception is
forloop iterators
- Wrap header (
.h) files with:
#ifndef HEADER_FILE_NAME_H
#define HEADER_FILE_NAME_H
//...
#endif // HEADER_FILE_NAME_HFor system calls and other "failable" function calls, please make use of the Trace macro and the logging methods, like so:
int rc = 0;
if ((rc = FailableFunction(...)) != 0)
{
Log(error, INTERNAL_ERROR);
Trace("WriteCoreDump: failed pthread_setcanceltype.");
exit(-1);
}struct Baz {
int Foobar;
}
int main(int argc, char *argv[])
{
int foo = 0;
int bar = 1;
char[64] str = "This is a string";
struct Baz baz = { 10 };
while (foo < 10)
{
foo++;
}
for (int i = 0; i < foo; i++)
{
printf(str);
baz.Foobar--;
}
printf("baz.Foobar is %d", baz.Foobar);
return bar - 1;
}