Re: [Bug-cssc] bug-CSSC post from address@hidden requires approval

[James Youngman]

address@hidden (Joerg Schilling) wrote:

> Hi,
>
> what it the purpose of the CSSC implementation? Is it just for fun or is it
> intended to be valuable for dayly use?

It's intended for daily use.   In fact, it's been in daily use for 14
years or so.

> It is intended to be fully compatible to SCCS?

It depends on how you mean; there are a number of different versions
of SCCS which differ slightly.   It's intended to be useful for people
trying to interoperate with those implementations of SCCS.   In
practice this normally means implementing the union of those features.

> Is it intended to be compatible to the POSIX standard?

In a word, yes.   But there are a many things of course that the POSIX
standard doesn't specify.


> This is a long list of possible problems that may need a discussion depending
> on your goals....
>
>
> I just found the following oddities with "val" from CSSC:
>
>
> Testing with files created by a standard UNIX SCCS, I get the following 
> problem:

There is no single standard "UNIX SCCS".   Various implementations are
(I'm guessing) forks.   With some small modifications.


> val: sccs/help.d/SCCS/s.cmds: line 31: Corrupted SCCS file. (Unknown flag 
> 's'.)
>
> ... the 's' flag has been present on Solaris since quite a while.....
>
> Out of curiosity: the new 'x' flag is not mentioned by your "val"
> implementation if present in a SCCS history file.

Yes.  The 'x' flag is from SCO SCCS.   I'm not sure what you're
suggesting val should do differently here.


> With a SCCS history file created on UNIX 25 years ago, I get:
>
> val: libndbm/SCCS/s.dbm.h: line 35: Corrupted SCCS file. (Missing arg)
>
> just for an empty comment line...

It looks like later versions of SCCS reliably include the space after
the 'c' introducing the comment line.   CSSC's val therefore checks
for this, since in the absence of any definition of the file format,
I've relied on the features SCCS implementations seem to have in
common (including this trailing space).     Since I guess you're now
pointing out that not all SCCS implementations include a space here,
I'll adapt the code.   Fully correcting this means understanding
whether any implementations attempt to preserve such a feature.   Do
you know of any implementations which insert such a comment into a
delta?

I think including an example as a test case would be helpful too.
I've attached a program which removes everything from the SCCS file
except its structure.   Could you try running it on your example and
send me the result?

> Testing with files created by a recent SCCS, I get the following message:
>
> val: warning: The 'y' flag specifies a keyword letter '*', but %*% is not a 
> recognised SCCS keyword
> val: warning: The 'y' flag specifies a keyword letter 'd', but %d% is not a 
> recognised SCCS keyword
> val: warning: The 'y' flag specifies a keyword letter 'e', but %e% is not a 
> recognised SCCS keyword
> val: warning: The 'y' flag specifies a keyword letter 'g', but %g% is not a 
> recognised SCCS keyword
> val: warning: The 'y' flag specifies a keyword letter 'h', but %h% is not a 
> recognised SCCS keyword
>
> These are keywords that have been introduced 3 years ago (well the flag 'y'
> parameter '*' really relates to %sccs.include.filename% - a more than 20 year
> old extension added in April 1990 by Keith Bostic).

The y flag was introduced into Solaris 8, I think.    But with all
these extra keywords, it looks like we have some implementation work
to do.   What do those keywords expand to?

> This looks strange:
>
> val: warning: this file has been written by a version of SCCS which uses 
> four-digit years, which is contrary to the common SCCS file format (though it 
> might have been a  good idea in the first place)
>
> Note that since 1999 every SCCS implementation is able to read 4 digit year
> numbers correctly without a warning. Why is there a warning from your program?

Because I've never seen an implementation of SCCS actually produce a
4-digit year.   I concluded that the SCCS file format (which, let's
face it, isn't documented anywhere) requires 4-digit years.

>
>
> Very strange is this:
>
> val: warning: s.inode.c is a BitKeeper file.
> val: warning: s.inode.c: bad checksum (expected=52330, calculated 59498).
> val: s.inode.c: line 51: Corrupted SCCS file. (Bad value '4' for 'e' flag.)
>
> If you know this is a BitKeeper file, why do you complain about the checksum
> that you just cannot compute? Why do you complain about the value 4 for the
> encoding flag?

Maybe we should just bail on validation entirely for BitKeeper files.

> Are you interested to follow the SCCS development with CSSC?

I'm interested in maintaining compatibility.

> Please note that the SCCS implementation does not check every detail in a
> history file and thus leaves room for future enhancements that will be
> accepted by every SCCS implementation but aparently not by CSSC.
>
> BitKeeper e.g. uses a bug in the SCCS parser related to delta comments in
> order to place enhancements. I plan to implement other enhancements into SCCS
> and base them on extensions in the history file that are not flaged by SCCS.
>
> Future SCCS implementationy may however need history file extensions that will
> not be accepted by other SCCS implementations.
>
> There is a need to switch to GMT based time stamps in order to prevent 
> problems
> with deltas from the hour that you see twice while switching to DST.

That's not the half of it.   The timestamps in all SCCS files are
ambiguous for all times of day, it doesn't matter whether they specify
a date on which some time zone has a retrograde step.   Since the file
does not include the time zone, it is necessary (for users) to make
some assumption about the time zone of the SCCS file.   Most people
don't know this and it's not uncommon for the same history file to be
updated


> There needs to be a way to mark converted SCCS history files.
>
> What are your future plans on CSSC?

I plan to make sure it continues to work and is compatible with
traditional SCCS implementations.


> BTW: it seems that some of the commands from CSSC may be in conflict with 
> SCCS.
> If you install into /bin /usr/bin or similar, you should use different names
> than SCCS.

CSSC installs itself in the location and with program names controlled
by the --prefix and --program-* options specified to the "configure"
script.   That is, it goes where it's told to.   Certainly some people
require CSSC to be able to work with their history files without any
need for change to their shell scripts and so forth, and to do that it
needs to use the same command names.

James