Re: [Bug-cssc] Test binary/auto.sh fa11

[James Youngman]

On Sat, May 21, 2011 at 10:26 AM, Joerg Schilling
<address@hidden> wrote:
> James Youngman <address@hidden> wrote:
>
>> On Fri, May 20, 2011 at 10:52 PM, Joerg Schilling
>> <address@hidden> wrote:
>> > Hi,
>> >
>> > it seems that you asume that
>> >
>> >        admin -ifile s.file
>> >
>> > does not automatically switch into binary (encoded) mode.
>> > Is there any reason for this decision?
>>
>> I only assume that for non-CSSC implementations.
>
> I did test this with the original SCCS and it failed.

That shouldn't be possible; that is the point of the conditional statement:-

if $TESTING_CSSC
then
    ## Real SCCS fails on these inputs:-
    test_bin   fb10 "foo"               # no newline at end of file.
    test_ascii fa11 "x\000y\n"          # ASCII NUL.
else
    echo "Some tests skipped (since SCCS fails them but CSSC should pass)"
fi


Perhaps you set $TESTING_CSSC to true even though you were not testing
CSSC.   If so, I would expect you to get odd test results.   Some
tests in the test suite are not passed by all SCCS implementations.

You use the phrase "the original SCCS" as if there is only one.
This is unnecessarily confusing.   Many Unix vendors have released
SCCS implementations - albeit ultimately derived from the same code
base - with different bugs and having or lacking different features.
 In order to avoid needless confusion, it is necessary to be more
specific.


> I did not test it with CSSC.
>
>> Some SCCS implementations do or did fail to detect files which are, at
>> least as we would understand it, binary files, but which happen not to
>> contain start-of-file or character 10 (i.e. \n), followed by character
>> 1 (i.e. \001).  GNU CSSC does detect these files and automatically
>> turns on uuencoding.   Hence the test you named verifies this
>> behaviour for CSSC in order to detect any potential regression, but
>> doesn't require that behaviour of non-CSSC implementations of SCCS,
>> since they don't all provide it.
>
> SCCS correctly detects the null byte that the test file from test fa11 
> inserts.

Only some versions of SCCS do this.   Some do not.   Therefore test
fa11 is applied only to CSSC in order to avoid spurious failures with
those versions of SCCS.


> The test is then considered as failed by your script and this is why I am 
> asking.

Test fa11 is applied only to CSSC.   It verifies that files lacking a
final newline are treated as binary files by CSSC.   If this test
fails on CSSC, then this is a bug in CSSC.  I will fix it.   Is this
what you experienced?

If you saw something different, you're applying a test intended only
for CSSC to something else, and perhaps it will pass, perhaps not -
this is going to depend on the properties of the specific SCCS
implementation.   In the end the propoerties of the diff command being
used will also be relevant to whether a file lacking a final newline
can really be correctly dealt with by a non-encoded SCCS history file.
  In fact as far as POSIX is concerned text files must end in a
newline (since it says they're composed of lines, all of which must
end in newline).

> BTW: I verified that SunOS-3.5 does not support encoded files, so this seems 
> to
> be a feature from SunOS-4 (most likely as a result of the efforts for NSE that
> contained the first project oriented SCM [based on SCCS] and that came up to
> the end of the SunOS-3.5 period shortly before SunOS-4.0 came out).
>
> So the question is:
>
> fa11 fails with the original SCCS, does it fail with CSSC too?

No.   When the test was introduced in February 1998, it originally
verified that CSSC followed the then behaviour of SCCS, but I updated
it the following month to allow CSSC to succeed.

> It is intended that this test should fail?

No.  That's why it's included in the regression test suite.

> BTW: When I should discuss the behavior of SCCS, I would like to be able to
> tell SCCS not to automatically switch to binary mode (e.g. via an environment
> varibale to catch the case where the only reason for bein "binary" is a 
> missing
> new-line character at the end of the file.

This strategy would certainly least surprise the user.  That would of
course be a good thing.   But it does mean that correct operation then
relies on the ability of the user's diff command (whichever is first
on $PATH) to work with files lacking a terminating newline.   Of
course, it is always possible for a user to admin -i with a text file
having a final newline, and then remove the terminating newline.   So
in principle we can always have this problem.

CSSC allows the user to make this choice to override the default by
setting CSSC_BINARY_SUPPORT=disabled when they run admin.

James