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

[Joerg Schilling]

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.

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.

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:

/*--------------------------------------------------------------------------*/
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
or as:
        -       2011/12/31 23:59:59


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?



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