[Coco] Climax C Compiler setup

Sun Mar 24 23:19:27 EDT 2019

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?

Where would you like me to upload version 19C of c_prep?

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