[Coco] Climax C Compiler setup

Christopher R. Hawks chawks at dls.net
Sun Mar 24 08:34:46 EDT 2019


On Sun, 24 Mar 2019 12:22:57 +0000 (UTC)
Bill Pierce via Coco <coco at maltedmedia.com> wrote:

> All of Kreider's stuff works
>  
>  

    Amen! Always has...

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




Christopher R. Hawks
HAWKSoft
-- 
Typhoon Rips Through Cemetery; Hundreds Dead
----------------------------------------
       \   ^__^                         
        \  (oo)\_______                 
           (__)\       )\/\           
               ||----w |                
               ||     ||                


More information about the Coco mailing list