1.10 Contributing

If you want to submit a patch for inclusion – from solve a typo you
discovered, up to adding support for a new feature – you should
submit it as a bug report (see Bug Reports). There are some
things that you can do to increase the chances for it to be included
in the official package.

Unless your patch is very small (say, under 10 lines) we require that
you assign the copyright of your work to the Free Software Foundation.
This is to protect the freedom of the project. If you have not
already signed papers, we will send you the necessary information when
you submit your contribution.

For contributions that doesn't consist of actual programming code, the
only guidelines are common sense. Use it.

If you normally code using another coding standard, there is no
problem, but you should use ‘indent’ to reformat the code
(see GNU Indent) before submitting your work.

Use the unified diff format ‘diff -u’.

Return errors.
No reason whatsoever should abort the execution of the library. Even
memory allocation errors, e.g. when malloc return NULL,
should work although result in an error code.

Design with thread safety in mind.
Don't use global variables. Don't even write to per-handle global
variables unless the documented behaviour of the function you write is
to write to the per-handle global variable.

Avoid using the C math library.
It causes problems for embedded implementations, and in most
situations it is very easy to avoid using it.

Document your functions.
Use comments before each function headers, that, if properly
formatted, are extracted into Texinfo manuals and GTK-DOC web pages.