* ```gnutls_credentials_``` for the credentials structures
* ```gnutls_global_``` for the global structures handling
+All exported API functions must be listed in libgnutls.map
+in order to be exported.
+
Internal functions, i.e, functions that are not exported in the API but
are used internally by multiple files, should be prefixed with an underscore.
For example `_gnutls_handshake_begin()`.
Internal structures should not be exported. Especially pointers to
internal data. Doing so harms future reorganization/rewrite of subsystems.
+They can however be used by unit tests in tests/ directory; in that
+case they should be part of the GNUTLS_PRIVATE_3_4 tag in libgnutls.map.
-All exported functions must be listed in libgnutls.map.in,
-in order to be exported.
+
+# Header guards
+
+ Each private C header file SHOULD have a header guard consisting of the
+project name and the file path relative to the project directory, all uppercase.
+
+Example: `lib/srp.h` uses the header guard `GNUTLS_LIB_SRP_H`.
+
+The header guard is used as first and last effective code in a header file,
+like e.g. in lib/srp.h:
+
+```
+#ifndef GNUTLS_LIB_SRP_H
+#define GNUTLS_LIB_SRP_H
+
+...
+
+#endif /* GNUTLS_LIB_SRP_H */
+```
+
+The public header files follow a similar convention but use the relative
+install directory as template, e.g. `GNUTLS_GNUTLS_H` for `gnutls/gnutls.h`.
# Introducing new functions / API
When it is necessary, or desireable to enable the new features by default
(e.g., TLS1.3 introduction), the "next" releases should be used (and
introduced if necessary), to allow the modification to be tested for an
-extended amount of time.
+extended amount of time (see the [Release policy](RELEASES.md)).
# API documentation