Add C preprocessor defintion identifying the Multics C compiler

[johnsonjh.dev@…]

I propose that we define __COMPILER_MULTICSC__ automatically, which programs can use to determine that they are being built with the "Multics C Compiler". This is in-line with the KCC C compiler for TOPS-20 defining __COMPILER_KCC__, etc. (Clang does similar, defining __clang_version__ to the version in use, Vbcc defines __VBCC__, etc.)

Currently Multics C automatically defines "multics" which can be used to identify the platform, but nothing for identification of the specific compiler. This would be the equivalent of passing the -def __COMPILER_MULTICSC__ control argument to cc.

Because Multics C is known to be somewhat deficient, it's common to have various Multics C-specifc workarounds in C programs, even those written extremely portably, and guard those workarounds with #ifdef multics.

Once we have the future theoretical bug-free non-Multics C-based compiler, whatever it might end up being, it will become important to be able to differentiate between the different compilers at compile-time. While those compilers will of course identify themselves in a similar fashion, it is still useful to differentiate Multics C.

We have the source code to the cc compiler driver (see >sl3p>cc>s>bound_cc_commands.s.archive>c_compile.pl1) so making this addition would be trivial, and there would be no effect on any existing C code that does not have knowledge of or check for the definition.

Programs that do wish to use the definition could do so:

#ifdef multics
/* Multics OS code */
# ifdef __COMPILER_MULTICSC__
/* Multics C Compiler specific code */
# else
/* Other Multics compilers */
# endif
#else
/* non-Multics OS code */
#endif

A real-life example of a program that would benefit is ​http://gitlab.com/dps8m/crc - there are 12 checks for the multics definition and of those 12, only one is really checking for "Multics, the operating system". The other 11 uses are actually specific to "Multics C, the compiler".