### 6.10 CSSC Extensions

There are some respects in which CSSC behaves unlike other versions of SCCS. These differences mainly relate to the removal of arbitrary limits or problems, and generally do not pose an interoperability problem. The most important extensions are listed below.

Line Length

  By default, CSSC enforces no line length limits. See Maximum Line Length.

Date handling

  The `-c` option to `get` supports four-digit years. See The Good News.

Binary file handling

  When you generate a new SCCS file with `admin -i`, the `admin` command will automatically determine if the file needs to be encoded. Other versions of SCCS which do this rely on being able to seek in the input file specified as the argument to the `-i` option, which means that this is not possible if the initial file body is being read by a pipe. The CSSC implementation of `admin` does not have this limitation, since it seeks on the file being created instead. See Unemulated Features.

Combinations of features

  Various other SCCS implementations have extensions (for example the `x` and `y` flags and binary file encoding). The CSSC suite attempts to honour all of these extensions, and is probably the only implementation which has all these features. If you try to use a feature which is specific to only one implementation of SCCS, CSSC will issue a warning that what you are doing is not portable.

  If you use features of CSSC which are extensions originating in more than one other SCCS implementation, for example both the `x` and the `y` flags, you have effectively tied yourself to CSSC. Once you are in that position, you are no longer able to interoperate with any other version of SCCS (since, in this example, any other version of SCCS will fail to understand either the `x` or the `y` flag). If interoperability with other versions of SCCS is no longer an issue, you might as well bite the bullet and migrate to a more modern configuration control system entirely. See Overview.

Validation

  The CSSC implementation of `val` implements some checks that other implementations lack. Howver, it is not complete, and so there are also checks that other implementations make that CSSC does not.

Error Messages

  The error messages issued by CSSC are intended to be self-explanatory and so lack reference numbers like ‘`(ge4)`’.

Closed File Descriptors

  If you invoke CSSC with file descriptor 0, 1 or 2 closed, that file descriptor is attached to `/dev/null`. This prevents error messages going into a file opened by CSSC for writing (for example an SCCS file).

Read-only reaction to unsupported features

  If CSSC discovers a construct in an SCCS file which it doesn’t understand, it will avoid modifying the file (though read-only tools like `prt` and `get` will still work).

Invoking other tools

  It is usual for CSSC to invoke other programs, for example `diff` and the MR-validator specified by the `v` flag. However, with the exception of the `sccsdiff` shell script, the tools within the CSSC suite do not invoke each other. For example, `delta` does not invoke `get`. This behaviour is different to the traditional architecture of SCCS and might introduce subtle differences of behaviour. Any such differences are bugs; see Reporting Bugs.

Environment

  Some environment variables are specific to CSSC. See Environment Variables.

See also Missing Features and other Problems.