These rules are a combination of my own and (most importantly) other
people's experiences.  If you have ideas regarding portability, please
contact the maintainer.

If you spot any code that does not follow these rules, please report it
as a bug and/or send a patch.  An exception to this are the files in the
tads2/ and tads3/ directories; they are read-only.  Don't touch them.
Any changes made to them will be lost next time FrobTADS gets in sync
with the TADS base code.  Problems in any of these files should only be
reported, not fixed.

Sidenote: If you're looking for object oriented programming guidelines,
forget it.  FrobTADS is object based, not object oriented.  It uses C++
mostly as a "better C".  Classes and objects are only used to make
things simpler, not with OOP in mind.

OK, here goes:


The "common.h" header file
==========================

In new source files, always, Always, ALWAYS, #include "common.h" as the
first header.  Everywhere; both in C and C++ sources, in headers and
*.c/*.cc/*.cpp files.


Non-standard compiler features
==============================

Don't use compiler-specific non-standard features; not everyone has GCC
installed.  You should always compile with g++'s "-std=c++14 -pedantic"
flags (use "-std=c11" for gcc).  Note that "-pedantic" cannot check your
code for full ANSI correctness; they are only meant to catch obvious
blunders.


Non-ANSI/ISO functions
======================

If you feel like using a non-ANSI function (for example a BSD one), use
it, but provide a working ANSI-only fall-back, as is already done with
some functions in src/missing.[h/cc].  Also look at the implementation
of os_get_sys_clock_ms() in src/oscurses.cc on how to handle portability
issues.

Generally, if such a function has equivalent ones in other standards, just
check for them in the appropriate cmake file and structure your code to use the
information the configuration script detects.
