[Coco] Climax C Compiler setup

Mon Mar 25 00:46:57 EDT 2019

On Sunday 24 March 2019 23:19:27 Walter Zambotti wrote:

> Gene
>
> Thanks for the include files.
>
> There was also no definitions for TRUE, FALSE & ERROR but I easily
> added them to cp.h.
>
> I managed to get cprep19b to compile.
>
> I modified the readln routine so it doesn't need a NL at the end of
> the last line.
>
> Where did you get the 'find' command from?
The asm src file is s.Find, originally by STEPHEN GOLDBERG. ISTR I had to 
do something to it to make it dead stable, but that was 2 decades ago 
now. Originally published in the Rainbow but I've no clue which issue 
now. If there is an index of Rainbow someplace in one of our archives, 
it should be easy enough to find. I just tried to cp the src to /x1 and 
wound up wth a no permissions error but it was in the final attr 
setting, the dates all mucked up and I'll probably have to use a hex 
editor on the file from the linux side to fix it. From the coco3, it 
looks like this, and the size is correct but everything else is date and 
perms scrambled:
B00  1900/95/02 09:22  --------     5BF      1DE1 s.Find

That B00 is the owner so its fd.seg is really screwed!
>
> Where would you like me to upload version 19C of c_prep?

Thats up to you Walter. We've several archives, the original of course is 
RTSI but there are newer ones, that others have built in fear of 
looseing more like we did when RTSI was hacked many years ago now.  If 
you want to, pack it up and send it to me and I will put it on my web 
page.  It will be reasonably safe as long as I am still sucking air 
regularly.  And Tormod Volden could probably put it in the 
nitros9/3rdparty C directory so its part of nitros9's collection of C 
compiler stuff.  Those header files I posted should also wind up there 
too.  I should put those 2 headers on my web page too, but the timbers 
under by eyelids are threatening to collapse for the night.
>
And I'm wondering about the os9 copy proggy now. I'll see if I can fix it 
with ded tomorrow.

> Walter
>
> -----Original Message-----
> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Gene
> Heskett Sent: Sunday, 24 March 2019 7:54 PM
> To: coco at maltedmedia.com
> Subject: Re: [Coco] Climax C Compiler setup
>
> On Sunday 24 March 2019 02:45:43 Walter wrote:
> > Missing header files <string.h> & <memory.h>.
> >
> > I can't recompile c_prep because there are includes to non-existent
> > header files.
> >
> > These don’t seem to be on the Climax CoCo C Compiler disk.
> >
> > Anyone know where they might be?
>
> There's a sting.h in the toolshed and
> memory.h is in 3rdparty/packages/uucpbb/src/header/memory.h
> string.h is in 3rdparty/packages/uucpbb/src/header/string.h
>
> What they are doing there, or how they got there I have no clue. Not
> even if they are the correct files.
>
> I have the os9 "find" looking for string.h on my coco3's main hard
> drive. Thats a nearly 500 meg partition so it will take a while. So
> far its found 4 copies in the dsaved copy of my old maxtor drive I
> made on the seagate its searching. That only took 2 or 3 minutes.
>
> And apparently I've either not run the c compiler since the maxtor was
> the main drive, at least a decade back, or I've done it while cd'd to
> the maxtor subdir. I ought to be ashamed of myself.
>
> {t2|08}/DD:find string.h /dd
> string.h found in /DD/MAXTOR/C.SRC/C.COMP1 string.h found in
> /DD/MAXTOR/C.SRC/KREIDER.L string.h found in /DD/MAXTOR/DEFS/OLDDEFS
> string.h found in /DD/MAXTOR/DEFS STRING.H found in
> /DD/MAXTOR/OS9LIB/DEFS
>
> It looks like memory.h is going to be in that same set of locations,
> {t2|08}/DD:find memory.h /dd memory.h found in
> /DD/MAXTOR/C.SRC/C.COMP1 memory.h found in /DD/MAXTOR/C.SRC/KREIDER.L
> memory.h found in /DD/MAXTOR/DEFS/OLDDEFS memory.h found in
> /DD/MAXTOR/DEFS
>
> here is string.h
> {t2|08}/DD:list /dd/maxtor/c.src/c.comp1/string.h char  *strcat();
> char  *strncat(); char  *strhcpy(); char  *strcpy(); char  *strncpy();
> char  *strclr(); char  *strucat(); char  *strucpy(); char  *index();
> char  *rindex(); char  *reverse(); char  *strend(); int   strcmp();
> int   strncmp();
> int   strlen();
> int   strucmp();
> int   strnucmp();
> int   patmatch();
> char  *strchr();
> char  *strrchr();
> char  *strspn();
> char  *strcspn()
> char  *strtok();
> char  *strpbrk();
> EOF
>
> And here is memory.h
> {t2|08}/DD/MAXTOR/C.SRC/C.COMP1:list memory.h
> char    *memccpy();
> char    *memchr();
> int     memcmp();
> char    *memcpy();
> char    *memset();
> EOF
>
> I just checked, the kreider.l versions are identical in both cases.
> You should be able to copy/paste these (without the EOF obviously)
> into your own files and put them wherever needed by your compiler
> environment.
>
> I hope this helps.
>
> > Walter
> >
> > -----Original Message-----
> > From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Walter
> > Sent: Sunday, 24 March 2019 2:01 PM
> > To: 'CoCoList for Color Computer Enthusiasts'
> > Subject: Re: [Coco] Climax C Compiler setup
> >
> > Bill G is correct. In OS/9 EOF is not a character.
> >
> > C_prep uses I_readln to read a line of text terminated by an EOL
> > upto a maximum buffer length.
> >
> > If the buffer length is exceeded a text to long error is returned.
> >
> > The code then checks to see if the last character on the line is a
> > EOL '\r'.  If it is not is then assumes the line is too long and
> > returns a line to long error manually.
> >
> > This is a bad assumption.  It should only assume this if the line
> > read back has no EOL and equals the maximum buffer length.
> >
> > After all most of the last lines in my source code is usually just
> > "}" . Which is just one character and is way shorter than the max
> > line length.
> >
> > If it is shorter the max line length it should just append a null to
> > the buffer and return.
> >
> > I am looking at a fix now!
> >
> > Walter
>
> And TBT, its something I should have caught and fixed in c.prep_19.
> My apologies. ISTR I always had a cr for the last character of
> anything I ever wrote. IMO thats just good housekeeping and everyone
> should just do it. However _19 is not now the last version extant so
> maybe its something that has crept in since. It never came to my
> attention before, so IDK.
>
> IMO, we've been a bit negligent in not corralling this stuff so its a
> known part of the c compiler. IMO it all belongs in /DD/DEFS/INCLUDES,
> but we've never enforced it. Now its biteing us. Or Walter at least.
> ;-)
>
> > -----Original Message-----
> > From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Bill
> > Gunshannon Sent: Saturday, 23 March 2019 7:04 PM
> > To: coco at maltedmedia.com
> > Subject: Re: [Coco] Climax C Compiler setup
> >
> > On 3/22/19 11:28 PM, Stephen Fischer wrote:
> > > OS-9 does not heed EOF.
> > >
> > > That's a MSDOS \ Windows thing which bit me several times, it took
> > > some time to realize why documents were truncated when I first
> > > used MSDOS 3.3.
> > >
> > > End of Text (ETX) is $03, I do not see EOF in the ASCII charts
> > > found by Google.
> >
> > EOF is not always a character.  EOF is end of file and how it is
> > determined is system dependent.  Even DOS/Windows is inconsistent in
> > this regard as it used both ^Z or an length mentry in the directory
> > to determine EOF. Characters like ETX were intended for data
> > transmission and communication device control.  Some have been used
> > for other things, but don't expect that use to common.
> > EOL is done many ways.
> >
> > bill
> >
> >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
> >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page <http://geneslinuxbox.net:6309/gene>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>