[Coco] Climax C Compiler setup

Sun Mar 24 08:22:57 EDT 2019

All of Kreider's stuff works

-----Original Message-----
From: Gene Heskett <gheskett at shentel.net>
To: coco <coco at maltedmedia.com>
Sent: Sun, Mar 24, 2019 8:13 am
Subject: Re: [Coco] Climax C Compiler setup

On Sunday 24 March 2019 08:05:36 Bill Pierce via Coco wrote:

> Gene, those are from Carl Kreider's clib97
>
Do they not work?
>
>
> -----Original Message-----
> From: Gene Heskett <gheskett at shentel.net>
> To: coco <coco at maltedmedia.com>
> Sent: Sun, Mar 24, 2019 7:54 am
> 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>

-- 
Coco mailing list
Coco at maltedmedia.com
https://pairlist5.pair.net/mailman/listinfo/coco