Re: [Bug-cssc] Fwd: GNU CSSC 1.3.1 is released

[James Youngman]

On Thu, May 26, 2011 at 9:44 AM, Joerg Schilling
<address@hidden> wrote:
> James Youngman <address@hidden> wrote:
>
>> > 2) 1.5 69/12/31 23:59:59 this is not a legal date for me as I am east to 
>> > GMT.
>> >        This is of course only happens when you use 32 bit binaries and
>> >        thus enforce 32 bit int overflows.
>> >
>> > It is however nice to see that:
>> >
>> >        TZ=GMT /opt/schily/ccs/bin/prs "-d:I: :D: :T:" -e 
>> > year-2000/s.y2k.txt
>>
>> I added this to the affected scripts:
>> TZ=GMT
>> export TZ
>
> Hi, I am sorry that I was mistaken here....whether to use GMT or not is not
> relevant.
>
>
> As you may see from a closer look, the date in my mail is a date that belongs 
> to
> (timet)-1 and this is what mktime() returns (setting errno to EOVERFLOW) when
> the date in struct tm is out of the possible range.
>
> I did a bit more research meanwhile and it turns out that 1932 is a "correct"
> printout for 2068....from a 32 bit program.
>
> If you are on a 32 bit system or running a 32 bit application, you will get
> into problems anyway. Even CSSC will stop working. Either because you are on a
> 32 bit filesystem and the range between January 18 2038 and 2068 will map to
> 1902..1932 and the same applies to your system clock, or because the OS will
> not permit you to access the files because stat() and open() will fail with
> EOVERFLOW.
>
> With most SCCS implementations, cut-off times will also stop working correctly
> in case they have to compare "negative" with "positive" time_t values.

Yes.  CSSC doesn't have this particular failure mode, since it doesn't
represent cutoff times as scalars.

However, it does have the problem you point out above for things like
delta (since the new SID needs the current date) and get -e (since the
p-file likewise needs the current date).


> By introducing similar wrappers for localtime()/gmtime()/mktime() to the rest 
> of
> SCCS as I introduced in January 2007 for my sccslog(1) program, I have been
> able to map the time_t range between 1902 and 1932 to the range 2038..2068 in
> case if a 32 bit SCCS binary version.

That makes some sense; nobody will/did use SCCS in 1932.



> SCCS now passes all tests as shipped in CSSC 1.3.1 except for the broken 
> "fa11"
> test. For a usability past January 18 2038, see above ;-)
>
> In addition, you may be interested in problems I discovered with CSSC while 
> running
> your test:

Thanks for pointing these out.   You will notice that these tests fail
as XFAIL.   That is, they are expected failures, i.e. known issues.

>
> /*--------------------------------------------------------------------------*/
> ei12...2d1
> < inserted on branch 1.1.1.1
> 3a3
>> inserted on branch 1.1.1.1
> XFAIL excl_ig_2.sh ei12: stdout format error with 
> /home/joerg/cmd/sccs/CSSC-1.3.1/src//get -s -p s.foo
> passed
> /*--------------------------------------------------------------------------*/
> ei15...2d1
> < inserted on branch 1.1.1.1
> 3a3
>> inserted on branch 1.1.1.1
> XFAIL excl_ig_2.sh ei15: stdout format error with 
> /home/joerg/cmd/sccs/CSSC-1.3.1/src//get -s -p s.foo
> passed
> /*--------------------------------------------------------------------------*/
> ei24...2d1
> < inserted on branch 1.1.1.1
> XFAIL excl_ig_2.sh ei24: stdout format error with 
> /home/joerg/cmd/sccs/CSSC-1.3.1/src//get -s -p s.foo
> passed
> /*--------------------------------------------------------------------------*/
> ei26...XFAIL excl_ig_2.sh ei26: "/home/joerg/cmd/sccs/CSSC-1.3.1/src//delta 
> -g1.5 -yNone s.foo" Expected exit code 0, got 1
> Error message: /home/joerg/cmd/sccs/CSSC-1.3.1/src//delta: Unsupported 
> option: 'g'
> passed
> /*--------------------------------------------------------------------------*/
> ei27...1,2c1,3
> < 1.10 inserted in 1.1
> < inserted on branch 1.1.1.1
> ---
>> 1.9 inserted in 1.1
>> This line inserted in 1.2 and deleted in 1.3
>> inserted in 1.5
> 4d4
> < This line inserted in 1.3 and deleted in 1.4
> XFAIL excl_ig_2.sh ei27: stdout format error with 
> /home/joerg/cmd/sccs/CSSC-1.3.1/src//get -s -p s.foo
> passed
> /*--------------------------------------------------------------------------*/
>
> ... and there is a question from looking at the way you introduced 4 digit
> years for cut-off time parameters:
>
>        How will CSSC interpret -c 2011
>
> Will it be interpreted as:
>
>        -       2020/11/30 23:59:59

I believe it should be the case above, since it's the only one that's
consistent with the historic processing of cutoff dates.   The only
way we can tell for sure that the user meant to specify a 4-digit year
is if they specify all the fields of the cutoff date.   Yes, this is a
bit frustrating.   One possible approach is yet another extension, to
allow punctuation in there.  Then the user can specify -c 2011/05  to
make it clear they don't mean -c 2020/11/05.

> or as:
>        -       2011/12/31 23:59:59

More generally on incomplete cutoff dates, this is not always the
correct cutoff time.   For years containing a negative leap second
(i.e. where UTC lags an additional second behind TAI) the last instant
of the year will be 2011/12/31 23:59:60 (since the final minute of the
year contains 61 seconds).   Hence this section of the code in CSSC
needs a small adjustment to deal with that corner case:

  month_day = get_part(s, days_in_month(month, year));
  hour      = get_part(s, 23);
  minute    = get_part(s, 59);
  second    = get_part(s, 59);

In other words it should be more like this

  month_day = get_part(s, days_in_month(month, year));
  hour      = get_part(s, 23);
  minute    = get_part(s, 59);
  second    = get_part(s, seconds_in_minute(year, month, month_day,
hour, minute));


> BTW: I would be interested in using sharing tests with you. I would e.g. be
> interested to use your tests as a base and write tests for the enhancements I
> added as well as for corner cases I can think of. Any thoughts?

I would be most pleased to include your contributed tests in the
regression test suite as long as they don't introduce gratuitous
incompatibility and they meet the FSF's requirements for inclusion
(such as copyright assignment, for example).

>
>
>
> Jörg
>
> --
>  EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
>       address@hidden                (uni)
>       address@hidden (work) Blog: http://schily.blogspot.com/
>  URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
>