[Coco] cprep19 __FILE__ fix?

[Stephen H. Fischer]

Hi,

I discovered and downloaded the source for c.comp a few days ago, but I 
cannot find out where it came from now.

It included source for Clib. Both Krieder's and MW versions.

I put it up on my web page:

http://home.mindspring.com/~sfischer1/

I do not see ctime.

Enjoy.

SHF

----- Original Message ----- 
From: "Michael Furman" <n6il at ocs.net>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Wednesday, May 25, 2011 2:49 PM
Subject: Re: [Coco] cprep19 __FILE__ fix?


>
> On May 25, 2011, at 12:53 PM, Willard Goosey wrote:
>
>> On Tue, May 24, 2011 at 10:12:09PM -0700, Stephen H. Fischer wrote:
>>> The __DATE__ should (must) be changed to return a date in the 2xxx range 
>>> as
>>> it is "Today's" date.
>>
>> OK, easy enough.  But someone who's good at binary patching and/or
>> disassembling things should fix Krieder's ctime() properly.  And that,
>> btw, would not be me.  I'm not very good with 6x09 assembler.
>
>
> Willard, I looked into this a few months ago.  Off the top of my haead:
>
> 1) I have some source for the Krieder C library, but when I assembled it, 
> it was not exactly the same as binary copies floating around.  This 
> reduces my confidence that the resulting clib after hacking will actually 
> work properly, and makes it difficult to generate a patch that will always 
> work.  The date command returns the correct year.
>
> 2) clib's asctime function had some contribution to the problem but the 
> details escape me ATM.
>
> 3) I took a look at Nitros9's date command and it has some Y2Kish stuff 
> there but it's not clear if it works correctly.  The algorithm there 
> seemed a bit convoluted or worked the problem backwards (from my 
> perspective) for some unknown reason (to optimize it? for 8-bit math 
> apparently?).  The comment in date.asm is from Grandpa Gene:
> *   5      1996/09/25  Gene Heskett
> * Made Y2K compliant.
>
> 4) It appears that Nitros9 keeps a 1-byte year, so this is what one would 
> expect F$Time to return.  According to OS9Defs:
> D.Time         equ       .                   System Time
> D.Year         rmb       1
>
> I'll try to fill in the rest of details from my previous investigation of 
> this issue later this evening.
>
> The result was that to fix UUCPBB (Which reported the year as 19111 in 
> some places and 111 in others) I basically changed any occurrence of 
> '19%d', year to '%d', 1900+year.  This was a hack that doesn't address the 
> real lower level problem.
>