[Coco] C language

[Joel Rees]

Sorry I disappeared.

Circumstances required me to be waving a baton on roads near construction
sites and other such activities over the past week and a half.

2019年11月23日(土) 1:39 Salvador Garcia via Coco <coco at maltedmedia.com>:

>  Thanks Joel.
>
> My objective is to prepare for a project which I hope to start in 2020. It
> is CoCo related in that it involves interfacing an Arduino, hence the
> desire to better learn the language.
>
> I am hesitant to post my C questions here because they might be considered
> off topic since the question would not directly involve a CoCo.
>

There is lots that directly involves the CoCo in the following.

Presently, I am working on algorithms to convert a relative file path to an
> absolute one, given the current working directory.


Strings on the CoCo are not the same as strings on the host OS.

This is to manage files on an SD card attached to the Arduino which in turn
> would be attached to a CoCo. Yes, I know, there are better solutions, like
> the (vastly) superior CoCo SDC, but I want to use this as an exercise to
> better understand the C language, the Arduino and of course, the CoCo's
> disk handling logic. Call it an academic exercise.
>

(thumbs-up)

The research I've done tells me that I need to use either char arrays or
> strings where many favor the use of char arrays. Although I don't see a
> distinction between the two (a string is a null terminated char array), I
> suspect that it has to do with the libraries used.
>

Are you sanguine to the fact that char is not character?

The C char type is sort-of misnamed. If they had had the advantage of our
current point of view, they would have named it byte, I think, although
there were good reasons at the time for not using byte. Anyway, the choice
of "char" was not really to save typing, in spite of a lot of people saying
it was.

   char != character

So, a C string of characters on a CoCo is (roughly speaking) an array of
char, terminated by a NUL char, and handled by appropriate library routines.

The same array can be treated as an array of bytes, as well, since ECB and
OS-9/6809 do not know anything about multi-byte characters.

Consider also that a string on OS-9/6809 is not the same as a string on
ECB, and, because there are several different character sets, ECB itself
has some ambiguity about the nature of a string.

Also, path on ECB depends on which variant of DOS you are using, and is
different from path on OS-9, and on your host.

I've also started doing some research into the Arduino SD library and it
> may that my problem may be easily solvable by using the SD library's
> functions.


If the Arduino host interface libraries have path parsing for the host, you
would do well to use them to pull off the end file name, then test that the
characters in the file name are all part of the character sets on the CoCo
that you want to deal with. Testing that they are all 7-bit US ASCII will
get you a good part of the distance, and may be enough. It will probably be
enough to start with, anyway.

I haven't gotten that far yet (doing that now), so I can't be sure of this.
> But if I can use the library, instead of manually parsing the given path
> then worrying about char arrays and strings is moot.


Only moot if you have at least an approximate awareness of the character
set limitations on the CoCo and how you want to deal with them.

As originally mentioned, I would like to eventually migrate my C skills
> towards CMOC. If there are no objections I will post my C questions here,
> of course after due diligence on my part :-). Salvador
>

I think it's a good idea.

>