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.