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

[Joerg Schilling]

James Youngman <address@hidden> wrote:

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

OK, I just wanted to make sure you know about these issues. 

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

BTW: the hack I implemented will not work correctly in late 2039 as Russia 
changed their daylight saving rules this year. Another reason to switch to 
GMT..... 


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

SCCS permits a slash between the day spec parts, this is why I plan to permit
4 digit years with '/' between year and month.


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

This has been discussed in the OpenGroup standard list already, I believe this 
is something that you cannot handle correctly in UNIX.


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

I am sorry, but I cannot do something that is forbidden by law. "copyright 
assignment" is forbidden by law in Europe.

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