Renamed GetReplacementType() to GetStructReplacementType().
Clarified in comments that most *Struct* facilities work for unions as well.
Made it clear in some error messages with regards to structs/unions.
In ca65.sgml, the following pattern was used in tables in order to
create an empty row:
||~@
That is, the first two columns are empty, the last one has an
Unfortunately, with newer linuxdoc, this fails, as the empty columns
create two @item directly after each other, which is not allowed.
Changing this to
~|~|~@
fixes it by adding an " " into each column.
Furthermore, the last line had a "newrow" (@) separator, which created
an artifact. Removed that one.
Please refer to https://github.com/cc65/cc65/pull/532 for background info.
I wrote in https://sourceforge.net/p/cc65/mailman/message/35873183/
===
cputs() wraps to the next line if the strings is too long to fit in the current line. I don't know if it's worth the effort to allow cpeeks() to continue reading from the next line. I'd like to discuss this aspect with the actual implementers.
===
This is still as unclear today as it was when I wrote the above. Therefore this change just doesn't add cpeeks() at all.
Since f8c6c58373 the Apple II CONIO implementation doesn't "need" revers() anymore - meaning that (nearly) every possible value can be placed in VRAM with a straight cputc() (without the need for a previous revers(1)).
The implementation of cpeekc() leverages that cputc() ability by always returning the value that can be fed into cputc() without a previous revers(1). Accordingly, cpeekrevers() always returns 0.
So after the sequence revers(1); cputc(x); a cpeekc() will return a value different from x! However, I don't see this behavior braking the cpeekc() contract. I see the cpeekc() contract being defined by the sequence textcolor(cpeekcolor()); revers(cpeekrevers()); cputc(cpeekc()); placing the very same value in VRAM that there was before. And that contract is fulfilled.
