Btw, I should use MacTorrent more.

Poke a bit at the sources and see if you can make it better

It appears the filler bytes between strings allow the strings to be treated as C strings.

The comment string has a two byte length and is therefore not a pascal string.

Since the ckid is variable length, I would maybe copy only the non-variable part from the resource to CkidRecord (everthing before projectPath).

C in classic Mac OS may have an option to print pascal strings. Is it "%p" instead of "%s"? I forget. That's not going to work for the comment which as a two-byte length.

Since the strings always have a terminating null character, you can treat them as C strings (unless you think someone might try putting a null character inside the string).

If you need to modify a string, you need to remember to update the length. If you update the length, you need to move all the following strings. If you make a string longer, then you need to move all the strings before making it longer.

Str255 is defined in MacTypes.h as:

typedef unsigned char        Str255[256];

That being said, I based the struct in my first post on the Pascal structure defined in the PDF I referenced.  It definitely has pad bytes, and you can see them in ResEdit too, where there appears to be two ^^'s between each data field.

Still not sure what to do here... should I be able to get this to work with C structures, or should I try and parse through it one character at a time?

Thank you!

Is a Str255 defined as char[256] in C? (char should be unsigned)

The first byte is the length. The length is followed by room for 255 characters.

The total length is 256 bytes, so you don't need padding bytes.

Here's all 4 possible string moves. Pick whichever one makes sense for your situation (and maybe add bounds checks or null pointer checks if needed). BlockMoveData is backward compatible with BlockMove (it sets a flag in the A-Line trap which is ignored by BlockMove implementations which don't check it) but is only for data guaranteed to not be 68k code. This means it doesn't have to flush caches (for later 680x0 CPUs) or invalidate the 68k Emulator's JIT cache (for PowerMacs). Which can speed things up.

void CStrToCStr(char * src, char * dst) {
 int len = strlen(src);
 BlockMoveData(src, dst, len+1);
}

void PStrToPStr(Str255 src, Str255 dst) {
 int len = src[0];
 BlockMoveData(src, dst, len+1);
}

void CStrToPStr(char * src, Str255 dst) {
 int len = strlen(src);
 BlockMoveData(src, dst+1, len);
 dst[0] = (char)len;
}

void PStrToCStr(Str255 src, char * dst) {
 int len = src[0];
 BlockMoveData(src+1, dst, len);
 dst[len] = 0;
}