[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Joerg Schilling
Subject: Re: [Bug-cssc] Fwd: GNU CSSC 1.3.1 is released
Date: Thu, 26 May 2011 10:44:04 +0200
User-agent: nail 11.22 3/20/05

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:
> export TZ

Hi, I am sorry that I was mistaken here....whether to use GMT or not is not 

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 

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 
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 
your test:

< inserted on branch 
> inserted on branch 
XFAIL excl_ig_2.sh ei12: stdout format error with 
/home/joerg/cmd/sccs/CSSC-1.3.1/src//get -s -p s.foo 
< inserted on branch 
> inserted on branch 
XFAIL excl_ig_2.sh ei15: stdout format error with 
/home/joerg/cmd/sccs/CSSC-1.3.1/src//get -s -p s.foo 
< inserted on branch 
XFAIL excl_ig_2.sh ei24: stdout format error with 
/home/joerg/cmd/sccs/CSSC-1.3.1/src//get -s -p s.foo 
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: 
< 1.10 inserted in 1.1 
< inserted on branch 
> 1.9 inserted in 1.1 
> This line inserted in 1.2 and deleted in 1.3 
> inserted in 1.5 
< 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 

... 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?


 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]