[Coco] Climax C Compiler setup

[Bill Pierce]

Gene, those are from Carl Kreider's clib97
 
 
 
-----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