[Coco] Climax C Compiler setup
Gene Heskett
gheskett at shentel.net
Sun Mar 24 08:13:40 EDT 2019
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>
More information about the Coco
mailing list